New commands/features for the GUI client

d18c7db · 2009-07-20 10:05:39

I added a few commands and features for the GUI client that should aid those that like to stare at waveforms all day long. All these are available in offline mode as they act on the graph buffer only.

threshold [-]val

The number can be positive or negative. The command runs through the graph buffer and replaces every sample value >= val with 1 and every other value with -1. This might be useful sometimes if you want to take an analog waveform and turn it into a clean set of highs and lows.

fskdemod

This is another way to demodulate HID tags inspired by tidemod. It acts on a raw FSK waveform as captured by loread or loaded from a saved capture. It uses the same principles of signal processing as tibits to demodulate the FSK waveform. It then goes on to detect the start condition and inserts markers around the detected bits to visually aid the user in detecting bit boundaries. Finally it manchester decodes (using a method different from the one implemented in hidfskdemod) the bitstream and prints out the output to the text window as binary and hex.

grid x y

This is one I've been wanting for a while. It overlays a faint grid on the plot window with the x and y spacing specified. Use positive values (no checking yet ). You can turn either or both grids back off by specifiyng a zero value. The grid zoom follows the waveform zoom (try it) but it does not follow the waveform left/right, ie the grid is fixed. The x values are in sample units. The y values are in, uhh.. , graph window pixel units I guess. The idea with the graph is not to use it for measurement as such, that's what the cursors are for but having an adjustable grid can aid with visually detecting waveform periods, alignment of peaks and valleys in the waveform or visually place boundaries around repeating bit patterns. Finally one other visual change to the graph window is that the sample labels now follow the sample as it moves left/right, ie the label under a sample reflects that sample's sequence. Does that make sense? For example, if you see a label with a value 8192, that means that the sample above it is the 8192'nd sample.

adam@algroup.co.uk · 2009-07-21 17:15:08

Very very cool, but unfortunately the grid command broke the linux build...

I've tweaked it slightly so it sets the variables within the command module instead of calling an external function (as per other graph variables), and I've implemented the grid plotting in the linux gui, so hopefully I haven't broken the windows version now!

BTW, I didn't quite get the "offset" variable, so I used "GraphStart" in linux - what was the purpose of setting offset to 64? Please feel free to change it if it's borked in any way!

Last edited by adam@algroup.co.uk (2009-07-21 17:35:08)

adam@algroup.co.uk · 2009-07-21 17:27:49

Doh! I got it... Just puts the grid into the plotted area.... fixed!

ryan · 2009-07-21 17:34:25

Hey Adam,

I think some of the changes in r96 broke the compilation of the Windows client.

command.obj : error LNK2001: unresolved external symbol "int PlotGridX" (?PlotGr
idX@@3HA)
command.obj : error LNK2001: unresolved external symbol "int PlotGridY" (?PlotGr
idY@@3HA)
obj/prox.exe : fatal error LNK1120: 2 unresolved externals
NMAKE : fatal error U1077: '..\..\devkitWIN\bin\cl.EXE' : return code '0x2'
Stop.

For some reason it doesn't seem as though command.cpp can see PlotGridX and PlotGridY that are in prox.h.

I'll let you know if I figure out an easy way to fix it, but I thought I'd alert you first.

Thanks,

-Ryan

adam@algroup.co.uk · 2009-07-21 17:39:30

I've committed a fix which I hope should do the trick... They have now been declared in the same was as some other external variables...

ryan · 2009-07-21 18:12:37

Looks like now they're declared twice in gui.cpp. I removed the "static int" declaration on line 44 line and it compiles now.

-Ryan

adam@algroup.co.uk · 2009-07-21 18:47:04

Great, thanks. I've committed that change as it still works in linux too.

ryan · 2009-07-21 21:41:21

Compilation issues aside, I have a question related to fskdemod and, in general, staring at waveforms all day.

How do you tell if you have a trace that fskdemod can interpret? I noticed that it seems to happily output a string of hex when no tags are in the vicinity during a loread. For example:

> loread
#db# 00000060, 0000005f, 00000000

> losamples 2000
> fskdemod
actual data bits start at sample 1459
length 50/50
bits: '111001011011001011110011010000010101000001100'
hex: 00001cb6 5e682a0c

The reason I ask is that I'm trying to decode a trace of one of the only other RFID tags I have been able to get ahold of and able to get a good read on. It's actually inside my cat, and I'm pretty sure it's a HomeAgain tag. I can't get much in the way of specs on that type of tag, so I've been pretty much going at it blindly. fskdemod seems to be one of the only demod commands that doesn't barf when I use it on a good trace of the tag, but I'm not sure that it's giving me real data.

