It may be the same issue you had with approxmark… a coupling problem. Have you tried different angles and approaches?
3 Likes
I know you guys have to debug from the very top, but I feel like this reader isn’t the issue here.
Video of fob: Watch fob | Streamable
Video of implant: Watch implant | Streamable
2 Likes
You’re moving awfully fast in the video…
Just a heads up, every time someone says it works fine with my badge/fob/whatever but doesn’t work with the implant we all groan. Because we’ve addressed this more times than we can count. : )
Edited to add: No one suggested it was the reader.
3 Likes
Point taken 
Use to work in IT Support so I know how often power-cycling actually fixes the issue!
I just tried 10x slower, and on a different door/reader (but identical setup). And still no beeps 
Is there another ID/flag that this reader might be looking for? Getting it identical to the fob in terms of ID/ATQA/SAK I thought would definitely fix it.
You have a flipper, right? Do you have the NFC Magic app? You can use that to save and clone it to the UG4. Also, do you have a hf field detector keychain? Have you used it with the readers? It’ll tell you where to target your efforts.
3 Likes
Just for fun id try tapping the implant against the side in both orientations.
Also rather than slide the implant around on the surface, try tapping, removing, and tapping again in a different orientation or location. Sometimes tapping around creates an awkward coupling spasm basically that kind of messes up the iso selection process
4 Likes
Good suggestion because I know there’s like a 2 second cool-down when it gives a red beep.
But still can’t get it to do anything?! Also tried a 3rd reader on another door and same thing.
I’ll find my Flipper and report back.
okok,
youve set the uid sak and atqa to match, and your chip is configured to be a mifare classic 1k with a 7 byte UID,
have you actually dumped the memory of your original tag? run hf mf autopwn on it to get the memory dump & we can proceed from there with getting it loaded onto your ug4
none of your test cards elicit any kind of respond from the reader.
ok so this means that your reader will not react to just an iso14443a uid within the field, the desfire and ntag share the same UID length and wake up procedure in line with your original MFP (SL1 MFC CL2) so what we learn from this is that your reader is going to ignore chips that it does not authorise past the initial wake up.
i would recommend emulating (using your proxmark, the flipper is… not the best at mifare classic emulation) the data dump file retrieved from the above command to be sure that the reader is going to accept the mifare classic data, your chip is a mifare plus which is emulating a mifare classic, this means the reader could be using the mifare classic data and/or it could be probing further into the mifare plus side of the chip for part of its authentication. once you’ve done that emulation we can analyse the trace of communications to see what the reader is thinking when we present to it.
following that in the event that the reader does accept the mifare classic data, you’d then put this on the implant itself making sure you’ve got a 1-1 clone of the working emulated dump file, this will cut out all potentialities that the reader is ignoring the chip because it is failing authentication.
if the reader is requesting the mifare plus authentication then the UG4 wouldn’t be able to work in this instance unless youre able to talk to the system administrator and have them enroll the credential against your user profile under special circumstances of just checking for the UID etc.
and finally, if the data matches 1-1, we’ve confirmed mifare classic data is accepted via emulation and the unimplanted UG4 still isn’t working then the only logical conclusion is that the UG4 is unable to meet the requirements of the reader in terms of timing. this is unfortunately a possibility with UMC chips on some readers, notably battery-powered readers, readers that are receiving the bare minimum acceptable voltage, low quality hardware 3rd market readers and readers that use a deep sleep energy saving mode.
the UMC is a much more complex chip in terms of magic functionality so they have been observed with these issues (i myself have seen it with cards, a friend of mine experienced his ug4 not working with the saflok mifare classic hotel cards at defcon etc)
-breathe out-
ok ok that all sounds like a lot of brain twisting confusion soup, i apologise for the yap but i wanted to put it on paper so we have a game plan.
i am happy to walk you through all of the above step by step so we can get your implant configured & tested and see if we can get it working.
I’m expecting this process to be a good few back and fourths so we may want to take this to the private messages section of the forum, I’m also available on discord & signal if either of those are easier for you.
6 Likes
Please keep it here if ok, it is very interesting and likely to help others.
4 Likes
Just noting that I can actually enroll ID’s in the system (don’t ask how). So I don’t even need to clone this exactly.
[usb] pm3 --> hf mf autopwn
[!] ⚠️ no known key was supplied, key recovery might fail
[+] loaded 5 user keys
[+] loaded 61 keys from hardcoded default array
[=] running strategy 1
[=] running strategy 2
[=] .......
[-] ⛔ No usable key was found!
2 Likes
I actually have a spare card that beeps (however it won’t let me enroll it which is a separate issue):
[usb] pm3 --> hf mf info
[=] --- ISO14443-a Information ---------------------
[+] UID: 42 AA BB DD
[+] ATQA: 00 04
[+] SAK: 08 [2]
[=]
[=] --- Tag Signature
[=] IC signature public key name: NXP MIFARE Classic MFC1C14_x
[=] IC signature public key value: 044F6D3F294DEA5737F0F46FFEE88A356EED95695DD7E0C27A591E6F6F65962BAF
[=] Elliptic curve parameters: NID_secp128r1
[=] TAG IC Signature: 8583CA0FA1F7DB6ED4AFB0C11204CD8628CBB6D0A429306C50C3616120EC4500
[+] Signature verification: successful
[=] --- Keys Information
[+] loaded 2 user keys
[+] loaded 61 keys from hardcoded default array
[=] <N/A>
[=] --- Magic Tag Information
[=] <N/A>
[=] --- PRNG Information
[+] Prng................. hard
But this might give some clues for what the reader is looking for.
2 Likes
I forgot how good the Flipper is!
It read my fob as:
MIFARE Classic 1K
UID: 11 22 33 44 55 66 77
Keys Found: 32/32
Sectors Read: 16/16
But when emulating the fob with the Flipper, I just got a red beep and weirdly doesn’t log anything in the system events.
Next, I tried emulating with the Proxmark with hf mf sim -u 11223344556677 --1k but it doesn’t even beep (same result as the implant by itself).
Not sure if I need to do a more advanced emulation with the keys retrieved from the Flipper?
I was able to download the Flipper dump to my computer also:
Filetype: Flipper NFC device
Version: 4
# Device type can be ISO14443-3A, ISO14443-3B, ISO14443-4A, ISO14443-4B, ISO15693-3, FeliCa, NTAG/Ultralight, Mifare Classic, Mifare Plus, Mifare DESFire, SLIX, ST25TB
Device type: Mifare Classic
# UID is common for all formats
UID: 11 22 33 44 55 66 77
# ISO14443-3A specific data
ATQA: 00 44
SAK: 08
# Mifare Classic specific data
Mifare Classic type: 1K
Data format version: 2
# Mifare Classic blocks, '??' means unknown data
Block 0: 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55
...
Block 63: 00 11 22 33 44 55 66 77 88 99 00 11 22 33 44 55
Let me know what’s next I can try! Appreciate all the help.
1 Like
What the… this is sus… it’s also 7 bytes and Mifare classic are 4 bytes
2 Likes
1K 7B is totally normal for Mifare Plus (SL1) in personalisation mode, its what Mifare Classic CL2 is, and this is what he’s got
(also 1k can have 7 byte UIDs anyway [so can 4ks])
4 Likes
3 Likes
Sooooo. What would I test next?