Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Pages: 1
Good day
I want to allow some proprietary system to work with remote card.
There are nfc-relay and nfc-relay-picc tools, but they are limited (nfc-relay cannot provide good timings for common readers, nfc-relay-picc has troubles with UID relaying).
What about this idea: proxmark as PICC and some libnfc-compatible reader on remote host?
Advantages:
In general proxmark is very flexible and powerful. For example, we can realize WTX frame or some proxying of remote card content.
Most of work is already done (including mifare simulation code).
I look to ARM sources - it seems to be clear and easy to extend.
Of course, there is work to do, but it does not seems to be too difficult.
Any opinion?
Last edited by edo1 (2012-07-21 00:35:05)
Offline
Interesting idea. I'm with you on this, but have not to much time unfortunately. Let me know if you need any help in (parts of the) coding. On all fronts I could help you there, client, arm source and FPGA. So let me know if you run into a problem!
Cheers,
Roel
Offline
I hope current FPGA code is sufficient for this task.
For now I see one big trouble - timings and authentication.
As I write before, I know two ways to go:
1. implement WTX frames support on proxmark side
BTW, should every reader support WTX frames?
another question - must WTX frame be encrypted while authentication sequence is started, but not finished?
In this approach every reader request must be forwarded to remote host, I don't really like it (it will add additional delay for every request)
2. do partial card content caching on promark side.
I'm not sure about this, but I suppose it is possible.
for example:
- reader start authentication sequence;
- we send nt, but later don't reply to reader (simulate card disappear?), so authentication will break;
- we steal key from recorder sequence (???);
- we send key to remote host, remote host check key and try to read the corresponding sector;
- on next try we can simulate authentication and reading for this sector without requests to remote host.
Yes, this seems to be complicated a little bit, but IMHO it will work better in real life.
PS: sorry, my english is very bad. I hope you can understand me.
Offline
I hope current FPGA code is sufficient for this task.
For now I see one big trouble - timings and authentication.
---------------------------------------------------------------------------------
for example:
- reader start authentication sequence;
- we send nt, but later don't reply to reader (simulate card disappear?), so authentication will break;
- we steal key from recorder sequence (???);
- we send key to remote host, remote host check key and try to read the corresponding sector;
- on next try we can simulate authentication and reading for this sector without requests to remote host.Yes, this seems to be complicated a little bit, but IMHO it will work better in real life.
Current FPGA code needs to be changed (
We need implementing at least manchester and miller decoding and authentication scheme.
I affraid that we need to implement there some key breaking mechanics.( And i think that there is too small FPGA (and too small CPU to make that).
So if you want run forward you need next generation of proxmark's hardware(
By now... You can rebuild software for your needs and rebuild FPGA core. (
You can "prepare" all "UID reading" commands and transfer it to simulator.
If you know the keys (you can sniff treace and then decode it) you can transfer card's memory into the emulator (if there is mifare classic card) and then....
you can buy some "magic" card with changeable UID and read data from "source" card then write to another and then use it )
P.S. You can easily break first authentication and for nested auth its not so easy. it needs too much time to calculate the key.
P.P.S. http://www.picocomputing.com/ex_series.html (not ad) ) Wih theirs hardware you can "break" it in a fly)))), but there is too high price (1 virtex6 chip = 1000USD)
Last edited by merlok (2012-07-23 10:21:26)
Offline
Current FPGA code needs to be changed (
We need implementing at least manchester and miller decoding and authentication scheme.
sorry, I'm totally newbie here.
But mifare simulation works with current FPGA code already, why we need change something in FPGA part?
I affraid that we need to implement there some key breaking mechanics.( And i think that there is too small FPGA (and too small CPU to make that).
what about CPU - we can move computation to host, so I don't expect big troubles here.
what about FPGA - if you are right, it will be big disillusion.
P.S. You can easily break first authentication and for nested auth its not so easy. it needs too much time to calculate the key.
even with modern Intel CPU?
P.P.S. http://www.picocomputing.com/ex_series.html (not ad) ) Wih theirs hardware you can "break" it in a fly)))), but there is too high price (1 virtex6 chip = 1000USD)
sorry, I don't have any experience with FPGA programming.
Offline
You can "prepare" all "UID reading" commands and transfer it to simulator.
agree
If you know the keys (you can sniff treace and then decode it) you can transfer card's memory into the emulator (if there is mifare classic card) and then....
you can buy some "magic" card with changeable UID and read data from "source" card then write to another and then use it )
If I understand right, you are saying about emulation few cards with already known keys. It is unsuitable for me.
Offline
sorry, I'm totally newbie here.
But mifare simulation works with current FPGA code already, why we need change something in FPGA part?
current simulation works, but too slow. because of that almost all readers rejects the emulator.
but logically - it works the same as NXP card
what about CPU - we can move computation to host, so I don't expect big troubles here.
it will be too slow
even with modern Intel CPU?
yes (
Only FPGA (
P.S. if you want transfer authentication - you will have only 64 "ticks" (1,8us) for all the link.
You need this to be like mifare classic card
If not - at the reader part you can easily found your emulator.
P.P.S. maybe another way - fast transfer source signals from the field from one anthenna to another.....
you can do it with current proxmark. but... you must dont use USB between proxmarks. Only cable or 800,2400 MHz, etc... synchronous modems
Last edited by merlok (2012-07-26 16:45:44)
Offline
current simulation works, but too slow. because of that almost all readers rejects the emulator.
so normal simulation is impossible with current hardware?
what about CPU - we can move computation to host, so I don't expect big troubles here.
it will be too slow
I mean move key cracking to host CPU.
IMHO we don't need strict timings here.
even with modern Intel CPU?
yes (
Only FPGA (
can you explain - what must be done in FPGA?
P.S. if you want transfer authentication - you will have only 64 "ticks" (1,8us) for all the link.
BTW, what about WTX frames? can we use it?
I see this in nfc-relay-picc code:
// Notes & differences with nfc-relay:
// - This example only works with PN532 because it relies on
// its internal handling of ISO14443-4 specificities.
// - Thanks to this internal handling & injection of WTX frames,
// this example works on readers very strict on timing.
You need this to be like mifare classic card
If not - at the reader part you can easily found your emulator.
"found emulator" = "will not work"?
It will depend on reader, right? my primary target is NXP-based (mfrc531) reader.
P.P.S. maybe another way - fast transfer source signals from the field from one anthenna to another.....
maintain direct link with very low latency seems to be impossible to me.
I'm too busy now, but I want to make a try a week later.
So I'll be grateful for any tips.
Last edited by edo1 (2012-07-26 17:17:16)
Offline
so normal simulation is impossible with current hardware?
Not at all... but it needs to fully reprogram fpga and cpu logic. if we want simulator we need to write it from the beginning.
I mean move key cracking to host CPU.
IMHO we don't need strict timings here.
if we want decrypt the stream on the fly - we need strict timings.
can you explain - what must be done in FPGA?
as i see:
1. receiver and transmitter code (allready done)
2. modulator/demodulator
3. crypto1
4. if we want key cracking: something like crapto1 (the most complex part)
BTW, what about WTX frames? can we use it?
I see this in nfc-relay-picc code:// Notes & differences with nfc-relay: // - This example only works with PN532 because it relies on // its internal handling of ISO14443-4 specificities. // - Thanks to this internal handling & injection of WTX frames, // this example works on readers very strict on timing
ISO14443-4 - not mifare classic. mifare classic is ISO14443-3
and there is no wait frame as i know(
"found emulator" = "will not work"?
well... if the system has code that involved to find emulators - will not work
if we have some "bad written" system - will work
It will depend on reader, right? my primary target is NXP-based (mfrc531) reader.
it depends on reader's code
maintain direct link with very low latency seems to be impossible to me.
by this method you can easilly do what you want. another ways too complex to use... but... not impossible.
Offline
Pages: 1