Indala Inconsistent Reads

The tag up for read will not show results on lf read or hf read 100% of the time. Only results found on auto. On auto let’s focus on when I get to a good spot. When in a good spot, it will never show the same raw result.

If I run auto in a spot that gives me a raw result the first time, generally it will give me a differing raw result 2/3 of the time or the other 1/3 gives me [=] Failed both LF / HF SEARCH, ie nothing found. Also, I have not received the same raw result twice in the several hours of testing, regardless if I move it or not. I’ve moved it a ton and retested in the same spot a ton. And, every single found result has a Indala indication. Never once a different indication. Best can be told this is Mifare 1K Classic.

Before cloning can even be pitched, we need a consistent raw in absent of a Indala Id, correct? Not once has a single Indala ID been shown, just the varying raw as shown below.

Lastly, lf indala reader has never ever revealed a result despite many 0.5mm movements. Not once. Results are only achieved through auto

Thoughts on next steps and what else can be provided to troubleshoot?

Example successful find:


[usb] pm3 --> auto
[=] lf search

[=] Note: False Positives ARE possible
[=]
[=] Checking for known tags...
[=]
 🕗 Searching for COTAG tag......

[-] ⛔ No data found!
[?] Hint: Maybe not an LF tag?

[=] hf search
[!] ⚠️  No known/supported 13.56 MHz tags found
[=] lf search - unknown
[=] -->  trying  ( 125.00 kHz )

[=] Note: False Positives ARE possible
[=]
[=] Checking for known tags...
[=]
 🕘 Searching for COTAG tag......

[-] ⛔ No data found!
[?] Hint: Maybe not an LF tag?

[=] -->  trying  ( 134.83 kHz )

[=] Note: False Positives ARE possible
[=]
[=] Checking for known tags...
[=]
[=] Odd size,  false positive?
[+] Indala (len 128)  Raw: 80000000000410000014001000000200200bfffffffdfffffffeffff


[+] Valid Indala ID found!

[=] Couldn't identify a chipset