d18c7db · 2009-07-21 21:45:36

I believe "offset" creates that empty space on the left hand side of the plot window.

samy · 2009-07-21 21:46:40

ryan,

Can you upload a trace of loread + losamples 6000 somewhere for us to look at? Do you have any idea on what the ID of your cat is?

ryan · 2009-07-21 21:55:04

Sure. Uploaded as homeagain.pm3. I'm looking for the documentation that has the ID number in it. I'll let you know when I find it.

In the trace, it seems that you can see periods of 32, 48, and 64, so that would mean that it's FSK-modulated, right?

d18c7db · 2009-07-21 21:57:06

Yeah, I was just going to say the same as Sammy. When I eyeball the sample I'd be able to make some informed comments :)The function fskdemod looks for a special marker in the datastream to detect the start of data. That special marker is an invalid manchester encoding (three low bits three high bits) followed by valid manchester data. The fskdemod is by no means a universal (decode any) FSK stream. It assumes 125K sampling rate and 8/10 cycles for low/high modulation as well as a certain length for the low high pulses. These parameters match the HID tag timings but maybe not your cats.

samy · 2009-07-21 21:59:14

Cool, I'll czech this out.

Mind if I add this to the SVN repo of traces as well for future testing? Your cat could become famous.

"Hansel, it's so simple. The tag is IN the cat!"

ryan · 2009-07-21 22:11:32

@d18c7db

Yeah, I saw in the docs that it was HID-specific, but I thought I'd try it anyway to see if it would produce anything meaningful for other types of tags. That's when I noticed that it would return something even for a trace with no tag in it. I was just wondering if there were any clues that would tip a user off in the event that it decoded garbage.

@samy
According to HomeAgain, the ID number is 985121004515220. I'm not sure if it corresponds exactly to what's in the trace or not, since the number is 15 digits. It might have no correlation to the trace at all. Feel free to include the trace in SVN. Just please don't steal my cat!

samy · 2009-07-21 22:14:23

ryan, when did you get this tag? Looks like HomeAgain started shipping new tags this month.

I want to make sure we can analyze and categorize it properly.

ryan · 2009-07-21 22:20:50

Mid-June.

Did you find any technical docs from HomeAgain?

samy · 2009-07-21 23:06:31

This might related but not sure: http://www.webcitation.org/5fsCRL5Zz -- also check out the FDX section here: http://en.wikipedia.org/wiki/ISO_11784_%26_11785

I think the trace starts at x=4000 based off of this data but I'm not positive.

I was trying to find decimal 840 in there but couldn't (was looking at x=5568) since that code should be in there (see http://en.wikipedia.org/wiki/ISO_3166-1_numeric)

I will take a look at this trace later tonight when I get some time.

d18: grid function is awesome!

samy · 2009-07-21 23:10:32

I'm probably wrong, if it were ISO 11784:1996, and the trace starts at x=4000, it would also start at x=224 and that just doesn't look right.

samy · 2009-07-21 23:20:30

ryan, do you mind radiating your cat to the proxmark again and get another trace?

See if 10000 samples works, as well. This trace is a little weird as I don't see anything repeating, and a second trace won't hurt. Well, it might hurt the cat.

d18c7db · 2009-07-22 01:10:19

I can see a full waveform from 204 to 4300 (so a period of 4096 cycles) before it repeats, not sure exactly where it starts though. Probably some of those long consecutive pulses somewhere.

The smallest waveform cycle is 32 samples, largest appears to be twice that at 64. Does not smell like FSK, probably a simple encoding,

If a bit is about 32 samples then 4096 samples would fit 128 bits or 16 bytes so if his cats ID is 985121004515220 that makes hex "0003 7FF6 5B88 EF94"

d18c7db · 2009-07-22 02:15:53

Looks to me like manchester encoding and if I manchested decode the datastream I end up with the following 128 bit repeating stream "FF803FE0039D532D". Again not sure where the data starts but if you turn the above to binary the alternating nine ones and zeroes look like a sync marker.

ryan · 2009-07-22 17:22:53

According to wikipedia, it's not ISO11784:1996. Looks like it might be something proprietary.

http://en.wikipedia.org/wiki/Home_Again … ery_System

I've uploaded a trace of 16000 samples just for good measure. It's homeagain1600.pm3. The only thing that was hurt was the antenna (slightly) when the cat tried to get it.

