Failed to simulate Amiibo

RedL0tus commented 4 years ago

Describe the bug May be somewhat a regression.
I tried to simulate Amiibos with dumps acquired online, but my Switch does not recognize it correctly. This issue is only present in this newer RRG fork but not the older deprecated iceman fork.
I'm new to RFID stuffs and the only tool available in hand is my phone, and I scanned the simulated tags with NFC Tools which shows that with the RRG fork the "Memory information" field is missing (screenshots are linked below).

To Reproduce Steps to reproduce the behavior:

Acquire the dump online (I used the complete amiibo dump from NFC Bank).
Use the mfubin2eml script to convert the bin dumps from .bin to .eml

Start the simulation with commands like:

hf mf eload u <whatever>
hf 14a sim t 7 u <UID>

Scan the simulated tag
Do these steps again but with the old iceman fork, compare the results.

Expected behavior Both versions of the firmware should have the same result and can be recognized from the Nintendo Switch.

Screenshots (With the RRG fork): RRG

(With the older iceman fork): iceman

Desktop (please complete the following information):

OS: Tried on macOS 10.15.5(x86_64) and Ubuntu 18.04 on Jetson Nano (AArch64).
- Toolchains used:
  - On macOS: Official clang (11.0.3) and official arm-none-eabi-gcc from ARM(GNU Arm Embedded Toolchain 9-2020-q2-update, 9.3.1 20200408)
  - On Jetson Nano: Official Ubuntu GCC (7.5.0) and official arm-none-eabi-gcc from ARM(GNU Arm Embedded Toolchain 9-2020-q2-update, 9.3.1 20200408)

(So I'm kind of sure that it's not my toolchains' fault)

inside proxmark3 client run the following commands and paste the output here.
hw version
hw status
data tune

RRG:

hw version:

[usb] pm3 --> hw version

 [ Proxmark3 RFID instrument ]

 [ CLIENT ]
  client: RRG/Iceman/master/v4.9237-343-g25fb6df2 2020-06-12 20:05:49
  compiled with Clang/LLVM 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.32.62) OS:OSX ARCH:x86_64

 [ PROXMARK3 ]

 [ ARM ]
  bootrom: RRG/Iceman/master/v4.9237-343-g25fb6df2 2020-06-12 20:05:41
       os: RRG/Iceman/master/v4.9237-343-g25fb6df2 2020-06-12 20:05:50
  compiled with GCC 9.3.1 20200408 (release)

 [ FPGA ]
  LF image built for 2s30vq100 on 2020-02-22 at 12:51:14
  HF image built for 2s30vq100 on 2020-01-12 at 15:31:16

 [ Hardware ]
  --= uC: AT91SAM7S256 Rev B
  --= Embedded Processor: ARM7TDMI
  --= Nonvolatile Program Memory Size: 256K bytes, Used: 228777 bytes (87%) Free: 33367 bytes (13%)
  --= Second Nonvolatile Program Memory Size: None
  --= Internal SRAM Size: 64K bytes
  --= Architecture Identifier: AT91SAM7Sxx Series
  --= Nonvolatile Program Memory Type: Embedded Flash Memory

hw status:

