Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

New RFIDler - Trouble reading AWID26 or HID prox tags

Hi all,
I just acquired an RFIDler at DEF CON and am very excited to start tinkering.

So far I have attached the USB/serial connection and gone through some basic functionality.  I have an AWID26 and an HID Prox card available for scanning but I get no data when using those tag modes.  (i.e. select fails, uid fails, reader fails, sniffer fails)  When I use askraw, I get uid and sniffer data out of each card but I do not get the same output repeatedly.  I assume this is because ASKRAW does not properly synchronize/demodulate the message but I do not understand why for example the AWID26 mode does not read the card which has 'AWID' embossed (and AWID26 printed on the back after what I assume are site codes).

I have confirmed that the 0057-beta firmware is loaded (re-flashed it myself).  Could I have messed up my coil in transit or something?  I assume there is no polarity for the coil so that should not be an issue.  Is it ok to have the card touching the coil while performing a read?  Do I need to prepare a casing?

Also -- in askraw mode I see a lot of high bits when no card is present.  is this normal background noise?

Any advice would be great.  I have rfidler.py up and running but I don't understand what the hardware test is supposed to do.

Thanks,
Craig
Tagged:

Comments

  • edited August 2014
    Kernel, I received one at DEFCON too.

    I'm having similar issues.  I'm using HID26.  I found that I really had to play with the coil positioning to get a good read.  Try to make sure that the coil and board aren't near a lot of metal.  If you sit them on a metal table, there is no way they're going to work.

    I've ended up getting a good read and have copied a card and told it to emulate it-- however I haven't actually got it to open a door yet.  It detects as a "foreign card."  Hoping to figure this all out!  Let me know if you learn anything!
  • Yes, FSK is a little fiddly - the problem is the coil tends to couple too well with the tag, so the circuit detects single large pulses instead of multiple thin ones. Running the plot function will make it clear what's happening.

    https://github.com/ApertureLabsLtd/RFIDler/wiki/plotting

    The best way to get a read is to use 'reader' and either move tag slowly away from coil, or move it off the edge.
  • Just tried putting the coil down on a better plane to the card and carefully moving the card around and I can get proper reads in AWID26 mode.

    Thanks for the advice!  I'll be sure to keep the list apprised of anything interesting.
  • elven
    Maybe something to do with the facility code?
  • After reading the plotting wiki I made a couple of changes to the firmware and I'm getting much better reads.  First, the plotting wiki says the high pot should be 110 instead of 100.  I tried to change this by setting the tag type then changing the pot setting with "potset h 110" but when I looked at the config it still showed 100.  Second I've been playing around with several frequencies and 125 KHz is working better for me than 130.7 KHz.  I'll continue to play with it, could just be it works better with the cards that I have.  I've also built a tag based on this design http://scanlime.org/2010/06/avrfid-1-1-firmware/ but that's pretty much expected.  It's nice to have a tag I can hook a scope to though to see how everything looks on that end to compare the RFidler with a commercial HID card reader.  Now, I'm going to see if I can add HID35 also known as Corporate 1000 tags, shouldn't be hard with HID26 already there.
  • POTSET does a direct setting on the pot. CONFIG is what's stored for that tag type and is only applied when you first set the tag type, so a subsequent POTSET should override. You can check what the pot is currently set to with the POTS command.
  • I've tried a LOT of different configs, and I can not reliably read HID26 cards.  For example, I have a Q5 card that I encoded a HID26 card to, which reads perfectly on a proxmark3 and the actual card readers, but I still cant get the RFIDler to read it.  I've tried moving the card around the coil, and changing the pot settings.

    It does read Q5 card information just fine though.

    @Sketch -- would you mind uploading your build of the firmware?
  • @Adam looks like it's working as expected.  It's interesting, if the tag is on or near the reader when I change the pot, then it doesn't seem to work, but if I move it away for a while then come back it starts working.  Is there a reason the default high pot is set to 100 when on the plotting page you say it needs to be 110?

    @RFidler you can get the firmware here https://github.com/sk3tch/RFIDler/tree/forked/firmware/Pic32/RFIDler.X/dist/default/production , I've started adding HID35 support, but if you try it you'll see it's not working yet . . . 
  • @sketch - no, no reason - just stuff getting out of step. A lot of the pot values changed when we went from beta version 21 to v22 which was the one for the production run, and I didn't get around to going through them all and updating them. If you're finding that 110 and 800 works better than 100 and 765 then I'll happily set those as the defaults...
  • @sketch -- Thanks, git wasn't pulling down the other directory with the modified firmware oddly enough.  Once I figured it out I can now read HID26 reasonably easy.  It still requires some moving around and adjusting.  The proxmark3 i have reads its almost instantly no matter what, so I wonder what changes can be done to the RFIDler board firmware to allow it to read as easily.
  • @Adam , OK, no worries, I just wondered if after the wiki was written more testing lead to choosing 110 for the pot setting.  The frequency setting doesn't have as much of an impact.  Thanks for the project, it's been fun to play around with.  I have HID35 read working now, I'm working on emulation, the parity is a lot different than HID26 http://www.pagemac.com/azure/data_formats.php but I think I've got that pretty much right now, but it's still not working.  I'm working to keep the code as consistent with what's there as possible.  You can find my code here if it's helpful at all https://github.com/sk3tch/RFIDler/tree/forked

    @RFidler , sorry I need to figure out how to merge it with master, that would probably make it easier, I'm not really a git guy.  I agree it reads much better, but still not great, not sure what can be done.  I've built a couple of readers based on other people's plans, and I've had mixed outcomes.  I'll keep playing with it to see what I can do.
  • @sketch I believe the parity on a hid35 simply overlaps - you use the first 18 bits and the last 18 bits. BTW, strictly speaking it's normally referred to as hid37 as you include the parity bits in the count.
  • @Adam thanks for the response, and thanks again for your work on this, it's a fun board to play with.  The card I'm working on is a HID Corporate 1000 card, with 32 bits of data and 3 bits of parity (total of 35 bits) as described in this page I referenced here http://www.pagemac.com/azure/data_formats.php .  Quoting from that page "This format uses a 12 bit facility code (bits 3-14) and a 20 bit card code (bits 15-34). Bit 1 is an odd parity bit that covers all 35 bits. Bit 2 is an even parity covering bits 3,4,6,7,9,10,12,13,15,16,28,19,21,22,24,25,27,28,30,31,33,34. Bit 35 is odd parity, covering bits 2,3,5,6,8,9,11,12,14,15,17,18,20,21,23,24,26,27,29,30,32,33. When calculating the parity bits, you must calculate bit 2, bit 35, and finally bit 1. What a weird format. I'm guessing this parity scheme is supposed to add another layer of obscurity."  I just noticed there's one slight error in this description, the first bit only covers 34 bits (it can't include itself because it's not calculated yet).  My understanding is many companies as they've grown have moved from HID26 to HID35.  Most readers do both, and if you need more than 65535 ID's (both active and inactive as people leave) then HID26 doesn't work for you and HID35 is a  reasonable choice, if you don't care that people can copy your door keys without you knowing ;).

    A while back I  modified the scanlime code to emulate this type of card (I've made at least a dozen cards like this).  I never wrote mine up but someone else wrote up their implementation (which is cleaner than mine anyway) http://trmm.net/AVR_RFID .  In other words, I can emulate this card with a ATtiny, but not yet with a RFidler.  Reads are working great though (the ID matches what's printed on the back of my card and what a HID reader outputs, so at least there's that). 
  • @sketch - ok, corp1000 is different from hid37.

    As far as merging in git goes, you should remove all your object files so you only have the same files as the original tree, and you'll then be able to send me a pull request when you're done and it'll be easy for me to diff the code and see what's changed...

    BTW, digging through the links you posted, this looks very useful: http://www.brivo.com/support/card-calculator/
  • @sk3tch -- Getting much better results after installing your firmware. 

    Thanks a bunch!
  • It seems to be different for different cards. If you plot any FSK trace you'll see that positioning of the card makes a huge difference. Changing the settings to 800/110 actually makes reading of most of the test cards I've got worse.
  • HID26 and INDALA224 read well for me with the forked firmware (especially after printing a case to hold everything together properly).

    Still not getting great results with AWID26 -- looking at some plots to try and visualize what's going on with that.image
Sign In or Register to comment.