search

RfidResearchGroup / proxmark3

Iceman Fork - Proxmark3
http://www.icedev.se
GNU General Public License v3.0
4.08k stars 1.07k forks source link

LF save and restore #412

Open mwalker33 opened 5 years ago

mwalker33 commented 5 years ago

Is your feature request related to a problem? Please describe. No

Describe the solution you'd like This is a place holder to work on the below items bit by bit and discuss options.

lf t55xx dump to file/restore from file
lf em 4x05 restore/dump/read/write/wipe lf em 4x50 restore/dump/read/write/wipe

File formats (eml, bin and json) Note: json will need some discussion for each.

Status

lf em 4x05

lf t55xx

mwalker33 commented 5 years ago

Looking at the em4x05 the help also talks about em4x69 The em4x69 seems to have a few versions.
The em4469 datasheet looks similar but does have some block layout differences. e.g. blocks 14 and 15 are user blocks not block protection/lock words and block 3 is the lock word. Also block 0 is R0, where as the 4x05 seems to have block 0 writeable.

I wanted to get some em4469 (or similar) to I could test. but they seem a little hard to find. Can anyone recommend a supplier to the em4469 ? Thanks

mwalker33 commented 5 years ago

Working on the t55xx dump to .eml and .bin Since the T55xx cards dont have a UID/Serial# not sure if we want to auto save or just save if f is supplied. if you want autosave, then do you want to use block 0 (config) as part of the filename ? e.g lf-t55xx-00148040-data.bin

edit: Since some T55xx cards only have page 0 (8 blocks), some have page 0 + 2 page 1 blocks and others have 4 page 1 blocks, I have set it up that it will save IF all page 1 is read OK, and any failed reads for page 1 blocks will be set to 0x00000000

iceman1001 commented 5 years ago

Yup. block0 should be used in filename. %08X capital hex.

Next step json format ;)

doegox commented 5 years ago

I'd say ideally also the blocks which are emitted according to the config, which reflects more what the current card UID is.

mwalker33 commented 5 years ago

Yeah I was thinking about that. most ID cards tend to be 2 or 3 blocks of data. so something like IDStr = "" if block1 != 00000000 or ffffffff the IDStr += block1 if block2 != 00000000 or ffffffff the IDStr += block2 if block3 != 00000000 or ffffffff the IDStr += block3 then fall back if IDstr == "" IDStr = block0

whats too long for a filename (from a user perspective) e.g. if limited to 3 blocks then max filename should be lf_t55xx_XXXXXXXXYYYYYYYYZZZZZZZZ-data.bin

doegox commented 5 years ago

I was more thinking of using the MAXBLOCK info from block0 to know how many blocks to take, maybe indeed with a max value even if only indala long id is 7, all others are max 4 blocks.

updated Looking at block1 to blockN where N is MAXBLOCK from block0:

We could even use the defines in cmdlft55xx.h to identify the type of tag if there is a match with block0, but maybe it becomes too complex.

iceman1001 commented 5 years ago

I think you are mixing up dumping a credential which has maxblocks vs making a complete t55x7 dump which is the intention of this command.

Ideally a t55x7 dump file would save all memory of tag. Both P0 and P1.

mwalker33 commented 5 years ago

I will draft it in and test, then we can review and tweak. I have just completed roughing in the lf t55 restore f for this draft, I check the ext and if .bin, binary load, if eml, then eml load It then writes back to a blank T55xx At the moment it assumes a non password protected card (will look at clearing the password if set password next) restore procedure will be something like lf t55 det <- this is really just to ensure we know the downlink mode incase not default
lf t55 restore f <filename.bin/eml> I write out blocks 1-7 page 0, then 1-3 page 1, then if d/l mode bits set from restore file, update the d/l mode, then last of all write 0 page 0 (config, so if password flag is set, everything else has been written.

For testing I setup an EM4100 tag, set a password and changed the downlink mode. perfect restore :)

iceman1001 commented 5 years ago

And now I got the problem. I am slow today. Block0 isn't very unique. Yes. Agreed.

Maybe we skip block values in file name. Have template and user input instead?

lf_t55xx_AAAAAAA.bin
where AAAAA is user inputed filename

The sperate that the template gives is kind of nice when you have many dumps like me laying around. Easy to see where it belongs.

mwalker33 commented 5 years ago

the user can supply the prefix lf t55 dump -f So, the question was more what to do if no filename prefix is supplied.
we can tune it as needed :)

iceman1001 commented 5 years ago

if "-f" is supplied and no string, thats an invarg fault, ie inform user of mistake

mwalker33 commented 5 years ago

What I have done for the dump filename. lf t55 dump f < prefix > Will dump to files < prefix >.eml / .bin (.json to be added later) lf t55 dump (no filename) Will build from the tag data from blocks 1 to x, upto block 7 or block data is 00000000 or ffffffff

existing save calls will add the -x if the file exists.

e.g.

[usb] pm3 --> lf t55 dump
[+] Reading Page 0:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | 00148040 | 00000000000101001000000001000000 | ...@
[+]  01 | FFCA518B | 11111111110010100101000110001011 | ..Q.
[+]  02 | DEC60C60 | 11011110110001100000110001100000 | ...`
[+]  03 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  04 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  05 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  06 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  07 | 00001111 | 00000000000000000001000100010001 | ....
[+] Reading Page 1:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | 00148040 | 00000000000101001000000001000000 | ...@
[+]  01 | E0150A48 | 11100000000101010000101001001000 | ...H
[+]  02 | 2D782308 | 00101101011110000010001100001000 | -x#.
[+]  03 | 90000C00 | 10010000000000000000110000000000 | ....
[+] saved 12 blocks to text file lf-t55xx-FFCA518B-DEC60C60-data.eml
[+] saved 48 bytes to binary file lf-t55xx-FFCA518B-DEC60C60-data.bin
iceman1001 commented 5 years ago

Great!

antoniovazquezblanco commented 1 week ago

Hi! It seems that EM410x dumping into file is not yet supported. I am not very familiar with the code but I may be able contribute if some of the following dobuts are clarified:

EM410x cards seem to be a bitstream that gets decoded into two ids (high and low) and a card type maybe. Despite this, in the end, to clone the cards it seems that the only relevant information is an UID.

What should be stored in the dumpfile? High and low id and type? The bitstream? Should we ditch all the info and only store the UID?

Thanks!

iceman1001 commented 5 days ago

Its because its only 5 hex bytes. You can find it in the proxmark logs...

antoniovazquezblanco commented 5 days ago

Its because its only 5 hex bytes. You can find it in the proxmark logs...

Yep, but keeping that info sorted in the same way and format as other cards in a separate folder is a nice feature.

Thanks!