I really think it's a period of 4096 as well. Using autocorr seems to show a definitive pattern that repeats at 4096 samples.

askdemod doesn't seem to like it, and neither does mandemod, though I'm probably doing something wrong.

Last edited by ryan (2009-07-22 17:38:16)

samy · 2009-07-22 19:12:40

I need to update the mandemod function to support variable peaks/valleys like in your trace. I changed the code but want to retest some of the other traces before I commit.

I would desperately be looking for either decimal "985" or "840" in the trace. If you can find either of those, you should be onto something. I say 985 because I believe that's a separate ID, and 840 is the country code for the US tags.

ryan · 2009-07-22 19:26:23

I was just about to ask if the fact that not all of the peaks/valleys lined up to the 32 sample boundary meant that it was a different type of encoding or if it meant that there were fewer samples per bit than we thought.

Have you seen variable peaks/valleys in other types of tags?

samy · 2009-07-22 19:30:18

I don't usually see this but I'm not really sure if that's indicative of anything meaningful.

The only other trace I've seen without static peaks/valleys is the Indala trace in the traces directory.

ryan · 2009-07-22 19:35:09

Maybe I just had too much coffee and it's the doppler effect of my hand shaking while holding the antenna.

samy · 2009-07-23 08:36:17

So I created a little perl script to help us determine whether tag data contains certain info we're looking for or not. It tries searching the binary data provided in a file for a string (hex/decimal/binary, in the end it converts to binary and searches).

It tests by searching normally as well as flipping bits, as well as testing for parity every 4th or 8th bit, as well as adjusting bit position to ensure bit positioning is correct. It also tries manchester demodulation on the data.

Needs a little work but might help out a little. I'll add to svn shortly.

donttasemebro:rfid samy$ perl rfidtest.pl /tmp/f 5b88
Testing normally...
Testing with flipped bits...
Testing with manchester demodulation...
Found 101101110001000 with parity every 9th bit, round 6 out of 8 (00100011011000100110110111000100011000100111001110101010011001100100011110110110001100111010101001100110000000000100100011001101101100011010010001011000)
Testing with flipped manchester demodulation...


donttasemebro:rfid samy$ perl rfidtest.pl /tmp/f 7ff6
Testing normally...
Testing with flipped bits...
Testing with manchester demodulation...
Testing with flipped manchester demodulation...
Found 111111111110110 in our stream (0101011011100110011101110010010000111011010011101110001100101010101110011001110111000101001001111001100101010101110011001111111111110110111100110010001001110001011011110100111)
Found 111111111110110 with parity every 9th bit, round 3 out of 8 (0101101100110011011100101000011111010011011100010010101001110011011101110010100101111001001010100111001101111111111101101110011010001001100010111111010011)
Found 111111111110110 with parity every 9th bit, round 4 out of 8 (101101110110011111100100000011101010011111100011010101011110011011101110010100101111001101010101111001101111111111101101110011000001001100010110111010011)

d18c7db · 2009-07-23 11:04:23

It should also search forward and backward through the bitstream.

adam@algroup.co.uk · 2009-07-23 16:22:17

I've added the homeagain traces to the repo.

adam@algroup.co.uk · 2009-07-23 16:38:37

BTW, if you want to compare it to a 11784/11785 tag, the traces file em4x05.pm3 is one - ear tag FDX-B ISO-11784/5 (ID: 6DB0840800F80001 - Application Identifier: 8000, Country Code: 124 (Canada), National ID: 270601654)

you wouldn't see "985" or "840" as you need to do all kinds of stuff to the binary before it starts to make sense, including reversing nibbles and bitshifting. See the " FDXBID" routine in RFIDIOt.py for exact details:

def FDXBID(self,data):
"Decode FDX-B ID"
out= self.HexReverse(data)
hexout= self.ToHex(self.NibbleReverse(self.ToBinary(out)))
# Application ID
self.FDXBAPP= hexout[:4]
# Country Code
ccode= hexout[4:7]
self.FDXBCCODE= int(ccode,16) >> 2
# Human Readable CCODE
if "%d" % self.FDXBCCODE in self.ISO3166CountryCodes:
self.FDXBCCODEHR= self.ISO3166CountryCodes["%d" % self.FDXBCCODE]
else:
self.FDXBCCODEHR= 'Undefined - see http://www.icar.org/manufacturer_codes.htm'
# National ID
natid= hexout[6:16]
self.FDXBNID= int(natid,16) &0x3fffffffff

samy · 2009-08-19 02:07:32

p.s., rfidtest.pl has been added to the tools directory

