Request new standalone mode to sniff and save the record on flash if possible about proxmark3 HOT 48 CLOSED

time and money?

from proxmark3.

Sorry to break the news but there is no external flashmemory on a Pm3 Evo. That is a dedicated RDV4 hw feature.

from proxmark3.

luckily for you that @cjbrigato already did something like that. https://github.com/RfidResearchGroup/proxmark3/blob/master/armsrc/Standalone/hf_colin.c

Your google-foo needs adjustments ;)

[edit]
...well... dump and save atleast. No sniff. I added the enhancement label to this issue

from proxmark3.

...@bogiton has been doing a upgrade to his standalone, adapted for this repo. almost done.

from proxmark3.

This reminds me I have not committed my own updates.
I've added delayed" reader attack from standalone mode. It means it saves traves like you then spit it again when it's connected by either USB or by, first serial available.
(Also ow save up to 4dump from the wild, slot selection for deleting or recalling each, "led menu" replace dump or no save mode, batch-cloming mode against gen1a tags. )
Well I did not think about sniffing... damn good job @bogiton

from proxmark3.

Well, to be honest, I didn't do anything serious. I just borrowed the already perfect code from the SniffIso14443a function and made it standalone. The only addition was the storing of ULC/NTAG/ULEV1 auth attempts into the flash. Which kinda works, but I am still having some flash mem bit flip issues.

from proxmark3.

@cjbrigato bogiton actually has one problem with flashmem. Like he says, its like the fourth byte gets bitflips in the MSB area.. very strange

from proxmark3.

Thank you. I'm so impatient to try it in real-field application

from proxmark3.

Hello. @bogiton what code are you using for flashmem writing ? I did not manage to reproduce the problem with actual driver. Can you point out anyhow how I could reproduce this in a short way ?

from proxmark3.

Hey @cjbrigato
you can find my code here: https://github.com/bogiton/proxmark3-1/blob/master/armsrc/Standalone/hf_bog.c
I believe that even something as simple as this may do:

uint8_t data = 5;
Flash_WriteData(0, &data, 1);

from proxmark3.

@bogiton I notice you need to add a identification string for your mode. Inside appmain.c / printStandAloneModes()
BogitoRun? :)

from proxmark3.

@cjbrigato when will you add all your new goodies?

from proxmark3.

@iceman1001 as soon as this is sorted. Such case freaks me.
@bogiton I did not manage to reproduce with such simple case and infortunately I'm not able to flash your standalone mode right now (multiple standalones will be, one day).
Anyone like @iceman1001 can confirm or infirm the behavior ? Does it smels like a driver issue or more like a well hidden but classic off-by-one / overflow ?
Since I was blind enough to let such an offby leading to overflow happen in my own standalone months ago (still in bereavement here), I guess a check on flashmem.c side would be needed.
@bogiton check my actual standalone again about reading and writings. I made some alternative function for contumibuois writing, or for cases where checkbusy or init would be unnecessary. Compare and test with such.
Also, please confirm that you are indeed working with default spi baudrate.

Oh. And also remind that the spi is actually used when transfering code to the FPGA. Thd functions fbpgaloader are all disruptive in term of spi configuration. Always ensure a clean state before writing to flashmem. You can't reliably jump from fpga loading to flashmem operations as for now and should restart the flash mem init from the start.
I have enforced some known workaround for reseting the spi state (such as double resets etc) and against silicon bugs but still, Spi is definitely not Exact nor rocket science when it comes to AT91SAM7

from proxmark3.

@iceman1001 BogitoRun identification added :)

from proxmark3.

Any progress on this?
Just my curiosity what have to be done to have multiple standalones support? @iceman1001

from proxmark3.

Oops, sorry @cjbrigato I just noticed your edit. Actually I did some more tests for this, where I have found out that this happens (at least in my case), even through the client commands. For example, if I load a file (mem load f test.bin) with the following contents:

05 00 00 00
bf 75 37 4f
11 91 d6 92
c6 2a b2 26
7b 4a 0b 7d

the resulting mem output is this:

pm3 --> mem read o 0 l 20
#db# FlashMem read | 0 - 20 |
#db# FlashMem reading  | 0 | 0 | 20 |
#db# [Chunk: : 00/20] 07 00 00 00 bf 77 37 4f 11 91 d6 92 c6 2a b2 26
#db# [Chunk: : 20/20] 7b 4a 0b 7f

As you can see, the written bytes are wrong in the following positions: 0, 5, 19.
I attached the test file if you want to try it too. test.zip

