Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

LFRFID: Indala 224 (resolves #2386)#3337

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Draft
Aidan-McNay wants to merge5 commits intoflipperdevices:dev
base:dev
Choose a base branch
Loading
fromAidan-McNay:dev

Conversation

@Aidan-McNay
Copy link

@Aidan-McNayAidan-McNay commentedJan 4, 2024
edited
Loading

What's new

  • Support for the Indala 224 LFRFIF Protocol (code adapted from Indala 26, based on Proxmark3). This shouldresolveIndala 224 card not being read #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

@Aidan-McNayAidan-McNay changed the titleIndala 224 (resolves #2386)LFRFID: Indala 224 (resolves #2386)Jan 4, 2024
@skotopes
Copy link
Contributor

@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
Copy link
Author

Aidan-McNay commentedJan 4, 2024
edited
Loading

(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 canwrite 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
Copy link
Contributor

On it, will try to ask around about these cards

Aidan-McNay reacted with heart emoji

@hedgerhedger added RFID 125kHz125, 134 kHz RFID New FeatureContains an IMPLEMENTATION of a new feature labelsJan 4, 2024
@DrZlo13
Copy link
Member

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
Copy link
Member

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

Copy link
Member

@DrZlo13DrZlo13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Does not work :(

@DrZlo13DrZlo13 marked this pull request as draftJanuary 19, 2024 10:04
@Giraut
Copy link

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
Copy link
Contributor

zinongli commentedJun 21, 2024
edited
Loading

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 donein 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.

memset(protocol->corrupted_negative_encoded_data, 0, INDALA224_ENCODED_DATA_SIZE);
};

static bool protocol_indala224_check_preamble(uint8_t* data, size_t bit_index) {
Copy link
Contributor

@zinonglizinongliJun 22, 2024
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

If you change this function to this:

static bool protocol_indala224_check_preamble(uint8_t* data, size_t bit_index) {
// Preamble 10000000__00000000__00000000__00000
if(bit_lib_get_bits_32(data, bit_index, 30) ==
0b100000000000000000000000000000) {
return true;
} else {
return false;
}
}

Reading will work.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Can you help me bro for My indala card ?

@Uniik-Lio
Copy link

hello guys I also have a work badge Indala 224 I would like to copy it on the pinball machine and then put it on a bracelet Question of practice did you manage to get the badge read? because for me it doesn't work I tried to take the file but the pinball machine doesn't recognize it it appears empty on the pinball machine Sorry I'm a novice

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@DrZlo13DrZlo13DrZlo13 requested changes

@skotopesskotopesAwaiting requested review from skotopes

@hedgerhedgerAwaiting requested review from hedgerhedger is a code owner

@nminaylovnminaylovAwaiting requested review from nminaylovnminaylov is a code owner

@gsurkovgsurkovAwaiting requested review from gsurkovgsurkov will be requested when the pull request is marked ready for reviewgsurkov is a code owner

+2 more reviewers

@zinonglizinonglizinongli left review comments

@Uniik-LioUniik-LioUniik-Lio left review comments

Reviewers whose approvals may not affect merge requirements

Requested changes must be addressed to merge this pull request.

Assignees

No one assigned

Labels

New FeatureContains an IMPLEMENTATION of a new featureRFID 125kHz125, 134 kHz RFID

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Indala 224 card not being read

8 participants

@Aidan-McNay@skotopes@doomwastaken@DrZlo13@Giraut@zinongli@Uniik-Lio@hedger

[8]ページ先頭

©2009-2025 Movatter.jp