ghaber · 2010-01-04 18:55:11

Hello all,

I a now working with my parking gate card that seems to be very similar to the one of this post, and I am wondering if there were any other progress on this cat card.

I have loaded the trace in rapidshare link:

http://rapidshare.com/files/330298134/p … r.pm3.html

if anybody can take a look and let me know their opinion, I would appreciate.

It seems to be a PSK mod.

Regards

exidez · 2013-06-30 11:26:12

adam@algroup.co.uk wrote:

BTW, if you want to compare it to a 11784/11785 tag, the traces file em4x05.pm3 is one - ear tag FDX-B ISO-11784/5 (ID: 6DB0840800F80001 - Application Identifier: 8000, Country Code: 124 (Canada), National ID: 270601654)
you wouldn't see "985" or "840" as you need to do all kinds of stuff to the binary before it starts to make sense, including reversing nibbles and bitshifting. See the " FDXBID" routine in RFIDIOt.py for exact details:
def FDXBID(self,data):
"Decode FDX-B ID"
out= self.HexReverse(data)
hexout= self.ToHex(self.NibbleReverse(self.ToBinary(out)))
# Application ID
self.FDXBAPP= hexout[:4]
# Country Code
ccode= hexout[4:7]
self.FDXBCCODE= int(ccode,16) >> 2
# Human Readable CCODE
if "%d" % self.FDXBCCODE in self.ISO3166CountryCodes:
self.FDXBCCODEHR= self.ISO3166CountryCodes["%d" % self.FDXBCCODE]
else:
self.FDXBCCODEHR= 'Undefined
# National ID
natid= hexout[6:16]
self.FDXBNID= int(natid,16) &0x3fffffffff

I found this link explains it very well. exactly what the code above does.
Page 31 and 32
https://www.blackhat.com/presentations/bh-usa-07/Laurie/Presentation/bh-usa-07-laurie.pdf

Proxmark3 community

Announcement

#1 2009-07-20 10:05:39

New commands/features for the GUI client

#2 2009-07-21 17:15:08

Re: New commands/features for the GUI client

#3 2009-07-21 17:27:49

Re: New commands/features for the GUI client

#4 2009-07-21 17:34:25

Re: New commands/features for the GUI client

#5 2009-07-21 17:39:30

Re: New commands/features for the GUI client

#6 2009-07-21 18:12:37

Re: New commands/features for the GUI client

#7 2009-07-21 18:47:04

Re: New commands/features for the GUI client

#8 2009-07-21 21:41:21

Re: New commands/features for the GUI client

#9 2009-07-21 21:45:36

Re: New commands/features for the GUI client

#10 2009-07-21 21:46:40

Re: New commands/features for the GUI client

#11 2009-07-21 21:55:04

Re: New commands/features for the GUI client

#12 2009-07-21 21:57:06

Re: New commands/features for the GUI client

#13 2009-07-21 21:59:14

Re: New commands/features for the GUI client

#14 2009-07-21 22:11:32

Re: New commands/features for the GUI client

#15 2009-07-21 22:14:23

Re: New commands/features for the GUI client

#16 2009-07-21 22:20:50

Re: New commands/features for the GUI client

#17 2009-07-21 23:06:31

Re: New commands/features for the GUI client

#18 2009-07-21 23:10:32

Re: New commands/features for the GUI client

#19 2009-07-21 23:20:30

Re: New commands/features for the GUI client

#20 2009-07-22 01:10:19

Re: New commands/features for the GUI client

#21 2009-07-22 02:15:53

Re: New commands/features for the GUI client

#22 2009-07-22 17:22:53

Re: New commands/features for the GUI client

#23 2009-07-22 19:12:40

Re: New commands/features for the GUI client

#24 2009-07-22 19:26:23

Re: New commands/features for the GUI client

#25 2009-07-22 19:30:18

Re: New commands/features for the GUI client

#26 2009-07-22 19:35:09

Re: New commands/features for the GUI client

#27 2009-07-23 08:36:17

Re: New commands/features for the GUI client

#28 2009-07-23 11:04:23

Re: New commands/features for the GUI client

#29 2009-07-23 16:22:17

Re: New commands/features for the GUI client

#30 2009-07-23 16:38:37

Re: New commands/features for the GUI client

#31 2009-08-19 02:07:32

Re: New commands/features for the GUI client

#32 2010-01-04 18:55:11

Re: New commands/features for the GUI client

#33 2013-06-30 11:26:12

Re: New commands/features for the GUI client

Board footer