Describe the bug
The sniff and dump feature seems to misinterpret some of the data, and save wrong values. Using proxmark3 to read a sector from a mifare 1k slot, and comparing the traces give different values.
I noticed this while trying to write a script to convert CU GUI's .bin files to pm3 .trace files
To Reproduce
Steps to reproduce the behavior:
- Import a mifare 1k card to slot 1, with default keys
- Place the chameleon ultra on the proxmark3
- In CU GUI, choose slot 1, then go to Tools>HF Sniffing, and start a capture
- In pm3, type
hf mf rdsc --sec 1
- In pm3, type
trace list -c -t mf
- Note the differences, in the card responses
Expected behavior
I should observe the same values in the proxmark 3 trace and Chameleon trace (being aware that proxmark's app is able to decode the encrypted part of mifare transmission, the differences can be seen in the encrypted part (ie even using trace list -t 14a to have no interpretation of the mifare commands)
Screenshots
In the above screenshot, which is part of the trace obtained, where the chamelon sends the actual data contained in sector 1, the app show the chameleon sent 64 44 C3 5B, where the proxmark shows 64 A2! F0! 6B, and a block of data 70 0a ad 16 56 d9 cf 75 e3 1e 91 b4 96 90 95 bd 69 85 07 22 where the proxmark shows 70 85 AB! C2 95 7E! D7 C6 1E 48! AD! 12! 59 EC! A6 0A 07 91
The same behavior is observed with the following bytes. The first byte seems to be correct each time, so I wonder if it's a parity problem. Even the length is wrong, the CU shows 20 bytes, the proxmark shows 18 bytes, including the 2 CRC bytes.
I have added the tracefile from the pm3 and .bin and .hex files from CU GUI in a zip file.
traces.zip
Version info:
- OS: linux
- App build number: 1.3.0 (Build 0)
- Connection type: USB
- Chameleon firmware commit: 2?1 (v2.1.0-235-g1a014f9)
Also required:
Describe the bug
The sniff and dump feature seems to misinterpret some of the data, and save wrong values. Using proxmark3 to read a sector from a mifare 1k slot, and comparing the traces give different values.
I noticed this while trying to write a script to convert CU GUI's .bin files to pm3 .trace files
To Reproduce
Steps to reproduce the behavior:
hf mf rdsc --sec 1trace list -c -t mfExpected behavior
I should observe the same values in the proxmark 3 trace and Chameleon trace (being aware that proxmark's app is able to decode the encrypted part of mifare transmission, the differences can be seen in the encrypted part (ie even using trace list -t 14a to have no interpretation of the mifare commands)
Screenshots
In the above screenshot, which is part of the trace obtained, where the chamelon sends the actual data contained in sector 1, the app show the chameleon sent
64 44 C3 5B, where the proxmark shows64 A2! F0! 6B, and a block of data70 0a ad 16 56 d9 cf 75 e3 1e 91 b4 96 90 95 bd 69 85 07 22where the proxmark shows70 85 AB! C2 95 7E! D7 C6 1E 48! AD! 12! 59 EC! A6 0A 07 91The same behavior is observed with the following bytes. The first byte seems to be correct each time, so I wonder if it's a parity problem. Even the length is wrong, the CU shows 20 bytes, the proxmark shows 18 bytes, including the 2 CRC bytes.
I have added the tracefile from the pm3 and .bin and .hex files from CU GUI in a zip file.
traces.zip
Version info:
Also required:
- I've upgraded app to latest app version
- I've upgraded Chameleon firmware to latest version
- I've searched and verified that there is no already created issues