T5577 Feature Request - dump / restore / compare feature

[amalg]

The low frequency T5577 chip is so versatile that even access control system manufacturers are using it over purchasing AWiD, EM, HID Prox, etc. LF chipsets, and replacement fob merchants are using them now too. Sometimes there are additional application data written to the T5577 and used by these systems than just their analog front-end configurations and ID data. This makes cloning the EM ID from a source T5577 to a fresh T5577 ineffective.

A good feature would be to be able to perform a complete memory dump of a T5577 chip to the Flipper Zero, then be able to write this complete memory dump to a new T5577. This would include block 0 config data and any additional application data, thus making it a perfect clone. Additionally, it would be really nice to be able to compare a dump file to a tag to check / ensure the write process has completed successfully.

[skotopes]

@amalg there are physical limitations in LF-RFID subsystem that prevents us from implementing Reader-Talk-First protocols reliably. Because of that PR with HiTag support stuck in limbo.

Exactly same thing happens with 5577: implementing proper data exchange is nearly impossible.

[skotopes]

Also wrong repo, should be in firmware.

[amalg]

@amalg there are physical limitations in LF-RFID subsystem that prevents us from implementing Reader-Talk-First protocols reliably. Because of that PR with HiTag support stuck in limbo.

Ah this makes sense. I therefore suggest instead that support for writing various proxmark3 t5577 dump bin files. This should be totally viable for Flipper Zero hardware, and it would allow an entire catalogue of dump files to be kept and made portable for easily updating T5577 chips on-demand. I have attached a sample dump which contains both bin and json file formats.

lf-t55xx-0001C101-01013B04-10511361-A186BFF4-dump.zip

[zinongli]

Hi @amalg ! I wrote a wrapper app for FZ's T5577 api. It could do the writing you suggested. But it saves and loads in Flipper format. I think the pm3 compatibility you are suggesting can be done in several ways. A Python script for the users to manually run, a C script that automatically checks for json and bin and covert them into Flipper format, or supporting those file extensions in the app's source code. What do you think?

[amalg]

Thanks @zinongli, I checked the .t5577 file format and realized it looks very similar to the .json file format the proxmark3 outputs. How much effort would it be to natively support the .json file format in your wrapper app? For example, the proxmark3 .json format looks like this;

{
  "Created": "proxmark3",
  "FileType": "t55x7",
  "Card": {
    "ConfigBlock": "00107080"
  },
  "blocks": {
    "0": "00107080",
    "1": "0001C101",
    "2": "01013B04",
    "3": "10511361",
    "4": "A186BFF4",
    "5": "00000000",
    "6": "00000000",
    "7": "00000000",
    "8": "00107080",
    "9": "C02A1451",
    "10": "11A99BCB",
    "11": "00000000"
  }
}

The .t5577 file format is similar;

Filetype: Flipper T5577 Raw File
Version: 2
Modulation: FSK2a
RF Clock: 64
Max User Block: 7
Raw Data: 
Block 0: 00 14 70 E0
Block 1: 11 12 13 14
Block 2: 22 33 44 55
Block 3: 1A 2B 3C 4D
Block 4: 56 78 AB CD
Block 5: 12 34 12 34
Block 6: AB CD EF AB
Block 7: 12 34 56 78

[zinongli]

Hi @amalg , I agree the file formats are similar. I'm very new to FAP dev and I'm not sure about FZ's capability to read .json files. But other than that it's definitely doable. Only requires some parsing scripts. But I think I will first make my app able to write the page 1 data before allowing it to import that from pm3.

Do you mind copy-and-pasting your comments into my repo's issue section so we have a dedicated place to talk about the app? I haven't yet found any indications that these features are planned to be included in the main RFID app. Considering how niche it is it probably should be a standalone app.