proxmark3
proxmark3 copied to clipboard
RfidResearchGroup
[WIP] Cryptorf
Added support for CryptoRF tag simulation. Crypto engine implementation is from the topic below. http://www.proxmark.org/forum/viewtopic.php?id=4855
Tested the implementation for a cryptoRF tag (AT88SC6416CRF).
Tag memory is generated as a header file, to change the tag memory, one need to change tag_mem.h Many performance optimizations are implemented for tag response generation and crypto engine. Used lookup tables instead of calculations where possible. Main changes are in the armsrc iso14443b.c file.
Looks like an awesome addition!.
How is the ram memory usage?, there is some pretty large LUTs you are using. and the changes into arm-side 14b, does that make 14b more stable aswell or just CryptoRF?
And you should run make style in order to get the code adapted to our prefered code style.
and don't forget a line in the CHANGELOG.md file!
Appveyour is confirming the RAM part...
interesting. I did build it as well and didn't get a complaint about the ram size. I used PM3OTHER platform setting though as I have an RDV2
I have changed the size of the tag memoryto solve the RAM issue. Now it is simulating a ATSC1616CRF tag. My changes are for cryptorf. I only added a TR1 synchronization timing for the rest of the hf 14b code. I did 'make style' and add a line in changelog. But I am having a conflict in changelog.md
Great!
Awesome stuff bro,
now some questions, why are you hard coding a tag? Why not use the reserved space called "emulator" memory of the bigbuffer? You can have "eload/esave" commands in client to upload/download the tag you want to simulate. That will save some space.
Next thing we will need is a way to read -> dump a cryptoRF tag's memory. In order to create the files needed for simulation.
And now you will have some conflicts. Not that hard to sort out, pm3_cmd.h sry
Great!
Awesome stuff bro,
now some questions, why are you hard coding a tag? Why not use the reserved space called "emulator" memory of the bigbuffer? You can have "eload/esave" commands in client to upload/download the tag you want to simulate. That will save some space.
Next thing we will need is a way to read -> dump a cryptoRF tag's memory. In order to create the files needed for simulation.
I am using a hard coded file, I didn’t realize the eload/esave use. It was a quick and easy way of doing it. I will look into that to see if I can use the client to load a memory image.
For reading a tag, the reader code didn’t work reliably enough for me to read many bytes back to back. I tried to fix it but it wasn’t good enough to read many bytes. I am not confident about reading tag memory in a loop.
And now you will have some conflicts. Not that hard to sort out, pm3_cmd.h sry
I will fix these but I can only look at this tomorrow. Thanks.
lets see then, we could merge, and rearrange stuff..
We would need info/read/write/dump all/ eload/esave to nice support for CryptoRF. I also think it should have its own command group, direct under hf cryptorf instead for under 14b. Even if its 14b based, think like iClass which can be both 14b and 15693 based.
ok, to help you out, I pushed two new files, a skeleton for cryptorf commands.
It compiles and uncomment one line in cmdhf.c and you can test your stuff direct.
its based on the 14b cmds, so it shouldn't be too hard to mix in your stuff :)
ok, to help you out, I pushed two new files, a skeleton for cryptorf commands. It compiles and uncomment one line in cmdhf.c and you can test your stuff direct. its based on the 14b cmds, so it shouldn't be too hard to mix in your stuff :)
Okay, I got the skeleton you added and now working on it. But you are fast :) - I hope you are not expecting such fast coding skills from me.
Btw, I added a new CRYPTORF simulate command in the armsrc/appmain.c, that is what I plan to use. Also for the dump/read etc. there is some code in get_14b_UID that checks if the tag is SRx first. I don't think those are necessary when we are using a tag we know cryptorf.
The skeleton was taken from 14B source, so it still has residue from things that isn't needed for cryptoRF. Also why it went fast to do ;)
Its easier to chat, instead of having the conv here. I can help to get things speeded up, if you want it.
Where are we on this one @baloncu ?
sorry guys! I didn't have much time to look at this recently. My implementation of the tag simulation depends on a hardcoded tag file. I was hoping to get rid of the tag_mem.h and instead take it as a parameter for eload command and utilize the card memory allocated in big buffer. I can take a look at this by the weekend and commit my changes.
Hi guys, My desired changes require me to test the code on the hardware and I am not able to do that. However the code as it is right now can do CryptoRF simulation (not very elegant, we still read the tag memory from a header) and does other 14B commands (no changes to the standard code except 3 retries for Info command). What we can do is to close/reject this PR and I can open another one if/once I have access to my hardware and can test my code or we can integrate as it is. I prefer not to push any changes that are not tested on HW.
I prefer not to push any changes that are not tested on HW.
Sure, we respect that. We can leave the PR open to keep track of the comments, no problem. I tagged it as [WIP].
Does this work with the at88rf04c tag? Can anyone help me how to decode the string I read from the tag?
Key Index = 12 Session Encryption Key S2 , Q1-8 = 9C31E4A9352EB6EB , CH1-8 = B492F00A7CEA4C0F Data is : 58BC6E20EB1A9EE483A9FD008843AB14
I will close this one as I have no free time to work on it. If/Once I do have sometime, I will work on the changes and open a new PR.
No need to close. The [WIP] tag was added in order to keep it alive and not loose track of the source code.
Just that there was no time and HW to test the needed changes.