[#] LF Sampling config
[#]   [q] divisor............. 95 ( 125.00 kHz )
[#]   [b] bits per sample..... 8
[#]   [d] decimation.......... 1
[#]   [a] averaging........... no
[#]   [t] trigger threshold... 0
[#]   [s] samples to skip..... 0
[#]

Indala is notorious for false positives, if it isn’t consistent, you can probably ignore it

Make sure the PM3 isn’t sitting on/near/around something metal which might be messing with the field

Similarly, move the tag all over/on/near/around/under the PM3, try leaving an air gap between the antenna and the tag

Can you post a picture of the tag? Or does it have any branding or identifying marks on it?
And also the start up text of the PM3 client?
And also the output from hw tune?

Do you have any other cards to test the PM3 with to make sure it’s working correctly? It may have come with some

2 Likes

pm3 load

[=] Session log /Users/ZYX/.proxmark3/logs/log_2025063NUM.txt
[+] loaded /Users/XYZ/.proxmark3/preferences.json
[+] Using UART port /dev/tty.usbmodem1101
[+] Communicating with PM3 over USB-CDC

8888888b. 888b d888 .d8888b.
888 Y88b 8888b d8888 d88P Y88b
888 888 88888b.d88888 .d88P
888 d88P 888Y88888P888 8888"
8888888P" 888 Y888P 888 "Y8b.
888 888 Y8P 888 888 888
888 888 " 888 Y88b d88P
888 888 888 “Y8888P”

[ ghost.713! :coffee: ]

[ Proxmark3 ]

MCU....... AT91SAM7S512 Rev B
Memory.... 512 KB ( 77% used )
Target.... device / fw mismatch

Client.... Iceman/master/v4.20469-49-g5b37fe8af 2025-06-29 23:32:03
Bootrom... Iceman/master/v4.20469-49-g5b37fe8af-suspect 2025-06-29 23:31:54 626fd9e51
OS........ Iceman/master/v4.20469-49-g5b37fe8af-suspect 2025-06-29 23:31:57 626fd9e51

[=] No previous history could be loaded

1 Like

That’s a problem, you’ll need to resolve that first

Did you flash the firmware to the PM3 with pm3-flash-all?

If you don’t have an RDV4, did you remember to edit Makefile.platform?

Are you on windows?

2 Likes


Tag shows no identifiers front and back.
Mac OS

Adding in, when I redo flash-all I still see
Target… device / fw mismatch

1 Like

This is the important part. Are you using pre-compiled binaries or are you pulling down the source code from the repo and compiling it?

Do you have an RDV4? If not, you must modify your makefile to tell the compiler to compile the right firmware version for your hardware.

The above guide has a section on how to do this.

2 Likes

If you are using the precompiled binaries make sure you’re using the correct ones:

RDV4

Generic

Scratch that, those are for Windows, not Mac, my bad

If you don’t know which you have:

If it doesn’t look like the RDV4 you have a “generic”

4 Likes

Definitely made progress. The Makefile error on my part is fixed and yes I’m using the Easy device on Mac OS:


MCU....... AT91SAM7S512 Rev B
    Memory.... 512 KB ( 68% used )
    Target.... PM3 GENERIC

    Client.... Iceman/master/v4.20469-49-g5b37fe8af 2025-06-30 12:15:46
    Bootrom... Iceman/master/v4.20469-49-g5b37fe8af-suspect 2025-06-30 12:15:37 626fd9e51
    OS........ Iceman/master/v4.20469-49-g5b37fe8af-suspect 2025-06-30 12:15:40 626fd9e51

[usb] pm3 --> hw tune

[=] -------- Reminder ----------------------------
[=] `hw tune` doesn't actively tune your antennas.
[=] It's only informative.
[=] Measuring antenna characteristics...
 🕛   9

[=] -------- LF Antenna ----------
[+] 125.00 kHz ........... 24.16 V
[+] 134.83 kHz ........... 17.14 V
[+] 122.45 kHz optimal.... 24.83 V
[+]
[+] Approx. Q factor measurement
[+] Frequency bandwidth... 6.3
[+] Peak voltage.......... 7.2
[+] LF antenna............ ok

[=] -------- HF Antenna ----------
[+] 13.56 MHz............. 15.65 V
[+]
[+] Approx. Q factor measurement
[+] Peak voltage.......... 4.6
[+] HF antenna ( ok )

[=] -------- LF tuning graph ------------
[+] Orange line - divisor 95 / 125.00 kHz
[+] Blue line - divisor   88 / 134.83 kHz


[=] Q factor must be measured without tag on the antenna

I am able to clone, I believe. Replaced actual raw text:

lf indala clone -r <raw>

[usb] pm3 --> auto
[=] lf search

[=] Note: False Positives ARE possible
[=]
[=] Checking for known tags...
[=]
[=] DEBUG: detectindala | 35
[-] ⛔ No known 125/134 kHz tags found!
[=] Couldn't identify a chipset
[=] hf search
[!] ⚠️  No known/supported 13.56 MHz tags found
[=] lf search - unknown
[=] -->  trying  ( 125.00 kHz )

[=] Note: False Positives ARE possible
[=]
[=] Checking for known tags...
[=]
[=] DEBUG: detectindala | 40
[-] ⛔ No known 125/134 kHz tags found!
[=] Couldn't identify a chipset
[=] -->  trying  ( 134.83 kHz )

[=] Note: False Positives ARE possible
[=]
[=] Checking for known tags...
[=]
[=] Odd size,  false positive?
[+] Indala (len 65)  Raw: <raw>


[+] Valid Indala ID found!

[=] Couldn't identify a chipset

[#] LF Sampling config
[#]   [q] divisor............. 95 ( 125.00 kHz )
[#]   [b] bits per sample..... 8
[#]   [d] decimation.......... 1
[#]   [a] averaging........... no
[#]   [t] trigger threshold... 0
[#]   [s] samples to skip..... 0
[#]
[usb] pm3 --> lf indala reader
[usb] pm3 -->

When I try the new blue fob at the door reader, there is no response at all. Should I try a different type of tag?

1 Like

Since that fob looks kinda thin, I suspect that it’s a high frequency tag. However, this can be wrong.

The Proxmark3 Easy has 2 antennas, the coil for low frequency fobs, and the BCB trace antenna for high frequency ones.

I suggest placing the fob on the LF coil and running an lf search, then moving the fob to the HF side of the Proxmark3 Easy, and running a hf search command.

If that fails, the lf tune and hf tune commands should help you locate the best location for reading the tag. You want to leave it on the spot that gives you the lowest voltage reading.

3 Likes

Sensational, that did the trick. I tried putting the original between the lowest board and the HF board, got what I was suspecting originally:

[usb] pm3 --> hf search
 🕙  Searching for ISO14443-A tag...
[=] ---------- ISO14443-A Information ----------
[+]  UID: <REMOVED>   ( ONUID, re-used )
[+] ATQA: 00 04
[+]  SAK: 08 [2]
[+] Possible types:
[+]    MIFARE Classic 1K
[=]
[=] Proprietary non iso14443-4 card found
[=] RATS not supported
[+] Prng detection..... hard

[=]  IC signature public key name: NXP MIFARE Classic MFC1C14_x
[=] IC signature public key value: <REMOVED>
[=]     Elliptic curve parameters: secp128r1
[=]              TAG IC Signature: <REMOVED>
[+]        Signature verification: successful

[?] Hint: Try `hf mf info`


[+] Valid ISO 14443-A tag found

If I’m correct, next would be to do what was highlighted in this video, correct?
I’m exhausted, will update again in a day or two.

1 Like

autopwn got me all of the decoded keys. No sectors with -------
And only two sectors with FFFFFFFFFFFF. Looks ready for cload
However, there is no eml file, just a json and bin file. I tried cload help but don’t see anything for eml. I tried loading the json but wasn’t expecting that to work. Two issues might be the eml and is the blue fob that came with the Easy package a Classic 1K but not a magic one?

[+] Generating binary key file
[+] Found keys have been dumped to `/Users/xyz/hf-mf-26C23BB1-key-001.bin`
[=] --[ FFFFFFFFFFFF ]-- has been inserted for unknown keys where res is 0
[=] Transferring keys to simulator memory ( ok )
[=] Dumping card content to emulator memory (Cmd Error: 04 can occur)
[=] downloading card content from emulator memory
[+] Saved 1152 bytes to binary file `/Users/xyz/hf-mf-26C23BB1-dump-001.bin`
[+] Saved to json file /Users/xyz/hf-mf-26C23BB1-dump-001.json
[=] Autopwn execution time: 104 seconds

[usb] pm3 --> hf mf cload -f /Users/xyz/hf-mf-26C23BB1-dump-001.json
[+] loaded `/Users/xyz/hf-mf-26C23BB1-dump-001.json`
[=] Copying to magic gen1a MIFARE Classic 1K
[=] .[#] wupC1 error
[!] ⚠️  Can't set magic card block: 0
[?] Hint: Verify that it is a GDM and not USCUID derivative
[usb] pm3 --> hf search
 🕚  Searching for ISO14443-A tag...
[=] ---------- ISO14443-A Information ----------
[+]  UID: <REMOVED>   ( ONUID, re-used )
[+] ATQA: 00 04
[+]  SAK: 08 [2]
[+] Possible types:
[+]    MIFARE Classic 1K
[=]
[=] Proprietary non iso14443-4 card found
[=] RATS not supported
[+] Prng detection..... weak

[?] Hint: Try `hf mf info`

[+] Valid ISO 14443-A tag found

[usb] pm3 --> hf mf info

[=] --- ISO14443-a Information -----------------------------
[+]  UID: <REMOVED>
[+] ATQA: 00 04
[+]  SAK: 08 [1]

[=] --- Keys Information
[+] loaded 2 user keys
[+] loaded 61 hardcoded keys
[+] Sector 0 key A... FFFFFFFFFFFF
[+] Sector 0 key B... FFFFFFFFFFFF
[+] Sector 1 key A... FFFFFFFFFFFF
[+] Backdoor key..... <REMOVED>
[+] Block 0.... BB<REMOVED>1D | .�.t�.�.

[=] --- Fingerprint
[+] Fudan FM11RF08

[=] --- Magic Tag Information
[=] <n/a>

[=] --- PRNG Information
[+] Prng....... weak

1 Like

The eml file format has been removed, either of the other two formats will work in its place

Is definitely a problem for cloning :classic_tongue:

2 Likes

The json reports:

"FileType": "mfc v2",

Any recommendations on Amazon or elsewhere for the right fobs to order? I noticed that putting “magic” in Amazon search for Mifare Classic 1K fobs didn’t change the search results much so I’m not certain which to order. And that FileType should still correlate to cload command, correct?

1 Like

DT sells a test card pack which has some magic cards in it:

1 Like

Update. Cloning with the correct card has worked on the first reader I tested against. Works perfectly when tested on the reader.

The second reader, which I thought would be less secure but which uses the same original fob, did not show any response to the card. So, I am looking for hints in the 16 sectors for what I could still need to run, possibly a specific block write command?

Commands from the clone:

[usb] pm3 --> hf search
 🕖  Searching for ISO14443-A tag...
[=] ---------- ISO14443-A Information ----------
[+]  UID: <CONFIRMED_TO_MATCH>   ( ONUID, re-used )
[+] ATQA: 00 04
[+]  SAK: 08 [2]
[+] Possible types:
[+]    MIFARE Classic 1K
[=]
[=] Proprietary non iso14443-4 card found
[=] RATS not supported

[+] Magic capabilities... Gen 1a
[+] Magic capabilities... Gen 4 GDM / USCUID ( ZUID Gen1 Magic Wakeup )
[+] Prng detection..... weak

[usb] pm3 --> hf mf autopwn

[!] ⚠️  Known key failed. Can't authenticate to block   0 key type A
[!] ⚠️  No known key was supplied, key recovery might fail
[+] loaded 5 user keys
[+] loaded 61 hardcoded keys
[=] Running strategy 1
[=] .^[[C....
[=] Running strategy 2
[=] .....
[+] Target sector   0 key type A -- found valid key [ FFFFFFFFFFFF ] (used for nested / hardnested attack)
[+] Target sector   0 key type B -- found valid key [ FFFFFFFFFFFF ]
[+] Target sector  15 key type A -- found valid key [ FFFFFFFFFFFF ]
[+] Target sector  15 key type B -- found valid key [ FFFFFFFFFFFF ]

[+] Found 1 key candidate

... valid keys found, removed

[+] -----+-----+--------------+---+--------------+----
[+]  Sec | Blk | key A        |res| key B        |res
[+] -----+-----+--------------+---+--------------+----
[+]  000 | 003 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D

001 - 013 decoded and matching

[+]  014 | 059 | decoded, different from 1-13 | N | decoded | N
[+]  015 | 063 | FFFFFFFFFFFF | D | FFFFFFFFFFFF | D
[+] -----+-----+--------------+---+--------------+----
[=] ( D:Dictionary / S:darkSide / U:User / R:Reused / N:Nested / H:Hardnested / C:statiCnested / A:keyA  )


[+] Generating binary key file
[+] Found keys have been dumped to `/Users/xyz/hf-mf-26C23BB1-key-002.bin`
[=] --[ FFFFFFFFFFFF ]-- has been inserted for unknown keys where res is 0
[=] Transferring keys to simulator memory ( ok )
[=] Dumping card content to emulator memory (Cmd Error: 04 can occur)
[=] downloading card content from emulator memory
[+] Saved 1024 bytes to binary file

No response at all, or a rejection?

Are you running this against the clone? Since it’s a Gen1 you can use hf mf cview instead

1 Like

No response at all. It is a larger ICT Reader. I am running autopwn against the clone. What should I look for in the cview output against the clone? Sorry, wasn’t sure if it is ok output that here in the forum or not.

cview output from the clone:

Are you sure your original fob isn’t dual frequency and the second reader is just not HF or reacting to HF (might be putting field out but not doing anything with it)? Have you tested both readers with RDC?

3 Likes

It might have something to do with SAK Swapping:

Since it looks like you have a Gen4 GDM card, you should be able to tinker with the SAK, I believe

2 Likes