I’ve recently bought an ESPkey for a badge grabber im building.
the hex readings on the esp key (coming from a hid maxiprox reader) are slightly different from the hex readings im getting on my flipper.
the ESPkey leaves out first and the last half-bite of hex (always a 0 as far as i can tell) aswell as the 3rd half-bite.
i want to be able to take credential grabs from my ESP key, and replay them with my flipper, but it seems like the reads im getting from the ESPkey are incomplete.
does anyone have any experience with this or advise?
The flipper in my experience stores the hex without the parity bits, any leading 0s may also be dropped
1 Like
So i can be off here and some of the more knowledgable members can likely correct me but this is how i understand it.
The ESPkey uses the Wiegand library and is essentially a pentesting tool that just captures the wiegand data and then can replay it.
The flipper is copying and emulating cards.
The problem comes in that there are different cards and different protocols, some of which are still secure and the flipper wont be able to emulate.
Wiegand data however is completely cracked and there is no issue.
Why does that matter?
The Card Reader.
So the card reader is the one that is looking for a particular type of card/frequency/encryption. If it doesnt have those three things, it wont read the card to process the data.
Since the ESPkey lives on the Data line of the reader it doesnt care what type the card is. its just capturing the data, saving it, and replaying it.
This is why i think you’re having these issues. The data that the espkey is capturing is limited to just what it sees coming across the data line.
2 Likes
that confirms what i was thinking.
i found that adding “000000101” to the beginning of the binary string, and “0000” to the end, then converting to hex, and adding a 0 to the beginning gives me a uid consistent with the flipper, regardless of which hid prox credential i use (note, this method only works with the hid prox formatting)
2 Likes
When i was working on my project that used the ESPKey i gathered this bit of information regarding the Wiegand protocol. I dont know if it is useful to you knowing how its bits are arranged.
And this guy here did a really good write up on how he wrote a new card using a proxmark with the understanding of Wiegand Data.
So i think (big stretch) i was right. Because he took the wiegand data and “faked” the card data using available HID data
3 Likes
Here’s a comparison of the wiegand from the same card across the PM3, ESPKey, Flipper, and converting it by hand:
Maybe it’ll help show what’s going on:
Here’s the relevant format for this particular card (H10301, standard HID Prox):
Original post with error:
Here’s the relevant format for this particular card (H10301, standard HID Prox):
About that PM3 weirdness, I somehow got an extra “4” in the hex, my bad:
2 Likes
wow, many thanks yall. this alot of great information, and i’ll dig through it when i get some down time at work, i appreciate it
2 Likes
