N2 Elite
N2 Elite is sold as a game cheating product, called previously Amiiqo, an name probably too close to the original targeted game Amiibo.
I'm not interested at all in its gaming aspects but it's primarily a (multiple) NTAG215 emulator and in that respect, I'm very curious about that product :)
Intro
It's a small round passive device with one button. It can emulate up to 200 NTAG215 and can be programmed via an Android app or, if you buy their additional reader, via a PC application: N2 Manager for Windows or Mac.
Credits: I heard about it by reading a 3-page article of Patrick Gueulle in the French revue Le Virus Informatique #28. In that article, the author revealed how the emulator could be used to emulate any 7-byte UID or even a 4-byte UID (we'll come to that later) and he's providing two programs written in Basic; apparently Patrick remained true to himself ;)
N2 & NTAG Resources
- Official
- Official site has a list of shops. Mine came from Cyprus (Playmods.co.uk) and was delivered in 4 days to Belgium.
- NTAG213/215/216 datasheet
Three versions of the Android app so far:
- ed5fc865e98b33e584860b39cb70ddb6 Amiiqo_1.0.apk
- 44d1ea2fd342c7faa3af81f473eada12 Amiiqo_1.1.apk
- f39a091be603058329b085f1b0382caa Amiiqo_1.2.apk
Versions 1.1 and 1.2 contain both the same fw image to update older N2 Elite tags, see below the section about firmware.
Amiibo Resources
Nothing really useful for us but for sake of completion:
- Amiibo tags
- Unofficial sw
- Alternate manager: http://www.maxconsole.com/maxcon_forums/threads/291976-Amiiqo-Manager
- Parsing library: https://github.com/Falco20019/libamiibo
Hardware
Device was sold previously under the name Amiiqo, and they insist this is the same hardware as the N2 Elite. Nevertheless there are apparently two revisions of the product:
- V1, preloaded with 10 amiibo figurines
- V2, empty, and an alien face printed on the PCB
I got a V2.
Patrick Gueulle mentions the QFN24 chip has a mark "SX3" but mine is completely black. Under the microscope he found two references on the die: "G4830H001I" and "DI 503 03".
Traces
Let's trace some transactions between the Android app and the device with a Proxmark3.
I've discarded the anticol and HALT/WUPA activities.
Discovery
Rdr | 30 02 10 8b | ok | READBLOCK(2)
Tag | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | |
| 37 cb | ok |
Rdr | 60 f8 32 | ok | EV1 VERSION
Tag | 00 04 04 02 01 00 11 03 01 9e | ok |
Rdr | 55 d6 54 | ok | ?
Tag | 00 01 00 03 47 3e | ok |
Rdr | 43 61 21 | ok | MAGIC WUPC2
Tag | 21 4b 87 02 52 3d 0d 10 16 3a 24 ff ff ff ff ff | |
| e4 e7 | ok |
Rdr | 3b 15 16 00 8e a7 | ok | ?
Tag | ff ff ff ff ff ff ff ff 5f d2 | ok |
When asking the app to show the tag ID it returns 214b8702523d0d10163a24.
Lock
Rdr | 46 cc 76 | ok | ? Tag | 0a a4 fe | |
Unlock
You need to press the button once the app discovers the tag and maintain it pressed. You've 2 seconds.
Rdr | 44 de 55 | ok | ? 2 secs pause. Rdr | 45 57 44 | ok | ? Tag | 0a a4 fe | |
Update number of banks
When changing the number of available banks from 1 to 2:
Rdr | a9 02 55 45 | ok | ? Tag | 0a a4 fe | |
Now the discovery phase has two such commands:
Rdr | 3b 15 16 00 8e a7 | ok | ? Tag | ff ff ff ff ff ff ff ff 5f d2 | ok |. Rdr | 3b 15 16 01 07 b6 | ok | ? Tag | ff ff ff ff ff ff ff ff 5f d2 | ok |.
Read a dump
Rdr | 30 00 02 a8 | ok | READBLOCK(0)
Tag | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | |.
| 37 cb | ok |.
Rdr | 30 04 26 ee | ok | READBLOCK(4)
Tag | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | |.
| 37 cb | ok |.
Rdr | 30 08 4a 24 | ok | READBLOCK(8)
Tag | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | |.
| 37 cb | ok |.
...
Rdr | 30 80 0a 2c | ok | READBLOCK(128)
Tag | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | |.
| 37 cb | ok |.
Rdr | 30 84 2e 6a | ok | READBLOCK(132)
Tag | ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | |.
| 37 cb | ok |.
Write a dump
Rdr | 1b ff ff ff ff 63 00 | ok | PWD-AUTH KEY: 0xffffffff Tag | 80 80 64 16 | |. Rdr | a5 00 00 04 c5 a8 e1 69 44 | ok | INCR(0) Tag | 0a a4 fe | |. Rdr | a5 01 00 da aa 2b 80 d9 8d | ok | INCR(1) Tag | 0a a4 fe | |. Rdr | a5 02 00 db 48 00 00 95 62 | ok | INCR(2) Tag | 0a a4 fe | |. Rdr | a5 03 00 e1 10 12 00 e2 15 | ok | INCR(3) Tag | 0a a4 fe | |. Rdr | a5 04 00 01 03 a0 10 17 ce | ok | INCR(4) Tag | 0a a4 fe | |. Rdr | a5 05 00 44 03 00 fe 53 13 | ok | ? Tag | 0a a4 fe | |. Rdr | a5 06 00 00 00 00 00 e0 8a | ok | ? Tag | 0a a4 fe | |. ... Rdr | a5 85 00 ff ff ff ff a6 70 | ok | ? Tag | 0a a4 fe | |. Rdr | a5 86 00 ff ff ff ff db 7c | ok | ? Tag | 0a a4 fe | |.
Commands
We'll present the commands understood so far, exemplified with pn53x-tamashell scripts (to be used with libnfc and a compatible reader)
NTAG Commands
0x60: GET_VERSION
#!/usr/bin/pn53x-tamashell 4a 01 00; Select tag 42 60; Get Version
0x3C: READ_SIG
Read ECC signature of NTAG.
#!/usr/bin/pn53x-tamashell 4a 01 00; Select tag 42 3c; Read ECC signature
0x30: READ
It reads 4 pages (16 bytes) starting from the given page
#!/usr/bin/pn53x-tamashell 4a 01 00; Select tag 42 30 00 42 30 04 42 30 08 42 30 0c ... 42 30 80 42 30 84
0x3A: FAST_READ
Syntax:
3a <start page> <stop page (included)>
Theoretically a bank could be accessed in one single command but it depends on the reader. With libnfc readers, don't read more than 63 pages (252 bytes) at once.
Reading entirely the tag:
#!/usr/bin/pn53x-tamashell 4a 01 00; Select tag 42 3a 00 1f 42 3a 20 3f 42 3a 40 5f 42 3a 60 7f 42 3a 80 86
0xA2: WRITE
Syntax:
a2 <page> <data>
#!/usr/bin/pn53x-tamashell 4a 01 00; Select tag 42 a2 84 01 02 03 04; Write 01020304 page #84
0x1B: PWD_AUTH
Syntax:
1b <4-byte pwd>
N2 returns always 8080
N2 special commands
0x55: N2_GET_INFO
#!/usr/bin/pn53x-tamashell 4a 01 00; Select tag 42 55; Get N2 info
Answer is 4 bytes as seen in the traces above, e.g.:
00 01 00 03
- byte 1:?
- byte 2: number of active banks
- byte 3: ?
- byte 4: FW version?
It could be that older N2 return only 2 bytes.
0x43: N2_GET_ID
#!/usr/bin/pn53x-tamashell 4a 01 00; Select tag 42 43; Get N2 ID
Answer is 16 bytes as seen in the traces above, e.g.:
21 4b 87 02 52 3d 0d 10 16 3a 24 ff ff ff ff ff
First 11 bytes constitute what's returned as ID by the Android app.
0xA9: N2_SET_BANK_CNT
Syntax:
a9 <nr_of_banks>
#!/usr/bin/pn53x-tamashell 4a 01 00; Select tag 42 a9 c8; Open the 200 banks
0x3B: N2_FAST_READ
Similar to 0x3A FAST_READ but with one extra parameter to specify the bank number so this command can access directly the 200 banks.
Syntax:
3b <start page> <stop page (included)> <bank>
Banks don't need to be active to be accessed.
Theoretically a bank could be accessed in one single command but it depends on the reader. With libnfc readers, don't read more than 63 pages (252 bytes) at once.
#!/usr/bin/pn53x-tamashell 4a 01 00; Select tag 42 3b 00 1f 00; start of bank #0 42 3b 20 3f 00 42 3b 40 5f 00 42 3b 60 7f 00 42 3b 80 86 00 42 3b 87 8f 00; pages above the 540 bytes of bank #0 NTAG215 42 3b 90 af 00; this is actually start of next bank 42 3b 00 1f 01; start of bank #1 42 3b 20 3f 01 42 3b 40 5f 01 42 3b 60 7f 01 42 3b 80 86 01 42 3b 87 8f 01; pages above the 540 bytes of bank #0 NTAG215 42 3b 00 1f 02; start of bank #2 42 3b 20 3f 02 42 3b 40 5f 02 42 3b 60 7f 02 42 3b 80 86 02 42 3b 87 8f 02; pages above the 540 bytes of bank #0 NTAG215 ;etc for remaining 197 banks
This is interesting! Original Android app doesn't care about ECC signature which is left = FFFF..FF but the N2 allows the ECC of a bank to be written via the 8 pages 0x87-0x8e. See command READ_SIG above.
I found no use of page 0x8f so far.
0xA5: N2_WRITE
Similar to 0xA2 WRITE but with one extra parameter to specify the bank number so this command can access directly the 200 banks.
Syntax:
a5 <page> <bank> <data>
Banks don't need to be active to be accessed.
#!/usr/bin/pn53x-tamashell 4a 01 00; Select tag 42 a5 84 00 01 02 03 04; Write 01020304 in bank #00 page #84
0x46: N2_LOCK
#!/usr/bin/pn53x-tamashell 4a 01 00; Select tag 42 46; Lock
Tag should return "0x0a". From now on, special N2 commands are unresponsive.
0x44/0x45: N2_UNLOCK
The procedure seems to be the following: initiate a 0x44, press the button, finalize with 0x45.
#!/usr/bin/pn53x-tamashell 4a 01 00; Select tag 42 44; Prepare unlock // Press N2 button now and keep it pressed for at least 3s p 2000; Pause for 2000ms 4a 01 00; Select tag 42 45; Unlock
The tag will reply with 0x0a if unlock succeeded
0xA7: N2_SELECT_BANK
Selects which bank is the current bank.
Syntax:
a7 <bank>
Tag replies 0x0a
Bank doesn't need to be active to be set as current.
Note: this command was found by brute-force, it's not used by the Android app.
0xAE: ?
Tag replies 0x00
N2 tricks
Swapping banks
In principle one needs to press the button to access the next bank. I got it occasionally working when scanned by the Android app but I couldn't initiate a "next bank" by pressing the button with my libnfc reader. I still don't understand what's the internal state machine of the tag and from which state it reads the button to go to the next bank...
ECC
In the N2_FAST_DUMP we saw that it contains additional pages above the 540-byte pages.
Actually some of them are used to store what is returned by the READ_SIG command:
42 3b 87 8e 00; 32-byte ECC signature of bank #0 NTAG215 42 3b 8f 8f 00; 4 unused bytes? 42 3b 87 8e 01; 32-byte ECC signature of bank #0 NTAG215 42 3b 8f 8f 01; 4 unused bytes?
Example:
#!/usr/bin/pn53x-tamashell // Please put N2 Elite on reader NOW 4a 01 00; Select tag 42 a5 87 00 00 01 02 03; Write over bank #0 ECC 42 a5 88 00 04 05 06 07 42 a5 89 00 08 09 0a 0b 42 a5 8a 00 0c 0d 0e 0f 42 a5 8b 00 10 11 12 13 42 a5 8c 00 14 15 16 17 42 a5 8d 00 18 19 1a 1b 42 a5 8e 00 1c 1d 1e 1f 42 3c; Read ECC signature
UID
UID can be changed by writing bytes in the first few pages.
Theoretically first pages contain also BCC0, BCC1 which should be respectively set to:
- BCC0=0x88^UID0^UID1^UID2
- BCC1=UID3^UID4^UID5^UID6
And that's what the Basic programs of Gueulle are doing.
But actually the N2 will handle the anti-collision properly, no matter how BCC0 and BCC1 are defined, as simply as that!
#!/usr/bin/pn53x-tamashell 4a 01 00; Select tag // Write UID ffffffffffffff: 42 a5 00 00 ff ff ff ff; Write in bank #00 page #00 UID0 UID1 UID2 BCC0 42 a5 01 00 ff ff ff ff; Write in bank #00 page #01 UID3 UID4 UID5 UID6 42 a5 02 00 ff ff ff ff; Write in bank #00 page #02 BCC1 Intl Lck1 Lck2 // Write UID 01020304050607: 42 a5 00 00 01 02 03 00; Write in bank #00 page #00 UID0 UID1 UID2 BCC0 42 a5 01 00 04 05 06 07; Write in bank #00 page #01 UID3 UID4 UID5 UID6 42 a5 02 00 00 00 00 00; Write in bank #00 page #02 BCC1 Intl Lck1 Lck2
Interestingly enough, Gueulle has shown that some systems can be fooled when security is based only on UID, even if they are not using NTAG! E.g.:
- 7-byte Mifare Ultralight
- 7-byte Desfire EV1
- 4-byte Mifare Classic
- 4-byte TypeB PUPI
In those 4-byte cases he simply completes the UID with zeroes.
ShowID
When Android app discovers a N2 tag, it issues what I call a N2_INFO to see how many banks are active, then it issues commands such as:
42 3b 15 16 00; Read 8 bytes from address 0x15 to address 0x16 bank #0
to discover the ID of the Amiibo figures that are stored, because actually the ID is stored in 8 bytes from page 0x15, so we can also get it from the currently active bank, or from an original figure, with:
42 30 15; Read 16 bytes from address 0x15
Compatibility
- N2 doesn't emulate any of the protections (OTP locks, etc) and everything is always fully RW.
- It seems that N2 doesn't support the following legit commands: COMP_WRITE, READ_CNT.
- N2 accepts the command PWD_AUTH with any password, it doesn't matter. It returns 8080. Android app issues a PWD_AUTH using the first 4 bytes of the UID as password before issuing write commands, but as said it doesn't matter, a PWD_AUTH is even not required by N2 before a WRITE.
Firmware
WARNING all the info in this section are unverified and any wrong attempt could probably brick a N2!
Android apps v1.1 and v1.2 contain the same update.apdu file.
I guess it contains apdus supposed to be played by the N2 reader because the app is truncating the apdus before they get sent.
App starts by sending the following commands: (there could be errors here, be very cautious if you want to try anything here...)
f4 49 9b 99 c3 da 57 71 0a 64 4a 9e f8 a2 30 d9 60; GET_VERSION
Then it sends the CAPDUs without the first 5 bytes (I'm not sure if the last byte=0x00 is still part of the CAPDU or not)
And checks the response from the tag, which should be the usual 90 00.
update.apdu is composed of 22 CAPDUs sending 250 bytes of payload each so the firmware image is 5520-byte long unless some bytes are e.g. a CRC.
Truncated CAPDUs sent to the N2:
55 00 00 0C B0 19 01 BD ... 80 29 69 00 55 00 F0 28 90 82 58 97 ... 38 3F 6B 00 55 01 E0 D5 81 02 C2 76 ... CF 69 7F 00 55 02 D0 BC 13 DB 33 D9 ... A0 14 68 00 ... F3 55 13 B0 35 0F 84 D0 ... A0 44 8D 00 55 14 A0 AA D4 9F 00 ED ... FD A2 13 00
Then a last CAPDU:
F0 15 90 95 A2 F4 93 4F 6F D9 77 00
If we isolate what's supposed to be the payload of those CAPDU ([3:-1]), we get 5520 bytes, of which the last 80 repeat themselves as
05 40 B9 3B DD FD A2 13
It looks like a XOR encryption, but so far even XORed back to get 00 or ff it doesn't make much sense :( to be continued...