While testing, I noticed another weird thing. If I load a bin file with zeros in it and right after, without wiping, I try to load another bin file, the contents of the second file won't get written at all.

pm3 --> mem wipe p 0
[+] Flash WIPE ok
pm3 --> mem read o 0 l 32
#db# FlashMem read | 0 - 32 |
#db# FlashMem reading  | 0 | 0 | 32 |
#db# [Chunk: : 00/32] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
#db# [Chunk: : 16/32] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
pm3 --> mem load f zero.bin
[+] Wrote 32 bytes to offset 0
pm3 --> mem read o 0 l 32
#db# FlashMem read | 0 - 32 |
#db# FlashMem reading  | 0 | 0 | 32 |
#db# [Chunk: : 00/32] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#db# [Chunk: : 16/32] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
pm3 --> mem load f test.bin
[+] Wrote 32 bytes to offset 0
pm3 --> mem read o 0 l 32
#db# FlashMem read | 0 - 32 |
#db# FlashMem reading  | 0 | 0 | 32 |
#db# [Chunk: : 00/32] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#db# [Chunk: : 16/32] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

from proxmark3.

@bogiton I cannot reproduce your bug on my device. If anyhow my flashmem driver is sketchy, it is not enought on my device at default spi speed.

About the rest of your message, well... that's exactly how it's meant to be.
Wiping the flash makes all the bit back to 1. "writing" the flash actually is "clearing" bits from 1 to 0.
A cleared bit cannot be "uncleared" unless using an "erase" operation.
Since we can write here 256Byte but can't erase less than 4k, Then we should know that each time we stark writing a 4k block, then it's written until it's erased again.
You can optimize things a little bit in some way : if you cleared only some bit of a block, another write WILL clear the new bit which had to be cleared. They won't change the already cleared one, neither they will unclear them. So you can "write" again and again with this bitmask effect until your 4k block is all 00 if you want.
for example, That means that a 4k block can be used as it's full potential if dedicated to a counter, well a counter TO 0.
If anyhow I missed the point here tell me, that's been too long since I've slept to keep track of every word.

from proxmark3.

This makes sense, that's true. So, before every file load, we should make sure that the region is wiped. Maybe even call the wiping from within the "mem load".
As for my example, just to be sure I set again the spi baud to 24, but the problem persists. I try this on the latest version of the RPG repo, but under Windows. Maybe my flash mem is faulty.
Could someone else verify this?

from proxmark3.

@bogiton wont call erasing within the load operation. You could want to pass loaded file like a mask against already cleared bits. You may want to have multiple "pass" effect against the flash as the wanted behavior of an algorythm. You may not want a full wipe nor a wipe the size of the file nor a wipe at a given offset.
But line every other program do we should propose or have a flag for wiping before load automation. Why not with loaded file size calculation for best wiming method, even could get to a size vs speed calculation of method.
Anyway i'm more into leveraging this flash with a very basic sortof filesystem with 4kblocks than anything else and keep away from automagicing low level things.
There are a bunch of fs which could work here. Might be a matter of less than a few hours to implement. Just bot forgetting the client side part to get "files" back and forth.

from proxmark3.

Strictly speaking, from the end-user point of view, when a user issues a file-load-into-flash-mem command, he would expect the file loaded onto the flash mem, regardless of what the mem had before in it or what happens in the low level. A flag to wipe before load sounds like a good idea though.
Flash file system would be awesome, but I am not sure that it should be limited to files.

from proxmark3.

...like what @cjbrigato said...
You did the same mistake as I did when I first approached the flashmem.
but in short the wipe processes sets everthing ot 0xFF. a "write bit" command actually flips to 0 that bit.
The same bit can not change anymore until next wipe.

• 16 4k sectors available on 4 pages.
• 256b writes at the time
• rewrite of same area, must be wiped before

The mix between sectors / writepages and direct address (offset in memory) make it easy to do the wrong thing. There are functions in code to support offset, array of data, ...
but before you need to keep track of which sector/page that offset lays in. You would also need to remember if the area is written to before or not.

Client cmds
So I agree with colin, that no wipe inside the load command. We have a seperate wipe command for it in the client. The client wipe is on 64k page level in order to upload a file easy.

interal calls
Here you need to check length of data, and wipe the correct amount of 4k sections instead. When you need to wipe....

I tried to map some sectors for special causes, like having the default keys uploaded, LF T55xx config, signature data inside Page3 at the end. Leaving page0,1,2 free to do what ever.
If you have suggestion for which sectios should be reserved for other ideas...

from proxmark3.

