search

iceman1001 / proxmark3

[Deprecated] Iceman Fork, the most totally wicked fork around if you are into proxmark3
http://www.icedev.se/pm3.aspx
GNU General Public License v2.0
465 stars 116 forks source link

Moved changes to iceman fork #127

Closed Satsuoni closed 6 years ago

Satsuoni commented 6 years ago

Could you please see if you could extract any useful functionality from this, aside from bugfixes? I think at least ISO18092 frames can prove useful if anybody is interested in further developing Felica Lite tags.

iceman1001 commented 6 years ago

Felicia support is something I've been waiting for. Really awesum fixes from you.

Some questions; The new fpga mode takes memory on ARM, wasn't possible to get it inside the HF part?

Your mods seems to have a raw-tracemode and felicia sniffing? There is no read/write/ etc standard felicia protocol?

Satsuoni commented 6 years ago

I tried to get it into HF part on FPGA, and ran out of slices around modulation part. So, well, sniffing part fits, modulation part doesn't, and I am not proficient enough in verilog to optimize it down. Especially since reader part needs to be added. But maybe it can be folded better. My mods have the tracemode (for frames, not really raw, I guess? There is no distinction between reader and card frames, aside from command numbers) and raw printer that prints the list (I am not sure how "hf list raw" worked in vanilla?) They also have Felica (well, ISO18092, of which Felica is a subset) sniffing and basic simulation (reply to polling command). I was originally trying to check if anything beyond polling was checked at the door readers, and well... no. No encryption used.

iceman1001 commented 6 years ago

What I meant was that to get a more complete Felicia support for PM3, commands like: hf felicia rdbl hf felicia wrbl hf felicia dump hf felicia reader
hf felicia info
hf felicia sim
hf felicia sniff
what is needed in your changes to support it?

Satsuoni commented 6 years ago

It is FeliCa, not felicia... Right. To implement that the steps would need to be:

  1. Fix the response timing on non-polling commands in hi_flite.v (respond ASAP, essentially)
  2. Implement reader sim in hi_flite.v (just driving pwr_hi with ck_1356meg might be enough, but I don't know)
  3. For rdbl, implement packet with cmd1=0x06, as described in NFC Tag 3, Felica or FelicaLiteS specification.( FelicaLiteS is a subset with fewer capabilities than full Felica). Send it over to the card with sendNFCToFPGA and wait for 0x07 (assuming reader part is working)
  4. For wrbl, likewise but with cmd1=0x08 and 0x09. Note: some config bits on Felica can only be written once (no auth switched to auth), for locking card to the reader with the key, I assume.
  5. Full Felica ( of which I haven't seen any blanks sold) supports switching to Encryption mode, with separate commands "Write with encryption" and "read with encryption". For FelicaLiteS, trying to switch would just disable the card until power reset, if I understand correctly.
  6. Dump would probably just go over available readable blocks?
  7. Info is essentially parsing the dump according to specs, I guess. Like 0x012e in IDm being Sony, FelicaLiteS, etc.
  8. Sim - depends on what exactly you want to simulate. Pasmo sim is probably impossible without appropriate keys (and the specs are harder to find). Just simulation of IDm is done (hf litesim ).
  9. Snoop - done, since frame format is the same for all of them (hf slite). The output might need to be tweaked?

Optional: Implement 424k mode in hi_flite.v (detectable from Manchester encoding)

iceman1001 commented 6 years ago

Yes, FeliCa, but a female name sounds much better :)

Protocoll: ISO18092

Adding a command set in PM3 to support the ISO18092 is the aim. The naming with NFC in your functions will change to fit in with current pm3 names. the tracelog should be able to be used as it is. timing, the commands,
a annotation for ISO18092 (or FeliCa) too.

dump: yes basically read all available cardmemory and write to file. restore: same, read all memory from file and restore onto card The included crypto used by FeliCa will be interesting to add aswell. Finally some analysing of cards can be done :)

There is a bit to do.

Satsuoni commented 6 years ago

Yes, I didn't do very much, sorry. I don't know much about RFID :) I find Felica cuter, though ;) I might be able to finish adding basic functionality to FPGA part (do you think driving antenna would be enough for a reader mode? It is supposed to be doing ASK10 modulation), but probably won't be able to fold it into HF part (without replacing parts there, anyway) Annotation can probably just use cmd1 byte from, say, card_usersmanual_2.02.pdf from Sony. As mentioned, please do keep in mind that some blocks are read-only, some are write-only, some bits are write-once and there is a limit as to how many MAC-verified writes can be made before that functionality is locked, so one should be somewhat careful with the card values XD Anyway, I am afraid I'll be of limited use/help with that due to full-time job, and the fact that I largely got the functionality I was curious about. I just wanted to see if these pieces would be of use.

iceman1001 commented 6 years ago

You did a great thing. I am impressed, there is a very few ppl who touches the FPGA code and come up with something new. For not knowing much of RFID, I'd say you know a lot. You can show me how to fiddle with the FPGA code and that would make my day :)

