search

RfidResearchGroup / proxmark3

Iceman Fork - Proxmark3
http://www.icedev.se
GNU General Public License v3.0
4.03k stars 1.06k forks source link

Implement CryptoRF commands #882

Open iceman1001 opened 5 years ago

iceman1001 commented 5 years ago

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

iceman1001 commented 4 years ago

Not far from it.
It implements cryptoRF, now it would need some more client commands etc.. ref https://github.com/RfidResearchGroup/proxmark3/pull/639

iceman1001 commented 4 years ago

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.

baloncu commented 4 years ago

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.

iceman1001 commented 4 years ago

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.

baloncu commented 4 years ago

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.

iceman1001 commented 4 years ago

Thanks for the heads up, but I thought of

  1. having a structure to define the layout of the bytes.
  2. emulationer resevered space is 4kb, so instead of your array we just eload to *emul and assume it fits a memory layout of yours.
  3. 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.

baloncu commented 4 years ago

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.

iceman1001 commented 4 years ago

8Kb simulation will be a bit harder right now....

baloncu commented 4 years ago

hmm.. well. that is the largest tag size, we can do 16x256 (AT88SC3216CRF) or 16x128 (AT88SC1616CRF). They all work the same.

iceman1001 commented 4 years ago

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.

iceman1001 commented 1 year ago

Since 14B got a fix for shallow mode, we can now more easily add cryptoRF support.