Proxmark3 community

ntk

Contributor

Registered: 2015-05-24

Posts: 701

Re: new lf commands summary

1/ oh dear how could I have missed reading the change document
3c/ Marshmellow Asper Jason and many senior contributors like iceman, 0xFFF, Mollusc, pwidi Yong jules  RFID field so it is not easy for me to disagree. since study of the format in the HID blocks calculator.xlsm, also in the thread T55x7 and Tags Emulation
I have unease feeling the AWID, INDALA, GPROX, GPROXII etc some how quite related on principle to HID concept. a little more complicated and hidden behide different mapping concept or more check bits, like in indala evey 4 bit is a check bit even or odd parity, but they do follow more or less the elements
preamble code, card format code, EP, Facility Code, card ID, Odd parity. Are they totally different format compare to HID? Maybe I am wrong

3d/"The hid sim and clone cmds don't need to know anything about wiegand or bit length because it uses the raw hex of the entire format." that is very clear and good to know. Sorry that I, an unbeliever, keep banging this door. Somehow last year our forum spend lot of time handle the problem getting clone over known FC, card ID number, so I had the always the impression that generating HID and AWID KANTEC from know description, without the card itself, would be the progress mark of our further understanding in these tags

marshmellow

Contributor

From: US

Registered: 2013-06-10

Posts: 2,302

Re: new lf commands summary

3c. don't confuse hid card formats programmed on chips to the wiegand format of the output of the readers that read them.  hid did not create the wiegand format.  hid just copied it as the output for their readers. 

that output format (wiegand) is the only tie between the formats you mention.  but the raw binary of the tag formats that are used to generate that output are very different.

3d.  understanding the individual wiegand formats used within a card format can assist in penetration testing when attempting an elevation in privileges attack by testing "the next number" in a format.  Only with a full understanding of each bit of the full card format can you generate the raw bytes to sim or clone without a reference card. 
and yes there is an ever growing list of these formats (there are literally thousands in the wild, which is why we cannot limit the base commands to one or two specific ones)

ntk

Contributor

Registered: 2015-05-24

Posts: 701

Re: new lf commands summary

"4) Adam laurie made some nice blogs about LF.  with descriptive pictures.  Just google him and rfidler.  You'll find both is his site and the kickstarter."

iI have both of them iceman
1/ RFIDler - An open source Software Defined RFID Reader/Writer/Emulator

2/ https://www.kickstarter.com/projects/1708444109/rfidler-a-software-defined-rfid-reader-writer-emul/posts/604981

i understood a little in document 1/ on how to use the blop technique to read 1 or 0 from signal following ASK/OOK modulation; but then in FSK signal I could not understand:
"So now, instead of signalling data directly by DAMPING for a 0 or a 1, we are creating a whole new CARRIER by DAMPING for different periods and allowing short or long pulses of the original CARRIER through. The fully DAMPED signal doesn't mean anything, it's the width and number of pulses of the UN-DAMPED signal that carries the information. In this case, 5 fat spikes means '0' and 7 thin spikes means '1' (or 12 thin spikes means '11'), so we've got '011010'. Neat!"
it is absolute terrifying where to read that neat "011010" sequence from

Or in case of PSK signal on few pages later, If we assume we're starting with a 0, this decodes as: '01101010001111100111000100010110000111010011100101101100001'. Easy-peasy!
Is that easy peasy. He's got 01101 I start with 01110 ...

Have you really follow those instructions and you understood howto to get your 1 and 0s out of ASK/FSK/PSK signal  ...

Apropos I think I can release the pm3commands.xml today so users can test and report issue before we have time to polish it again before binding it in a place next to the GUI SW release 0xFFF will soon complete. Where should I release? here, perhaps at this place
Whet your appetite ...    or new thread on the forum or could I send to you, so you will give it a place next to GUI  SW so people can easily report issue, and request maintenance , iceman? window user should test it, the more use it, the better test, clean out all errors for all areas HF or LF

the settings.xml or pm3commands.xml for proxmark3 version 3.0.1

it takes 31s for start up, enjoy.

Last edited by ntk (2017-06-23 19:31:09)

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: new lf commands summary

Just add your changes to the pm3commands.xml on GitHub repo and make a pull request (PR).

ntk

Contributor

Registered: 2015-05-24

Posts: 701

Re: new lf commands summary

thanks iceman. i have done it.

no6mis

Contributor

Registered: 2014-05-24

Posts: 8

Re: new lf commands summary

Hi,

are there any debug switches to enable some verbose output of the lf search command, like output of the recognized modulation or clockrate? I'm pretty sure that in the past at least the clockrate was shown in the lf search output.
I have some different em tags, recognized only by the proxmark but not by a generic em reader as they use different clock rates. I would like to know whether they also use different modulations as this seems possible based on the em spec.

Cheers,
Simon

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: new lf commands summary

For LF we have:

data setdebugmode 0     - none
data setdebugmode 1     - intermediate level
data setdebugmode 2     - nightmare level 

marshmellow

Contributor

From: US

Registered: 2013-06-10

Posts: 2,302

Re: new lf commands summary

2 is highest level of debugging on lf.  And is not for the faint of heart.

no6mis

Contributor

Registered: 2014-05-24

Posts: 8

Re: new lf commands summary

Thank you very much.