work on iso15, merging with official, ...

[lnv42]

Issue created based on discussion with Iceman1001 in 0ada0e5#comments

last message from lnv42:

OK. i misinterpreted some clone functions available for a lot of tag type. They are actually just "restore" functions.
I was not aware of your fork that seems to be more advanced (at least for iso15). I will pick things from your fork. But i wonder why you don't PR your improvements into the main proxmark repo ?
My main goal is to develop a fully working simulator for iso15 (not supporting only inventory cmd) (i started in the "tmp" branch of my fork). I also plan to do some factorization because currently (at least in the main repo) there are a lot of duplicated codes. I will try to use your work as much as possible. If you have any others suggestions please inform me as soon as possible. ;)

Response from Iceman1001:

Its not the right place to disucss intentions inside one of your commits. Either on the forum or in a issue..
I tend to create issues for iceman fork in order to keep track of my idea of making it better.

There are many reasons for me not making PR's, which I also address in my readme.md , but in short since I can't merge with pm3 offical any longer, I don't have time/energy to sit and create a cherrypicked PR.
There is also the fact many of my ideas is not considered suitable, so I started my fork in order to make a pm3 firmware/client the way I would like to work with it. With consistencies among commands and structures. However while I fiddle with plenty of stuff, I also tend to break things. Which makes my fork highly unstable from time to time ;)

Go for the 15 sim, its one of the older issues on pm3 offical Proxmark#20

[lnv42]

Ok. Got it.So for the iso15 i will try to merge your work with the official one and with mine for the clone/restore and for the simulator. Then i will PR everything to the official and to your fork.

[iceman1001]

I suggest you merge against one first. Keeping track of three different versions at the same time is hard.
Easier to iron out bugs. Once you have it, you can start merging against the second one... and get out the bugs.

Normally PM3 Offical is the oldest, then comes my fork with adaptations. You make up your mind which you like, and start from there ;)

[lnv42]

Yes. In any case my first step will be checking diff between both versions (only concerning iso15). If every diff in Iceman fork are improvement without any regression then the merging job will be easy ;).

[lnv42]

Another question : it's probably not the right place but : do you know if fully writable (including uid) iso15 tag (like chinese mifare) exist and if : how to get some ?

[iceman1001]

There is no magic iso15693 cards on the market to my knowledge.
Its only a matter of time before someone creates one

[iceman1001]

have a look a @douniwan5788 He did much of iso15 impl first.
douniwan5788@ca0c94e

[lnv42]

Oh Yeah ! He did a lot of work on the sim, but the last version on his branch "newWorking15693sim" don't contain a fully working sim and his approach don't seems to be very "clean". But i will definitely grab few things from his code ;). Thanks to you and to him.
If you saw other advanced code on the iso15 sim : i'm of course interested ;)

[iceman1001]

well, I think you have all of the ones that I have found...

[lnv42]

(@iceman1001 or anyone else) : Another question for my work on iso15 : Is there any way/functions to store some none-volatile data on the PM3 ? (Data that stay there after a power loss).

[iceman1001]

well.. not directly of the box, but remember there is 512kb flash mem on some boards.
the 256kb boards are almost full with current firmware.
So battery and the reconnect ability is how you can solve it today

[lnv42]

OK. TY. My PM have a 256k flash, Is there a simple way to write it ?
I tried to pick some code from firmware flashng function to wirte the flash but i have some bugs, all the firmware page is writed with the same byte... i probably have to do some debugs and more test.

[iceman1001]

You have to look at the atmel specs to sort that out. Remember your 256kb mostly filled with firmware.. You would need to find a place in the end, to write and read...

[iceman1001]

waking up an old issue,
I noticed some commits. Recap of whats happenings since last 2 years.

• Magic ISO15693 tag exists
• RDV4 has extra onboard flash memory for persistent storage

Still waiting for you to finish the sim :)

[lnv42]

Yes i restarted working on that. My plan is to have a fully working simulator before the end of the month and to work on merging it on feb.
I have seen the apparition of magic tag and ordered few, but they have some fixed spec (e.g. sectors numbers) that may limit their usage...
Nice news for the RDV4 but i don't have one to test...

My next job is to implement the support for the FSK mode (aka 2 Subcarrier). But i had never touched to the fpga code yet and i'm not sure of what is the good way to do that.
My current plan is to create a 3390KHz subcarrier (which is 8x424KHz and 7x484KHz) in order to be able to decode it, but if you know a better and/or easier way to do that i'm very interested.

[iceman1001]

Merry Christmas!

Two years has passed (more or less) since I commented last. The RRG/Iceman repo is quite a nice place to merge your code into. I see your stuff never got into Official.

Hook me up on the RFID Hacking discord ( https://discord.gg/iceman ) or email me, so we can do something with your stuff.

One thing is that you don't need to remove trace for fpga, and I would suggest you use a struct instead of having references to offsets in a array as base for the emulator.