Alright, I understand what you guys are saying. But I still don't get the bit-flip issue I'm having, right after wiping the first page where I get to load my test file, using the client commands. @iceman1001 did you try to load the file I attached?

from proxmark3.

Ok, this is definitely caused by the different spi baudrate. After setting the baudrate to 48Mhz, the writing works just fine.

pm3 --> mem wipe p 0
[+] Flash WIPE ok
pm3 --> mem spi 24
#db# Spi Baudrate : 24Mhz
pm3 --> mem read l 32
#db# FlashMem read | 0 - 32 |
#db# FlashMem reading  | 0 | 0 | 32 |
#db# [Chunk: : 00/32] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
#db# [Chunk: : 16/32] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
pm3 --> mem load f test.bin
[+] Wrote 32 bytes to offset 0
pm3 --> mem read l 32
#db# FlashMem read | 0 - 32 |
#db# FlashMem reading  | 0 | 0 | 32 |
#db# [Chunk: : 00/32] 07 00 00 00 bf 77 37 4f 11 91 d6 92 c6 2a b2 26
#db# [Chunk: : 16/32] 7b 4a 0b 7f ff ff ff ff ff ff ff ff ff ff ff ff
pm3 --> mem wipe p 0
[+] Flash WIPE ok
pm3 --> mem spi 48
#db# Spi Baudrate : 48Mhz
pm3 --> mem read l 32
#db# FlashMem read | 0 - 32 |
#db# FlashMem reading  | 0 | 0 | 32 |
#db# [Chunk: : 00/32] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
#db# [Chunk: : 16/32] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
pm3 --> mem load f test.bin
[+] Wrote 32 bytes to offset 0
pm3 --> mem read l 32
#db# FlashMem read | 0 - 32 |
#db# FlashMem reading  | 0 | 0 | 32 |
#db# [Chunk: : 00/32] 05 00 00 00 bf 75 37 4f 11 91 d6 92 c6 2a b2 26
#db# [Chunk: : 16/32] 7b 4a 0b 7d ff ff ff ff ff ff ff ff ff ff ff ff

from proxmark3.

If you have suggestion for which sectios should be reserved for other ideas...
It's possible to reserve some space to indicate what standalone mode to operate? In this way we could set the mode by a command and simply reboot. Which part of code as to be changed to a sort of switch case to make that appen?
I take a look here https://github.com/RfidResearchGroup/proxmark3/blob/master/armsrc/Standalone/readme.md
I read some modes the problem is they share a lot of functions (like LED and so on)?

P.S. @iceman1001 time and money? I understand that and I appreciate the effort every people put in this project

from proxmark3.

@bogiton Looks like you solved your problem and we can close this issue

@BreakSecurity Sounds like a interesting approach, which would need some rewrite of the current standalized way of adding new standalone modes. Inside appmain, main loop, would be the switch.
ie call all runmode with the id. Every runmode function has their own id, if id matches, continue execute that mode. if not, exists. All support functions inside a standalone most be compartmentlized.
...and a array of available standalone modes to be called with the id...

That would be the solution for it such functionality I think.

from proxmark3.

ok, wrong issue, I think @bogiton has another issue somewhere else about this. Sorry. That one should be closed. Not this one.

from proxmark3.

Yeah, I kinda hijacked this issue. Sorry about that! Well, at least now I can make the standalone pwd sniff work. :P

from proxmark3.

yes, i did rewrite it a bit.. never finished that part... So little time. But basically you don't need that looping, you can call write functions in flashmem.c instead :)
You could also skip that counter thingy.. And just loop memory and write after when you get 4 0xFF,,, Well assuming 0xFF FF FF FF is not allowed as pwd to save :)

from proxmark3.

Until we can eXcute In Place on the spiflash or have clear way to specialise/strip down the firmware at make time by a whole block of feature, having multiples standalone modes here is not possible statically. To costly. I'm more into having XIP working anyhow or being able to load overwriting standalone modes on the go.

About @bogiton that was my feeling that it had to do with spi-rate. Still, this is highly uncommon and unlikely that the 48Mhz works and the 24Mhz don't.
The chip is a lot more sensible on Reading speeds that writing speeds. When you choose to get at 48Mhz, Fastreads are used instead of reads nut writes remain unchanged.

@bogiton can you try this : wipe the flash, then write or load to memory at normal spi speed.
But then switch to 48Mhz for READING the result.
My guess is that your problem is absolutely not woth writing but with reading, and that somehow you cant manage to use Normal Reads in an error-free way at 24mhz.
In my tests scenarios, a subtile change on the voltage levels is enough to trigger the "normal reads are not enough" behavior at 24mhz. Because such voltage directly plays in the maximum conditions the chip can handle in this or that way.

