proxmark3
proxmark3 copied to clipboard
RfidResearchGroup
Implement CryptoRF commands
The crypto used also is known, so it would be possible to implement it all.
Datasheet http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-5276-CryptoRF-AT88SC0808CRF-1616CRF-3216CRF-6416CRF-AT88RF04C-Datasheet.pdf
Not far from it.
It implements cryptoRF, now it would need some more client commands etc..
ref
https://github.com/RfidResearchGroup/proxmark3/pull/639
Took parts of @baloncu 's PR to fit in. The crypto part needs to be looked at, large LUT's and tagmemory should be a binary file take you can eload and make device simulation use the emulator memory.
However all of it is based upon ISO14443B, which is not working very well at the momement.
I took the crypto part from Roel's code. I downloaded it via one of the cryptoRF threads http://www.proxmark.org/forum/viewtopic.php?id=4855 However, in order to make it work with the reader I had, the code had to run faster than what it did, that is why all the LUTs and bitshift operations. I tested and made sure the code is simulating a cryptoRF tag correctly. I fed the key to CryptoRF simulator, never tried to extract the key from a snoop trace like it was explained in the paper "Dismantling SecureMemory, CryptoMemory and CryptoRF" In order to clone a cryptoRF tag that part has to be added.
As the moment, 14b is working nice. and we got a cryptoRF lib insde the pm3 client. now to see if those lookup tables LUT and bitshifts can be adapted into it.
getCRFResponse function in the armsrc will look for a specific indexing of the tag memory.
like response.body = tag_mem[userZone] + (((cmd[1] & 0x0001) << 8) | cmd[2]);
this may be changed because of the eload.
Thanks for the heads up, but I thought of
- having a structure to define the layout of the bytes.
- emulationer resevered space is 4kb, so instead of your array we just eload to *emul and assume it fits a memory layout of yours.
- I would need a binary file of your hardcoded bytes.
So, tag_mem would be just referencing emulator_mem, the code wouldn't see a difference.
this makes sense. tag_mem is same as cryptoRF layout in datasheet. 16 x 512 byte zones (AT88SC6416CRF).
static uint8_t tag_mem[16][512] and all bytes set to 0xFF for a brand new tag.
hmm.. well. that is the largest tag size, we can do 16x256 (AT88SC3216CRF) or 16x128 (AT88SC1616CRF). They all work the same.
Excellent. In the future making the hardcoded limit for emulator memory reserved space a configurable one shouldn't be too hard.
list of possible sizes and its modelnumber for future reference.
- 8Kb - 16 x 512 (AT88SC6416CRF)
- 4Kb - 16 x 256 (AT88SC3216CRF)
- 2Kb - 16 x 128 (AT88SC1616CRF)
Since 14B got a fix for shallow mode, we can now more easily add cryptoRF support.