[#] Memory
[#]   BigBuf_size.............47540
[#]   Available memory........43444
[#] Tracing
[#]   tracing ................0
[#]   traceLen ...............3118
[#] Current FPGA image
[#]   mode.................... HF image built for 2s30vq100 on 2020-01-12 at 15:31:16
[#] LF Sampling config
[#]   [q] divisor.............95 ( 125.00 kHz )
[#]   [b] bits per sample.....8
[#]   [d] decimation..........1
[#]   [a] averaging...........Yes
[#]   [t] trigger threshold...0
[#]   [s] samples to skip.....0
[#] LF T55XX config
[#]            [r]               [a]   [b]   [c]   [d]   [e]   [f]   [g]
[#]            mode            |start|write|write|write| read|write|write
[#]                            | gap | gap |  0  |  1  | gap |  2  |  3
[#] ---------------------------+-----+-----+-----+-----+-----+-----+------
[#] fixed bit length (default) |  31 |  20 |  18 |  50 |  15 | N/A | N/A |
[#]     long leading reference |  31 |  20 |  18 |  50 |  15 | N/A | N/A |
[#]               leading zero |  31 |  20 |  18 |  40 |  15 | N/A | N/A |
[#]    1 of 4 coding reference |  31 |  20 |  18 |  34 |  15 |  50 |  66 |
[#]
[#] Transfer Speed
[#]   Sending packets to client...
[#]   Time elapsed............500ms
[#]   Bytes transferred.......176640
[#]   Transfer Speed PM3 -> Client = 353280 bytes/s
[#] Various
[#]   Max stack usage so far..4840
[#]   DBGLEVEL................1
[#]   ToSendMax...............165
[#]   ToSendBit...............8
[#]   ToSend BUFFERSIZE.......2308
[#]   Slow clock..............30170 Hz
[#] Installed StandAlone Mode
[#]   HF - Reading Visa cards & Emulating a Visa MSD Transaction(ISO14443) - (Salvador Mendoza)

data tune: data tune on RRG

Iceman:

hw version:

pm3 --> hw version

Proxmark3 RFID instrument

 [ CLIENT ]
 client: iceman build for RDV40 with flashmem; smartcard;

 [ ARM ]
 bootrom: iceman/master/ice_v3.1.0-1097-ga23414fe-dirty-unclean 2020-06-12 21:00:08
      os: iceman/master/ice_v3.1.0-1097-ga23414fe-dirty-unclean 2020-06-12 21:00:11

 [ FPGA ]
 LF image built for 2s30vq100 on 2017/10/25 at 19:50:50
 HF image built for 2s30vq100 on 2018/ 9/ 3 at 21:40:23

 [ Hardware ]
  --= uC: AT91SAM7S256 Rev B
  --= Embedded Processor: ARM7TDMI
  --= Nonvolatile Program Memory Size: 256K bytes, Used: 236713 bytes (90%) Free: 25431 bytes (10%)
  --= Second Nonvolatile Program Memory Size: None
  --= Internal SRAM Size: 64K bytes
  --= Architecture Identifier: AT91SAM7Sxx Series
  --= Nonvolatile Program Memory Type: Embedded Flash Memory

hw status:

#db# Memory
#db#   BIGBUF_SIZE.............40000
#db#   Available memory........35904
#db# Tracing
#db#   tracing ................0
#db#   traceLen ...............919
#db# Currently loaded FPGA image
#db#   mode.................... HF image built for 2s30vq100 on 2018/ 9/ 3 at 21:40:23
#db# Flash memory
#db#   init....................FAIL
#db# Smart card module (ISO 7816)
#db#   version.................FAILED
#db# LF Sampling config
#db#   [q] divisor.............95 (125 KHz)
#db#   [b] bps.................8
#db#   [d] decimation..........1
#db#   [a] averaging...........Yes
#db#   [t] trigger threshold...0
#db# USB Speed
#db#   Sending USB packets to client...
#db#   Time elapsed............1500ms
#db#   Bytes transferred.......763392
#db#   USB Transfer Speed PM3 -> Client = 508928 Bytes/s
#db# Various
#db#   MF_DBGLEVEL.............1
#db#   ToSendMax...............165
#db#   ToSendBit...............8
#db#   ToSend BUFFERSIZE.......2308
#db# Installed StandAlone Mods
#db#    LF HID26 standalone - aka SamyRun (Samy Kamkar)

data tune: data tune on iceman

Additional context The version info on the Iceman fork says dirty is simply because I have to make some changes to make it build correctly with the new toolchain (GCC 9 added several new warnings).

Another suggestion is to make the build system to use tools like pkg-config to automatically find the libraries required, because otherwise it is somewhat painful to compile it in some cursed environment (e.g. The Nix package manager).

RedL0tus commented 4 years ago

Also my Proxmark 3 Easy is the 256K[edited] version, I don't know if it is the cause but right now I have no way to test for that. I would not buy this if I know it is the 128K version beforehand.

I'm just a new college student and Proxmark 3 RDV4 is certainly an overkill for me and is just... not affordable.

doegox commented 4 years ago

Hello, regarding

changes to make it build correctly with GCC 9
pkg-config and Nix package manager please open separate bugreports, we're interested in fixing/making better those ones too.

RedL0tus commented 4 years ago

Hello, regarding

changes to make it build correctly with GCC 9

pkg-config and Nix package manager please open separate bugreports, we're interested in fixing/making better those ones too.

Hi!

For the GCC 9 part, it is not an issue with this newer RRG fork, I was just trying to explain why the version in the old iceman fork says it is “dirty”.

I will open a separate issue about the build system, thank you for your seggestion!

doegox commented 4 years ago

Ha yes sorry, I was surprised we missed a warning :) What could help us btw is if you try older commits to locate roughly the period when the bug appeared. You can use git bisect to help you if you're at ease with it. Thanks!

RedL0tus commented 4 years ago

Ha yes sorry, I was surprised we missed a warning :) What could help us btw is if you try older commits to locate roughly the period when the bug appeared. You can use git bisect to help you if you're at ease with it. Thanks!

I'm absolutely willing to help with that, but I have to get some sleep right now 🤣

BTW, I saw that the 256K[edited] PM3 Easy support was added recently, I may not be able to test for the commits before the support of the 256K[edited] version was introduced.

doegox commented 4 years ago

You've a 256K version while RDV4 and other Easy are 512K, there is no 128K, hopefully :D BTW you'll have to reflash the PM3 during your search but in principle no need to flash the bootloader, it'll be safer. Platform PM3OTHER is defined since 21/8/2019 and for older ones you can use PM3EASY introduced since 3/5/2019. I hope you won't have to go that far away.

RedL0tus commented 4 years ago

You've a 256K version while RDV4 and other Easy are 512K, there is no 128K, hopefully :D BTW you'll have to reflash the PM3 during your search but in principle no need to flash the bootloader, it'll be safer. Platform PM3OTHER is defined since 21/8/2019 and for older ones you can use PM3EASY introduced since 3/5/2019. I hope you won't have to go that far away.

Thank you! The one I have is in deed a 256K one, I messed up with it in my memory. Anyway, thank you.

iceman1001 commented 4 years ago

How about you share the amiboo dump you are using. And for the sake of saying, PM3 Easy clones has variable quality, you get what you pay for, and the HF antenna has been known to be bad with simulations. I will not spend time on looking into this issue.

RedL0tus commented 4 years ago

@iceman1001

I got them from here: https://nfc-bank.com/bins.php?do=download&downloadid=1988

Yea... I know PM3 Easy is kind of a mess when talking about product quality, but doubt it is not the case here since the older firmware does work and I get somewhat consistent result between scans...

I would like to help anyway.

iceman1001 commented 4 years ago

Hm,, the NFC Tools Pro pictures seem to be showing the same values. What is it that is different with them?

Once you exit sim from RRG/Iceman. save a trace log and share here.

trace list 14a
trace save   my_amiboo.trace

RedL0tus commented 4 years ago

Hm,, the NFC Tools Pro pictures seem to be showing the same values. What is it that is different with them?

Once you exit sim from RRG/Iceman. save a trace log and share here.
trace list 14a
trace save   my_amiboo.trace

The RRG fork's scan result lacks the last column with the title "Memory information". I'm not sure what that means though, it's just the only difference I can find 🤣🤣🤣

Terminal log:

[=] Session log /Users/kay/.proxmark3/logs/log_20200613.txt
[=] Loading preferences...
[+] loaded from JSON file /Users/kay/.proxmark3/preferences.json
[=] Using UART port /dev/tty.usbmodemiceman1
[=] Communicating with PM3 over USB-CDC

  ██████╗ ███╗   ███╗█████╗
  ██╔══██╗████╗ ████║╚═══██╗
  ██████╔╝██╔████╔██║ ████╔╝
  ██╔═══╝ ██║╚██╔╝██║ ╚══██╗     ❄️  iceman@icesql.net
  ██║     ██║ ╚═╝ ██║█████╔╝    https://github.com/rfidresearchgroup/proxmark3/
  ╚═╝     ╚═╝     ╚═╝╚════╝   bleeding edge ☕

 [ Proxmark3 RFID instrument ]

 [ CLIENT ]
  client: RRG/Iceman/master/v4.9237-363-ge0eaff45 2020-06-13 13:31:30
  compiled with Clang/LLVM 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.32.62) OS:OSX ARCH:x86_64

 [ PROXMARK3 ]

 [ ARM ]
  bootrom: RRG/Iceman/master/v4.9237-363-ge0eaff45 2020-06-13 13:31:23
       os: RRG/Iceman/master/v4.9237-363-ge0eaff45 2020-06-13 13:31:32
  compiled with GCC 9.3.1 20200408 (release)

 [ FPGA ]
  LF image built for 2s30vq100 on 2020-02-22 at 12:51:14
  HF image built for 2s30vq100 on 2020-01-12 at 15:31:16

 [ Hardware ]
  --= uC: AT91SAM7S256 Rev B
  --= Embedded Processor: ARM7TDMI
  --= Nonvolatile Program Memory Size: 256K bytes, Used: 228952 bytes (87%) Free: 33192 bytes (13%)
  --= Second Nonvolatile Program Memory Size: None
  --= Internal SRAM Size: 64K bytes
  --= Architecture Identifier: AT91SAM7Sxx Series
  --= Nonvolatile Program Memory Type: Embedded Flash Memory

[usb] pm3 --> data tune
[=] Measuring antenna characteristics, please wait...
 🕚  10
[+] LF antenna: 25.60 V - 125.00 kHz
[+] LF antenna: 19.60 V - 134.83 kHz
[+] LF optimal: 25.60 V - 125.00 kHz
[+] LF antenna is OK

[+] HF antenna: 25.30 V - 13.56 MHz
[+] HF antenna is OK

[+] Displaying LF tuning graph. Divisor 88 is 134.83 kHz, 95 is 125.00 kHz.

[usb] pm3 --> hf mf eload u zelda
[+] loaded 1020 bytes from text file zelda.eml
[=] detected old mfu dump format
[+] old mfu dump format was converted to 243 blocks
[=] MFU dump file information
[=]      version  00 04 04 02 01 00 11 03
[=]         tb 0  01 00
[=]         tb 1  00
[=]    counter 1  00 00 00  - tearing 0x00
[=]    counter 2  00 00 00  - tearing 0x00
[=]    counter 3  00 00 00  - tearing 0x00
[=]    signature  92 58 0B 4C 45 A9 C4 2F A9 01 45 CE 5E 5F 9C 43 09 A4 3D 47 D2 32 A3 D1 68 CB AD E6 7F 81 85 C6
[=]         data  04 CF 1C 5F 4A E0 4C 80 ... (only first 8 bytes showing)
[=]     max data page 242,  data len 972 bytes
[=]  file header size 56
[=] ----------------------------------------------
[=] Uploading to emulator memory
.................................................................................................................................................................................................................................................................

[+] Done
[usb] pm3 --> hf 14a sim t 7 u 04CF1C4AE04C80
[+] Emulating ISO/IEC 14443 type A tag with 7 byte UID (04 CF 1C 4A E0 4C 80 )
[=] Press pm3-button to abort simulation
[#] Emulator stopped.  Trace length: 5603
[=] Done
[usb] pm3 --> trace list 14a
[=] downloading tracelog from device
[+] Recorded activity (trace len = 5603 bytes)
[=] Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
[=] ISO14443A - All times are in carrier periods (1/13.56MHz)

      Start |        End | Src | Data (! denotes parity error)                                           | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
          0 |      61680 | Rdr |0f  0f! f0  0f! f0! 0f! 0f  f0  0f  0f! 0f! f0  f0  0f  f0  f0! 0f! 0f!  |     |
            |            |     |f0  0f  f0! 0f  0f! f0  f0! f0  0f  0f  f0! f0  f0  0f! 0f  f0  f0! 0f!  |     |
            |            |     |0f  0f! 0f  0f! 0f  0f! 0f! 0f  f0  f0! 0f! f0  f0! f0! f0! f0  0f  0f   |     |
            |            |     |0f! f0! 0f! f0! 0f  0f  f0! 0f  f0  0f  f0  f0  0f  0f! 0f  0f  0f! f0!  |     |
            |            |     |0f! 0f  0f  0f! f0  0f! f0! f0! 0f! f0! 0f  f0! f0  f0  0f  f0  0f  f0!  |     |
            |            |     |0f! 0f  f0  0f  0f  f0! f0! f0  0f! 0f! 0f  0f! 0f! f0  0f! f0  f0! 0f   |     |
            |            |     |0f! f0! f0  0f! 0f! f0  f0  0f  f0  f0  f0  0f! 0f  f0  0f  0f  f0! f0   |     |
            |            |     |f0! 0f  f0  f0! 0f! f0! 0f! 0f! 0f! 0f! f0! 0f  f0! f0! 0f! 0f! 0f! 0f!  |     |
            |            |     |0f  0f! f0  0f  0f  f0  f0! 0f  f0  f0  0f! f0! 00! ae! 06! 00! 0e  03!  |     |
            |            |     |80! 00  fe! 51  80! c3! 51  be! 06! a0  12! 04! 00  50! 00  57  cd! c0!  |     |
            |            |     |63! 1d! df  06! 20  04  01  00  26  00! 17  26  df  06! 40  09! 02  80!  |     |
            |            |     |44! 00! c0! 13  5a! df  06! a0! 12! 04  00! 50! 00  57! cd  c0! d1! 11!  |     |
            |            |     |ed! 06! e0! 03! 01! 00! 52! 00  85! 1a! ed! 06  40  09! 02! 80! 44! 00!  |     |
            |            |     |c0  19! 55! ed  06  a0  09  02! 00! 93! 20  80  4d! 63! ed! 06  c0  16!  |     |
            |            |     |05! 80  88! 04! cf  1c! 5f  a8  e1! a9  ed  06! 20  29  09  00  93  70   |     |
            |            |     |88  04  cf! 1c  5f! 1b  ad  ab! 00  95! d7! ed  06! c0! 0d  03! 80  04   |     |
            |            |     |da  17  20  bd  10  ee! 06! a0  09! 02  00! 95  20  80  f1! 1e! ee  06!  |     |
            |            |     |c0! 16  05! 80  4a  e0  4c! 80  66! 08! bd  63  ee  06! 20  29  09  00   | !crc|
[usb] pm3 --> trace save my_amiibo.trace
[+] saved 5603 bytes to binary file my_amiibo.trace
[usb] pm3 --> exit

my_amiibo.trace: https://files.salted.fish/public/amibo-trace (SHA512: 9841ee8ab7ad0a1d00690817472f62efbe167d23413cf9ebc27b722f8b862f6657831e25ea815bd62ec626fa7e716db0405a032bfe02836f1b5a9aaad46e9379)

RedL0tus commented 4 years ago

You've a 256K version while RDV4 and other Easy are 512K, there is no 128K, hopefully :D BTW you'll have to reflash the PM3 during your search but in principle no need to flash the bootloader, it'll be safer. Platform PM3OTHER is defined since 21/8/2019 and for older ones you can use PM3EASY introduced since 3/5/2019. I hope you won't have to go that far away.

I tried to find a known working commit in order to start bisecting, but I noticed that the macOS toolchain cannot correctly build the client until a certain commit October 2019 and after that the artifact was too big for my board. The first commit I found that can be correctly built and can be fitted onto my board already has this issue, so... sorry.

iceman1001 commented 4 years ago

nay, you don't need to bisect. I am kind of sure I understand whats going on. Its sadly a mix of things.

dump format,
possible stack-overflow when simulating.

The binary format used for mfu dumps has changed. The dumps from that collection you download / refenced to doesn't have the new header. Which is ok, we just need to get a NTAG215, tearing hardcoded value instead same goes for the PACK.

I pushed some fixes for dump format, which would make it easier. the second is something I am looking into, we did recently a major change in Stacksize on device side.

RedL0tus commented 4 years ago

nay, you don't need to bisect. I am kind of sure I understand whats going on. Its sadly a mix of things.

dump format,

possible stack-overflow when simulating.

The binary format used for mfu dumps has changed. The dumps from that collection you download / refenced to doesn't have the new header. Which is ok, we just need to get a NTAG215, tearing hardcoded value instead same goes for the PACK.

I pushed some fixes for dump format, which would make it easier. the second is something I am looking into, we did recently a major change in Stacksize on device side.

Are there any documentation about the different dump formats? I'm willing to write a converter for and maybe a new and working amiibo simulation tool ( #119 ).

Anyway, a huge thanks to you!

iceman1001 commented 4 years ago

You can pull latest and try your plain and old style dumps together with simulation. It should work nice. Some could have issue with not responding with PACK but the output will be helpful.

ref convert

iceman1001 commented 4 years ago

The amiibo software, basically only need a good integration with the hf mfucommands. Where it could read a tag, decrypt / save, or encrypt / load to sim / load to magic / load to normal tag. Would need to lookup uid etc, but its quite doable.

RedL0tus commented 4 years ago

You can pull latest and try your plain and old style dumps together with simulation. It should work nice. Some could have issue with not responding with PACK but the output will be helpful.

ref convert

I just tried that, and the conversion looks good.

The amiibo software, basically only need a good integration with the hf mfucommands. Where it could read a tag, decrypt / save, or encrypt / load to sim / load to magic / load to normal tag. Would need to lookup uid etc, but its quite doable.

Yea... I saw there was a PoC lua script from here, but it is no longer working (can be a reference though).

iceman1001 commented 4 years ago

re: amiboo the idea is to have it integrated with the client, no lua.

Re: format converts I just realised that for the ppl who dumps now will get the new binary format and if they wanna take that to another device they will need to clean of the header...

RfidResearchGroup / proxmark3

Failed to simulate Amiibo #785

RRG:

Iceman: