LFRFID: Indala 224 (resolves #2386)

[Aidan-McNay]

What's new

• Support for the Indala 224 LFRFIF Protocol (code adapted from Indala 26, based on Proxmark3). This should resolve #2386 (as well as hopefully provide some groundwork for later implementing Indala 64)

Verification

• THIS IS WHERE I NEED HELP 😃. I don't actually have access to such a card (yet...in the process), so I would need some help in seeing whether the functionality is correct. I've verified it to the point where the code builds and can be accessed like other protocols, but haven't been able to verify functionality

Checklist (For Reviewer)

• [ ] PR has description of feature/bug or link to Confluence/Jira task
• [ ] Description contains actions to verify feature/bugfix
• [ ] I've built this code, uploaded it to the device and verified feature/bugfix

[skotopes]

@Aidan-McNay nor do we have those cards. And it's going to be quite challenging to get them.

@doomwastaken looks like we need your help here too.

[Aidan-McNay]

(Just saw linting - will fix!)

I have a friend who I believe has them, so I can try to get ahold of one. In the meantime, I know that you can write the data/protocol to T5577 cards via Proxmark3 as well, so if other people have those, that could also be an avenue? Thanks in advance for the support!

[doomwastaken]

On it, will try to ask around about these cards

[DrZlo13]

Doesn't work with the example card that comes with the proxmark help.

[usb] pm3 --> lf indala clone
   ...
   lf indala clone -r 80000001b23523a6c2e31eba3cbee4afb3c6ad1fcf649393928c14e5
   
[usb] pm3 --> lf indala clone -r 80000001b23523a6c2e31eba3cbee4afb3c6ad1fcf649393928c14e5
[=] Preparing to clone Indala 224 bit to T55x7 raw 80000001B23523A6C2E31EBA3CBEE4AFB3C6AD1FCF649393928C14E5
[+] Blk | Data
[+] ----+------------
[+]  00 | 000820E0
[+]  01 | 80000001
[+]  02 | B23523A6
[+]  03 | C2E31EBA
[+]  04 | 3CBEE4AF
[+]  05 | B3C6AD1F
[+]  06 | CF649393
[+]  07 | 928C14E5
[+] Done
[?] Hint: try `lf indala reader` to verify

[usb] pm3 --> lf indala reader
[+] Indala (len 224)  Raw: 80000001b23523a6c2e31eba3cbee4afb3c6ad1fcf649393928c14e5

[DrZlo13]

Here I am attaching the raw psk record of this card, you can upload this file to your flipper and use the below command in CLI to test and debug your decoder.

rfid raw_analyze /ext/lfrfid/indala_224.psk.raw

indala_224.psk.raw.zip

[Giraut]

I have a genuine Indala 224 tag (we use them at work) and it's also cloned into my T5577 implant.

Neither of them are read.

[zinongli]

Hi all! I managed to get a reading with CLI raw_analyze after some minor debugging.

If you look into PM3’s Indala code carefully, you can see that the preamble for indala 26 is <one 1, one 0, one 1, twenty nine 0s, another 1>. That’s 33 bits, not 32 bit and not thirty 0s as mistakenly written in this code.

Also, this is Indala 224. According to PM3’s code, it’s preamble is <one 1, twenty nine 0s>. Period. The size is 30-bit. It shouldn’t have been using indala26’s preamble to begin with.

The current preamble checker can be made simpler. I used get_bits_32() to get 30 bits from the data starting from position 0, compared it to <one 1, twenty nine 0>, return true if true and vice versa. And it read just fine. I believe this is also how it's done in PM3.

can_be_decoded() is weird: after passing the initial preamble check, it checks preamble again starting from the last+1 bit. I can understand it’s for checking preamble repetition, but the buffer size only fits one repetition. It will never return true by comparing nothingness with the preamble.

And even if implemented correctly, this check will still be unnecessary as the RFID app already does check for repetition to prevent false positives.

I will upload the changes I made to protocol_indala224.c later this week. There are still many things dependent on the preamble that need to be fixed.

Edit: I was wrong about repeating preamble checks. They do have a purpose. After a closer look, I infer the intention of checking preamble twice is for ensuring the signal transmission has terminated after certain bit length so that 26 and 224 won't compete with each other i.e. both won't be claiming to be able to decode an incoming bit stream. 224's preamble is a subset of 26's, meaning you will always find 224's preamble in a 26 fob. PM3's solution to this is supporting both within the same file, but run 26's preamble search first and then 224's, i.e. a stricter search is executed first and, if it passes, skip 224 preamble check and move on; if it fails, try 224. It seems OP intended to use separate files and make 224 fail when encountering a 26, which also works. Sorry for my misinterpretation.