search

RfidResearchGroup / proxmark3

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

`lf em 4x05 view` not working for custom named dumps #2279

Closed hornet-hacker closed 8 months ago

hornet-hacker commented 8 months ago

Describe the bug When running the lf em 4x05 view command, it doesn't output correctly. Also, when attempting to view a json file, it shows the full filepath, but when attempting to view a bin file it does not. See output below

[usb] pm3 --> lf em 4x05 view -f A1.bin [+] loaded 64 bytes from binary file A1.bin

[=] Addr | data | ascii |lck| info [=] -----+----------+-------+---+----- [=] -----+----------+-------+---+-----

[=] Note: [=] All ZEROS password block might be filler data [usb] pm3 --> lf em 4x05 view -f A1.json [+] loaded /media/user/XSYSTEM/files_prox/dump/A1.json

[=] Addr | data | ascii |lck| info [=] -----+----------+-------+---+----- [=] -----+----------+-------+---+-----

[=] Note: [=] All ZEROS password block might be filler data

Expected behavior Here is the output of cat on the json in the above output:

┌──(user㉿dell11)-[/media/user/XSYSTEM/files_prox/dump] └─$ cat A1.json { "Created": "proxmark3", "FileType": "EM4205/EM4305", "Card": { "UID": "16935928", "Config": "003E8258", "Protection1": "00008002", "Protection2": "00000000" }, "blocks": { "0": "00040072", "1": "16935928", "2": "50524F58", "3": "0000CF2A", "4": "003E8258", "5": "556A9647", "6": "55555555", "7": "95555555", "8": "5595555A", "9": "A6955A9A", "10": "5A99595A", "11": "00000000", "12": "00000000", "13": "00000000", "14": "00008002", "15": "00000000" } }

Desktop (please complete the following information):

Additional context dumps made within the last couple of days, at the same time that the command that isn't working for me was being written.

iceman1001 commented 8 months ago

There was a fix pushed two days ago, so try latest source. Compile / flash / test again.

regarding the file path printed or not , this is because we have not decided which way is better. long paths take screen space, but gives some info. filename only is excellent for screen space, but gives no info See it as a quirk.

hornet-hacker commented 8 months ago

I pulled and compiled latest source immediately before posting this issue. I understand the file path quirk now, thanks for that information.

iceman1001 commented 8 months ago

Well, I can't replicate your issue.
Try running the commands with debug log enabled.

lf em 4x05 dump
lf em 4x05 -f <file from above>

image

hornet-hacker commented 8 months ago

I'm not sure how to turn on debugging, but the real issue I just discovered is named dump files. If I create a dump and allow the client to name it, that dump loads fine with the view command. If I then create a non-default named dump of the same card, the view command returns the broken output of my original comment. I have changed the name of the issue to reflect that.

This can be recreated with: lf em 4x05 dump -f name lf em 4x05 view -f name Screenshot_2024-01-28_04-57-50 Screenshot_2024-01-28_04-59-03

hornet-hacker commented 8 months ago

Further testing shows the view command will properly load a dump with the name lf-4x05-* regardless of the rest of the filename. Screenshot_2024-01-28_05-10-58

iceman1001 commented 8 months ago

Aha, That is useful. We use filename to detect what kind of type of file it is.
Let me have a look at it

iceman1001 commented 8 months ago

We don't have a simple way to detect what kind of tag it is. Hence we are falling back to filename to identify tag type.

iceman1001 commented 8 months ago

ok, we did have better identification.

Pull latest and test, should be fixed

hornet-hacker commented 8 months ago

Fixed now.