The questions I have, is more for me to understand the stuff you have done. I'll adapt it and make it follow the PM3 style we have.

Lookint at the felica users manual, it says ASK, Manchester, 212 / 414 bitrate, We have that already but on device side (arm), so I guess you added this modulation on fpga side? Now this will explain why you need more space on fpga.

So you send of the demodulated bytes to ARM, this should be easy to adapt to current tracelog. same goes for annotations on client side.

Sending raw felica commands could be a good start, with it we can add the command protocol later.

Satsuoni commented 6 years ago

Fiddling with FPGA code might be easy enough (I tried to add comments) - it is similar to what you had for ISO14443A/B, except that hysteresis code didn't work for me (due to aliasing, as far as I can tell - the envelope for non-modulated carrier was a sine wave of amplitude 10 to 13, the signal convolved with that), and I didn't find the ASK10 manchester no-subcarrier demod for high frequency on ARM side, so I combined pieces from LF envelope following with what I could see from signal to demod it. Block after if ((mod_type==SNIFFER )||(mod_type==TAGSIM_LISTEN)) is listening (or sniffing, there is no difference). Modulation is trivial, but it uses counter from demod phase - the most problematic here was to shift the bits from ARM at the right rate ( I am still not sure how frame affects that). So yeah, I send out demodded bits to ARM, where I find the correct bit offset from SYNC byte structure and count frame from there. Once NFCFrame is full, I check (rolling) crc and either parse it or dump it into buffer (with SYNC and CRC, and prepended with duration till length). To write (simulate) card I use sendNFCToFPGA with the pointer to frame (with SYNC and CRC) , and just switch the mode and push data over to FPGA.

Now, currently, FPGA does the collision resolution, that is, it counts for 512 of 64/fc ticks before allowing ARM to send. That is correct for POLL command (is time slot is zero), but all other commands have shorter timeouts, so that has to be adjusted (I was planning to use TAGSIM_MOD_NODELAY for that, and maybe 3rd bit of mod_type for reader). Anyway, that will probably be my last answer for today, since it is late here.

iceman1001 commented 6 years ago

@Satsuoni is there a missing fpga_nfc.bit file in this PR?

Satsuoni commented 6 years ago

Added (it always gets gitignored). Anyway, I tried my hand at adding reader mode, but with no success so far. Since there is no way for me to tell what it outputs until the tag responds (or what tag response looks like when pwr_hi is on), this may take a while. So far I determined that my baseline for no signal is 0x7e for external reader field, ond about 0xdc with me driving the antenna. Any pointers?

iceman1001 commented 6 years ago

Lets bring in the topnotch dudes, @pwpiwi , the godblessed, might have answers for you

Satsuoni commented 6 years ago

OK :) To give some more details, I am trying to drive shallow modulation in the same way it is driven in hi_read_tx.v, in the same place modulation is now in hi_flite.v (by switching mod-type)

iceman1001 commented 6 years ago

It will not be possible to merge this PR, but I'm adding your changes and adapting them as I go.

Satsuoni commented 6 years ago

Of course. I'll upload something if I manage to make reader work.

pwpiwi commented 6 years ago

Do you have some links to introduction to both Felica and ISO18092?

Satsuoni commented 6 years ago

Like http://www.proxmark.org/files/Documents/13.56%20MHz%20-%20Felica/JIS.X.6319-4.Sony.Felica.pdf and http://standards.iso.org/ittf/PubliclyAvailableStandards/c056692_ISO_IEC_18092_2013.zip ?

iceman1001 commented 6 years ago

http://www.proxmark.org/files/Documents/13.56%20MHz%20-%20Felica/

pwpiwi commented 6 years ago

Thanks for the links. I had a quick glance and have the following comments/questions:

Satsuoni commented 6 years ago

Hmm. There is no subcarrier in ISO18092, but yes, I experimented today and it seems that modulation is easier from the ARM side (it knows where to stop :) ) Which means that if I butcher my FPGA code a bit and alter the existing to support proper modulation frequencies (like hi_read_tx for fc/32 and fc/16) , I might be able to fold demodulator into existing fpga_hf. Sorry, @iceman1001 ;) Let's see if demodulator works with power on...

iceman1001 commented 6 years ago

Dont be sorry :) I think I have taken much of your changes and merged it now. the hf felica commands skeleton is there, so its a matter of filling it up...

Satsuoni commented 6 years ago

I was mostly apologizing because I moved a lot of stuff around when I was working on a reader part... For example, I managed to fold FPGA part into fpga_hf.bit, if barely (430 out of 432 slices) . Then discovered that our door readers are finicky about timing and had to move things around again... I'll try to finalize what I have into something coherent probably tomorrow, and then make another pull request. Also, I took a look at your command skeleton, and I am not sure I see the point/understand some of them, like sending partial bytes (all commands to Felica are byte-aligned)

Satsuoni commented 6 years ago

Closing this one and opening new one.