Can you make this test and get back to us ? Thx

from proxmark3.

@RfidResearchGroup this was the plan from the start, but while testing/debugging I had to reach to the write loop used in the flashmem.c (just like colin does in his standalone), just to make sure that everything else was the same. I guess I can safely rewrite it to be more clear now. The 0xFFFFFF is actually one of the default pwds used in ULEV1 auth, but I suppose it isn't one of worth sniffing in the first place, so yeah, I think I'm gonna drop the counter, as you suggest.

@cjbrigato yeah that was my thought exactly when I read about the use of fast reads when the baudrate is set to 48MHz. But, it seems that the writes are also affected when the FlashSetup is called with the higher baudrate. Probably along this line in flashmem.c (90):
SPI_DLYBCT(dlybct,MCK) // Delay between Consecutive Transfers (32 MCK periods)
where the dlybct is set to 1500 instead of 0.
So here is the result of the test you asked me about:

pm3 --> mem wipe p 0
[+] Flash WIPE ok
pm3 --> mem spibaud 24
#db# Spi Baudrate : 24Mhz
pm3 --> mem load f test.bin
[+] Wrote 32 bytes to offset 0
pm3 --> mem spibaud 48
#db# Spi Baudrate : 48Mhz
pm3 --> mem read l 32
#db# FlashMem read | 0 - 32 |
#db# FlashMem reading  | 0 | 0 | 32 |
#db# [Chunk: : 00/32] 07 00 00 00 bf 77 37 4f 11 91 d6 92 c6 2a b2 26
#db# [Chunk: : 16/32] 7b 4a 0b 7f ff ff ff ff ff ff ff ff ff ff ff ff

from proxmark3.

Cannot reproduce. Working as is at 24mhz. So if it is not reads you are definitely on the right track, it is that a multiplier has gone one step to far or not far enough. This is because I've error-tried because of sillicon bugs and other strange at91sam7s behavior to ensure fastest transfer speed ,i.e. with the least possible clock cycles.
Two possibility here :

• tweak the delays to a more safe value.
• find the cause compiler-wise. What is your gcc version ? Could you try lowering optimization level when compiling?
  I sense a compile time change is responsible because it works st 48mhz. Definitely it should be more unstable at 48mhz here.

from proxmark3.

hi,
maybe too late, but...
maybe it needs to include a flash filesystem in code and thats all?
will no need to manage blocks and etc by hand and saves flash durability...

from proxmark3.

I have asked my friend and he shows me cool flash filesystem)
https://github.com/pellepl/spiffs
https://github.com/pellepl/spiffs/wiki/Integrate-spiffs

if it needs more flexibility - then use https://yaffs.net/ but it needs to clarify maybe it too big for our cpu

from proxmark3.

@cjbrigato I did some more tests. My usual workstation is Windows, so all my tests (compiling, running) were under Gator's Proxspace (gcc version 5.3.0). So, this time I connected the rdv4 to a Linux box (Raspbian). Exactly the same thing was happening there. Just to be sure, I recompiled everything under Linux and I even re-flashed the device there (gcc version 4.8.4). I tried again the same example and the bit-flipping was still there but in different positions! Once again, worked fine with the baud rate set to 48mhz.

pm3 --> mem spi 24
#db# Spi Baudrate : 24Mhz
pm3 --> mem wipe p 0
[+] Flash WIPE ok
pm3 --> mem load f test.bin
[+] Wrote 32 bytes to offset 0
pm3 --> mem read l 32
#db# FlashMem read | 0 - 32 |
#db# FlashMem reading  | 0 | 0 | 32 |
#db# [Chunk: : 00/32] 05 00 00 00 ff 75 37 4f 11 d1 d6 d2 c6 2a f2 26
#db# [Chunk: : 16/32] 7b 4a 0b 7d ff ff ff ff ff ff ff ff ff ff ff ff
pm3 --> mem spi 48
#db# Spi Baudrate : 48Mhz
pm3 --> mem wipe p 0
[+] Flash WIPE ok
pm3 --> mem load f test.bin
[+] Wrote 32 bytes to offset 0
pm3 --> mem read l 32
#db# FlashMem read | 0 - 32 |
#db# FlashMem reading  | 0 | 0 | 32 |
#db# [Chunk: : 00/32] 05 00 00 00 bf 75 37 4f 11 91 d6 92 c6 2a b2 26
#db# [Chunk: : 16/32] 7b 4a 0b 7d ff ff ff ff ff ff ff ff ff ff ff ff

from proxmark3.

