Hello,
I am trying to clone this particular AWID fob and it comes up as len 40 and unknown for fmt. Does anyone have a work around on how to clone this fob? Including a picture of what is imprinted on the fob.
[usb] pm3 → lf search
[=] Note: False Positives ARE possible
[=] Checking for known tags…
[+] AWID - len: 40 -unknown- (17520) - Wiegand: d3464688e1, Raw: 01242b2b1d42b18782111111
[+] Valid AWID ID found!
[+] Chipset detection: T55xx
[?] Hint: try lf t55xx commands
is “lf awid clone –raw {raw}” not working?
It’s probably not an exact awid bit pattern, and the awid clone code probably won’t make an exact copy. The t5577 dump and restore command would be better in this case.
Could you explain what this would mean?
The PM3 isn’t reading the credential correctly? Or the actual credential is malformed somehow?
lf awid clone doesn’t seem to have a --raw option
I tried lf t55 dump and then restore, it bricked the fob. Any subsequent attempt to reset it/wipe it will not restore the fob and rendering it useless. Any other suggestions?
You restored to the same source fob?
Everything about the proxmark is just timings and guessing. That’s why Indala often shows up, identifying noise as a valid tag. It’s just very simple pattern recognition, which is sometimes not accurate.. if somebody is using some sort of custom bit pattern based on awid, but it’s not a “real” awid pattern, you might have an awid ID in the data yes but there’s also be more information there in addition to the valid ID that the system uses for other purposes or even just for ID purposes.
With the advent of T5577 chips emulating different chip types, adding on arbitrary data to your RFID access control system and programming your fobs with these additional data is trivial. Let’s say I want to lock my customers into only my awid fobs.. I add some extra bits in the t5577 memory and I use that to verify that the customer is using one of my fobs and not another awid fob. Just a simple example but there’s all kind of weird shenanigans going on. That’s why the dump command is a better option if your source fob is a t5577; you get all these extra bits from the fob that the awid clone command will omit because those bits lay outside the awid ID bytes used to construct the ID.
That makes sense, thank you!
In this case as an unknown format, all the proxmark is doing is identifying the AWID header and then saying “here’s the rest”. it is unable to actually decode pacs data from the raw.
when it’s saying valid awid id found that’s a bit of a misnomer because it’s not finding an ID it can decode it’s just able to identify that based on the modulation, clock speed etc and the header (preamble) that it knows it’s an awid, the pacs itself is not known to the proxmark.
what is received by the proxmark in this scan is the same thing the reader will receive as it’s all the t5577 base chip is configured to transmit when powered, there isn’t more hidden data past this point [!UNLESS] the reader this fob is used for is sending t5577 commands to poll the memory to discover that data, which is not something domestically deployed ASC is capable of and i highly doubt this is the case, and if it was the case, there would be no need to make it come through as awid at all.
the raw is all the data past the header so we can manually construct a working duplicate onto another t5577 by doing these block writes:
0: 00107060 - config block, hidden data not transmitted, used to set up the analogue frontend to match how awids behave
Then we chop up the raw into 4 byte chunks to fit the memory
1: 01242b2b
2: 1d42b187
3: 82111111
(step commands for proxmark incase you want them)
lf t55 detect --IMPORTANT-- run this before writing anything to your fresh t5577
lf t55 write -b 0 -d 00107060
lf t55 detect --IMPORTANT-- reconfigures the proxmark to know how to talk to t5577s new frontend and allows you to see that your original command worked
lf t55 write -b 1 -d 01242b2b
lf t55 write -b 2 -d 1d42b187
lf t55 write -b 3 -d 82111111
lf search -- confirm output is same as original
@stalbertmama given your original is a t5577 itself, amal is correct in that it would be quicker to just dump your original and restore it onto a new t5577. steps below
on original:
lf t55 detect -- primes proxmark in how to talk to this t5577 in its current config
lf t55 dump -f myfob
on new blank t5577:
lf t55 detect
lf t55 restore -f myfob
as a general note, its imperative that you run lf t55 detect before doing any memory operations directly to any t5577, including dumping and restoring, writing or reading specific blocks or using clone commands. Block 0 is the analogue frontend and controls how the t5577 “talks”, the proxmark needs to be told how your t5577 is configured via detect or else it will use the default config when sending memory commands, which is why your attempt failed (we can fix it dont worry)
@stalbertmama do you have another t5577 we can work with or do you need a hand unbricking the one previously bricked?
Edit to add: sorry for the wall of text, im an asshole who likes to run my mouth lol i love you amal <3
damn, it could do with it, thanks for catching that
That logo is the Fairpointe logo, (upside down)
I could be wrong but I thought they came under HID not AWID
Have ypu tried HID commands?
lf hid reader
lf hid clone
I’ll delete this if im wrong
with domestic lf that is monodirectional (reader doesnt send any commands to the chip), the chip spits out its memory like so
{Header}{data}
the header is a pad of data that identifies what it is, in this case AWID, kind of like a brand fingerprint. this combined with the behaviour (modulation, clock speed, etc) shows its following data follows an awid format.
brands can have multiple ways to format the data (look at hid in the wiegand list theres like a thousand)
formats are just bitmasks, its the method for extracting the PACs data from the blob of data and checking for valid format parity etc, all this is bundled into the raw.
this is some examples, the system knows to exact which bits and what data they represent.
so with this AWID its just a matter that the proxmark doesnt know how to extract the actual facilty code/card number from the raw data so it just gives it to you raw, not that it matters for cloning.
in more recent years, some companies will use site/deployment specific masks that mean you can only decode the card number out of that raw, if you know the site specific key (different from fc) which is what this looks like, the proxmark cant know how to decode the PACs out of the raw.
does that make sense? i can expand on bits if you want but i dont wanna derail (more than i have)
farpointe deploy a range of chipsets (which is why they use T5577s instead of manufacturing chips specific to the format they want to use) for the sake of compatibility.
anytime fitness uses farpointe pyramid.
they’d not be of use as its not matching a HID header
I think it makes sense now, thank you for the info!
Mostly I was just unsure about this part, even an unknown awid bit format would still just be awid, so I just wasn’t certain what he meant. I hadn’t considered the possibility of adding some non-PACS data to the payload for other purposes
yeah it’s not matching the expected bit pattern for awid, so it knows it’s an awid but not fitting awids bit pattern
and it’s not so much adding junk data it’s more just scrambled in a specific way only the panel knows how to decode, so we can’t turn the raw into binary and try and pick out the numbers printed on the fob.
Right, but that would still be an “exact awid bit pattern”, just not a known one
I think my problem here was less a technical misunderstanding and more a language one, if that makes sense?
hi, thank you so much for all the help you have offered so far including other member on the forum. What you provided worked perfectly, after writing to block 3 and performing lf search, the fob was already reading the same as the original and I did not have to restore the dump. So this was a subtle difference as dump and restore was not needed.
*lf t55 detect --IMPORTANT-- run this before writing anything to your fresh t5577
lf t55 write -b 0 -d 00107060
lf t55 detect --IMPORTANT-- reconfigures the proxmark to know how to talk to t5577s new frontend and allows you to see that your original command worked
lf t55 write -b 1 -d 01242b2b
lf t55 write -b 2 -d 1d42b187
lf t55 write -b 3 -d 82111111lf search – confirm output is same as original*
Before I tried to clone it, I had done an lf t55 det as well as lf t55 info on the blank fob (which subsequently got bricked during the restore).
[usb] pm3 → lf t55 info – THIS WAS THE BLANK FOB PRIOR TO RUNNING lf t55 restore
[=] — T55x7 Configuration & Information ---------
[=] Safer key : 0
[=] reserved : 0
[=] Data bit rate : 2 - RF/32
[=] eXtended mode : No
[=] Modulation : 8 - Manchester
[=] PSK clock frequency : 0 - RF/2
[=] AOR - Answer on Request : No
[=] OTP - One Time Pad : No
[=] Max block : 7
[=] Password mode : No
[=] Sequence Terminator : No
[=] Fast Write : No
[=] Inverse data : No
[=] POR-Delay : No
[=] -------------------------------------------------------------
[=] Raw Data - Page 0, block 0
[=] 000880E0 - 00000000000010001000000011100000
[=] — Fingerprint ------------
[+] Config block match : T55x7 Raw[usb] pm3 → lf t55 det
[=] Chip type… T55x7
[=] Modulation… ASK
[=] Bit rate… 2 - RF/32
[=] Inverted… No
[=] Offset… 33
[=] Seq. terminator… Yes
[=] Block0… 000880E0 (auto detect)
[=] Downlink mode… default/fixed bit length
[=] Password set… No[usb] pm3 →
In its current bricked state, it is not responding to lf t55 det but when I change the bit rate to either 40 or 50, I can run lf t55 info and get some information but nothing comes up with lf t55 det
[usb] pm3 → lf t55 config
[=] — current t55xx config --------------------------
[=] Chip type… T55x7
[=] Modulation… ASK
[=] Bit rate… 4 - RF/50
[=] Inverted… No
[=] Offset… 33
[=] Seq. terminator… Yes
[=] Block0… 001080E8 (user set)
[=] Downlink mode… default/fixed bit length
[=] Password set… No[usb] pm3 → lf t55 info - - BRICKED FOB
[=] — T55x7 Configuration & Information ---------
[=] Safer key : 2
[=] reserved : 91
[=] Data bit rate : 3 - RF/40
[=] eXtended mode : No
[=] Modulation : 0x13 (Unknown)
[=] PSK clock frequency : 0 - RF/2
[=] AOR - Answer on Request : No
[=] OTP - One Time Pad : Yes - Warning
[=] Max block : 1
[=] Password mode : Yes
[=] Sequence Terminator : No
[=] Fast Write : No
[=] Inverse data : No
[=] POR-Delay : Yes
[=] -------------------------------------------------------------
[=] Raw Data - Page 0, block 0
[=] 2B6D3131 - 00101011011011010011000100110001
[=] — Fingerprint ------------[usb] pm3 → lf t55 det
[!] Could not detect modulation automatically. Try setting it manually with ‘lf t55xx config’
[usb] pm3 →
Any help/suggestions will be greatly appreciated.
lf t55 write -b 0 -d 000880E8 --r0
lf t55 write -b 0 -d 000880E8 --r1
lf t55 write -b 0 -d 000880E8 --r2
lf t55 write -b 0 -d 000880E8 --r3
lf t55 wipe
lf t55 detect```
```lf t55 detect
lf t55 write -b 0 -d 000880E8 --r0 -t
lf t55 write -b 0 -d 000880E8 --r1 -t
lf t55 write -b 0 -d 000880E8 --r2 -t
lf t55 write -b 0 -d 000880E8 --r3 -t
lf t55 wipe
lf t55 detect```
try these, let me know how it goes; do them all one after the other