[Hackrf-dev] Help with NFC decoding.

[Martin Holst Swende]

I can also recommend posting nfc-related topics to the proxmark3-forum at proxmark.org, even if it's not directly related to pm3. Fairly active community with lots of nfc-knowledge. 
Cheers
/Martin (forum user 'holiman')

On April 18, 2015 7:17:29 PM CEST, evilsocket <evilsocket at gmail.com> wrote:
>If anyone wants to keep the conversation going ( instead of receiving
>dozens of emails :P ) I've posted the question on reddit
>http://www.reddit.com/r/sdr/comments/331jeq/q_how_do_i_demodulate_a_series_of_magnitudes_in/
>
>2015-04-18 18:44 GMT+03:00 evilsocket <evilsocket at gmail.com>:
>
>> Yeah as long as I know, NFC-A is modulated on ASK 100% from the
>reader
>> side and ASK 10% from the tag side, so using only one type of
>demodulation
>> I should be able to see only the reader data and wrongly demodulated
>tag
>> data ... but once I'll be able to correctly demodulate the reader
>side,
>> I'll "follow" the protocol and know what should be demodulated how
>....
>> hopefully :P
>>
>> I'm pretty sure it's ISO14443a, at least that's what the nfc reader
>app
>> I'm using is saying.
>>
>> 2015-04-18 17:46 GMT+03:00 Martin Holst Swende <martin at swende.se>:
>>
>>> 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
>>>
>>
>>
>>
>> --
>>
>>
>>
>> _________________________
>> Simone '*evilsocket*' Margaritelli
>> http://www.evilsocket.net/  <http://www.evilsocket.net/>
>>
>
>
>
>-- 
>
>
>
>_________________________
>Simone '*evilsocket*' Margaritelli
>http://www.evilsocket.net/  <http://www.evilsocket.net/>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20150419/8bc498c4/attachment.html>