@merlokk yeah , a SPIFFS would be best. Colin already explained to me, but I never got time to look into it.

from proxmark3.

@iceman1001 I just updated my standalone mode, added spibaud set/reset, removed the counter and extra functions and seems to be working fine now. Should I PR?

from proxmark3.

Go for it! Push Push Push!

from proxmark3.

Its been merged!

from proxmark3.

I have asked my friend and he shows me cool flash filesystem)
https://github.com/pellepl/spiffs
https://github.com/pellepl/spiffs/wiki/Integrate-spiffs

if it needs more flexibility - then use https://yaffs.net/ but it needs to clarify maybe it too big for our cpu

Will you implement this? @iceman1001

I didn't understand this can you explain better? @cjbrigato
"Until we can eXcute In Place on the spiflash or have clear way to specialise/strip down the firmware at make time by a whole block of feature, having multiples standalone modes here is not possible statically. To costly. I'm more into having XIP working anyhow or being able to load overwriting standalone modes on the go."

Thank you I just compiled with BogitoRUN I'll let you know when I try this out in real-field ;) @bogiton
P.S. Some way to test without a reader? (I have the proxmark easy and chameleon too maybe one of the two can act as a reader but i don't know how to configure)

from proxmark3.

SPIFFS - i can implement or maybe Colin if he have a time.
now i have plain for 1-2 months. after that i can)

from proxmark3.

I have no time to implement anything, feel free do it.

from proxmark3.

If I had anything like "time", this would have already been implemented. Like @iceman1001 said, we've already been discussing this matter weeks or month ago. Out first argue about leveraging the flash even came years ago when first having access to 512 instead Of 256 on the at91sam7. I started developing in this matter but the firmware then grew too much with too much features to neither handle not benefits these development, which were kept for very specific wild firmware.

All this to say... anybody but me but yes, just do it. In the case of spiffs the work to do is nothing mote than giving three or so low level i/o function to the ready to go abstraction.
Just as fatfs and all these micro fs are. It's a matter of hours, not really more.

from proxmark3.

@bogiton I try it out:

1. Press button until LED_A on
2. Sniff (LED_A + LED_C on)
3. Press again button to stop sniff LED_A and LED_C off
4. At home mem read l 256 result in all ffffffffffffffffffffffffffffffff...

What went wrong? Where I can set DEBUG level globally @iceman1001 ? I found this in common.h:

// debug
// 0 - no debug messages 1 - error messages 2 - all messages 4 - extended debug mode
#define MF_DBG_NONE          0		
#define MF_DBG_ERROR         1
#define MF_DBG_ALL           2
#define MF_DBG_EXTENDED      4
extern int MF_DBGLEVEL;

from proxmark3.

@BreakSecurity what kind of communication did you try to sniff? This only stores AUTH attempts for ULC/NTAG/ULEV1 tags in the flash mem. If you want to see the entire sniffing session, you need to keep your RDV4 powered while reconnecting it to a client (with a Y-cable) where the reconnect feature works and type 'hf 14a list'. The current RFG repo has no reconnect capability. Personally, I use a pm3-iceman client just for this.

from proxmark3.

@bogiton I sniff AUTH attempts for an ULEV1 tags (I know becouse the reader wrote on password protected area).
Tell me about the led in my previus post are the on off sequence right?
Some way to test without a reader? (I have the proxmark easy and chameleon too maybe one of the two can act as a reader but i don't know how to configure)

from proxmark3.

@BreakSecurity The sequence sounds about right. Could just be wrong positioning of the rdv4 and didn't grab the pwd (?).

When I was testing locally I had the following setup:

1. the RDV2 used as the reader (I suppose you can use the easy for that), connected on a Linux box.
2. the ULEV1 card to test the authentication on top of the RDV2.
3. the RDV4 to sniff and store the auth on top of the ULEV1 card, connected on a Windows PC.

First you enable the standalone mode on the RDV4, just like you did before. From the pm-easy try running a few auth attempts (for example type: hf mfu info, which will try the default passwords). After that, stop the standalone mode and then view the flash mem of the RDV4.

In order to view the debug messages in the connected client, you have to set the MF_DBGLEVEL to a higher level than 1 (for example by adding MF_DBGLEVEL=2; inside the SniffAndStore function), or just remove the if (MF_DBGLEVEL > 1) in front of the Dbprintf calls.

Btw, how do you power your RDV4?

from proxmark3.

Hi. Is there any way in standalone mode 14a sniff and save in flash men in proxmark3 evo(clone)?

from proxmark3.

It's a pity. Thanks so much :)

from proxmark3.