[Hackrf-dev] Help with NFC decoding.
Martin Holst Swende
martin at swende.se
Sat Apr 18 10:46:14 EDT 2015
On 2015-04-18 16:10, evilsocket wrote:
>> I think this is a great goal, but have you considered using GNU Radio
>> to confirm that it works and then rewrite it in C/C++ piece by piece?
>
> Yep but in that case would be copying, not understanding, wouldn't it? :D
>
>> Have you looked at the waveform to see if you can identify where the
>> data is being transmitted?
>
> Yep, I'm on the right frequency and it's clearly ASK.
>
>> I think you're on the right track.
>
> Great! :D
One thing that will bite you with this approach, is that you'll only get
reader-side of the comms this way. The reader does OOK, but the tag does
not transmit; it modulates the reader signal. So, depending on whether
the tag coil is open or closed, it will dampen or not dampen the
reader-signal. So you'll need to have some more levels to discern these
pretty small variations in the signal.
>
>> It probably depends on what is being transferred. A good place to
>> start would be these specs:
>> http://members.nfc-forum.org/specs/spec_list/
>
> Thanks so much :)
Obviously, depending on what you're observing, it will vary, but I would
guess that the traffic you're seeing is iso14443a, afaik the most
commonly used. The documents you're looking for would be the ISO 14443a
specs. There are four of them:
1. Physical characteristics
2. Radio frequency power and signal interface
3. Initialization and anticollision
4. Transmission protocol.
Start with 2, and work your way up... I can email them to you off-list
if you'd like, shoot me an email in that case.
Otherwise, it's probably iso15693 you're seeing. That's more common in
vicinity (as opposed to "proximity") cards which can be read over a
greater distance, e.g. ski passes.
Good luck
/Martin
More information about the HackRF-dev
mailing list