Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Hi- I'm new to the forum but not new to RFID. I've done alot of decoding but am stumped using this tool around a specific situation. I've searched for hours on the forum and testing, to no avail, so would really appreciate it if anyone can assist
(grateful).
I have a Keri fob. Before telling me to read Keri posts, I've already done that and they've helped a little but not entirely.
Do an LF search, it tells me it's indala (but it's not). Also can't identify tag type.
Do rawdemod and provides binary but only what seems for specific block, and since it thinks its indala I believe not giving me the correct info. It gives me repeating info that can't be from all blocks, just 2 at most. And part of it is incorrect because doesn't have Keri header. Doesn't help at all.
What would help is to get a dump of all block data. I can do this when i know what tag it is (e.g., t5xx det/dump), but again, PM3 can't identify the tag used, neither can I. But I'm stumped as to why PM3 thinks it needs to know the tag type to do a dump of block data at all? I mean as long as the chip is in a field to produce backscatter, it should be able to give me all the binary on the card in block format?
I tried to do a data manrawdecode but whatever i do with this command gets errors. I think its because i don't understand the proper syntax with the command (the help and examples aren't really descriptive enough as to what should be entered after). I can't find detailed explanation or examples. Perhaps this would help if i could, maybe not.
Again, I've read the manual, wiki, posts, so doing this as a latter step where anyone can provide clarity as to the above would be great. thank you.
Offline
1. don't assume keri makes all their own tags
2. 2 blocks sounds about right
3. if `lf search` didn't identify the chipset along with the format then the chip is likely password protected or an unknown chip protocol. (or you got a bad read) - so a block read is likely out of the question.
4. the t55xx chips can be configured to respond with multiple different protocols if that protocol is not set or detected the response has no chance of being correctly read.
5. manrawdecode is intended to decode manchester binary (which would have had to have been demodulated from a raw signal first), but since your tag is probably PSK and manchester encoding is not used this is not helpful to you.
6. without a trace file shared we can only guess at what you are looking at.
hope that helps.
Offline
So I'm not assuming that Keri makes their own tag. I've been in the industry behind the scenes and know the supply chain (so i know they don't ;-).
I don't understand however why a password would make sense. The card and reader are passive. When backscatter occurs from card to Keri reader it will just barf all data, all blocks, reader will use header to identify it and strip out all except data used for wiegand for controller to authenticate. Are you implying that Keri readers have stored password to use to unlock password protected areas for some block data before this begins? I am not aware they do this (but could be new to me so want to clarify) but would be an explanation.
Tried t5xx commands, not happening. Its definitely PSK (and would assume such if PM3 is picking it up as indala since all indala are psk). For the heck of it i tried FSK rawdemod gets all 0's. However both P1 and P2 get data (different) so not sure which to use. Although the P1 matches the indala binary output I am getting from lf search. However I can't trust that data since its assuming its Indala (why does PM make such an assumption)?
I honestly spent a few hours trying to learn more about "traces" using PM3, but I can only find discussions that reference it in different contexts, not specific commands, output or what to do with it. Can you point me toward clarification here?
why would 2 blocks sound about right? I can't do anything with that data, particularly since it assumes its indala (doesn't tell me which blocks it is, nothing matches the keri header, and therefore, i have no idea which bits to focus on to decode (and that is if I am getting all that i need which is still in question).
thank you
Offline
so if keri doesn't make it then it very well may be made by indala.
it appears you do not fully understand the way most dumb passive lf chips work. if you are interested in the password and block read modes i suggest you read the ata55x7 datasheets. (x stands for 5, or 6, or 7 generation). (though i'm not sure it will help you in this instance)
for LF a trace is obtained after a `lf read (or lf search)` - `data save xxx.pm3` - post xxx.pm3 to a fileshare service and link here (can then be loaded later with data load xxx.pm3)
2 blocks is all the standard indala formats use. again to learn more about how the chips transmit it's blocks look into the ata55x7 datasheets.
what exactly are you trying to accomplish?
Offline
Hey Marshmellow,
Thank you for the time and attention to reply. Perhaps I'm not clear and is causing some of my confusion. I will dig into the atmel data sheets.
In the past, using different tools I've been able to work through nearly all raw data from obtaining block data. So that's where i'm coming from. Why? I'm trying to clone and enumerate a Keri fob (clone but also make ones with different valid CN's). However, not being able to get block data, and it assuming its indala (when it clearly is not, get to that in a moment), would lead me to believe that i am getting information specific to indala, not Keri, or is off-setting what i need to be looking for.
So, where I am at so far is that I have written to a t55xx card indala clone to block 2. Wrote expected Keri header to block 0. But when i look at the t55 card there are other blocks (#1) and #3, #4, etc that have data that I can't verify that are correct. So I'm thinking its not correct, but logic would be that I would want to compare all blocks form Keri fob to t55 and that way I can figure it out.
FYI, very few if any RFID card/fob vendors make their own cards, inlays and/or chips (two separate pieces). Most, except for one or two, outsource everything to contract manufacturers and just define the coding, transport key (if one applies) or have robots internally only for personalization/encoding. The one or two that do any manufacturing still use contract manufacturers for a good part of it.
This is important because even though its a "Keri" fob, it is doubtful they manufacture it. Indala is a brand acquired by HID, and didn't make psk under other brands. The other thing that is problematic with the assumption of it being indala (when it clesarly isn't) is that indala is infamous, in the real world, for implementing custom formats across their various channels. Hence, there are many variations of an indala format in same bit length. Hence, i like it may raise that is COULD be indala, but not useful because chances are it isn't or isn't the right format atleast for larger implementations where custom schemes prevailed to protect reseller supplier business.
I guess i can understand why PM3 would try and do this to make things easier but alternate methods to not use these assumptions is where I really need to dig in. However, I can't seem to find good documentation on many of the commends (lack context, examples, etc.). Not a criticism, just where I am lost burning alot of time and thinking there is info out there I just haven't found yet.
Offline
why are you so resistant to it being an indala format branded for Keri?
"and didn't make psk under other brands" - not sure where you get this as it is not correct.
not sure what expected keri header to block 0 means. there are many different keri formats some are psk some are fsk some are ask/manchester. there is no keri standard block 0 configuration.
indala clone will write block 0, 1, and 2.
there are a few more than one or two oem card manufacturers, but in general you are correct, many who claim to be aren't.
it also appears you may be using an older version of pm3 firmware. can you post the output of `hw ver` to confirm?
Offline
Its new hw version just updated. I will upload shortly to confirm.
I have worked in the RFID physical supply chain (and do a fair share of auditing them, thats all i will say on that) so i know fairly intimately who makes what for who. I wasn't stating that contract manufacturers are only one or two, but the vendors (Keri, HID, indala, etc.) contract the manufacture of chip, inlay and material out and in general, they are the same outfit and only vary slightly when going to less reputable brands. These are separate from chip silicon manufacturers, ones that do inlays, and sometimes encoding can happen anywhere from inlay to vendor.
<y reference is that I am not aware that indala made psk for other brands under other branded labels (they OEM'd their modules but kept the brand of the card when they did so, if they did). My statement was not broadly applied to all PSK, but indala. There could be edge cases where they did do this, but extreme edge cases and i'm not aware of them.
I am not familiar with the details of the keri format but from reading as many posts on here almost all them seem to state that keri has the same header data applied to block 0. So thats where i'm getting that from. If i use an indala clone command then i would assume that its putting indala header data and not keri. So, I figured (as some posts suggested) to write to block 0 the keri header that is expected. However, doesn't give me full transparency to check all data against sample card. Thats what I am really trying to get to, rather than use the assumption of it being an indala card - it is an assumption, and the bit format would be another assumption. Its usually larger enterprise where the variations occur, where reseller was trying to lock them in. This is why all wonky formats exist. Not for security, but to lock customers into suppliers. Unfortunately, I work with large clients that tend to have all the wonky formats so assumptions don't really help much of the time, so i need something lower level. Was hoping to not have to use an osciliscope ;-)
Offline
FYI, point taken that indala would write to blocks 0, 1, 2 but its assuming its indala and i have no method to confirm/compare to candidate card data (which is what i am inquiring about doing). I'm fairly certain its not the exact same as indala card. Do you have suggestions on how I can do this without using such assumptions and trusting that is is indala?
Offline
here is the version info (thank you)
Prox/RFID mark3 RFID instrument
bootrom: master-rysc/v3.0.1 2017-09-21 16:36:44
os: master-rysc/v3.0.1 2017-09-21 16:36:45
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2017/05/17 at 17:48:26
uC: AT91SAM7S256 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes. Used: 192856 bytes (74%). Free: 69288 bytes (26%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
Offline
what is the printing on the tag? it usually identifies the keri series type.
the K series is an example of a modified indala format
see http://www.proxmark.org/forum/viewtopic.php?id=2224
there is also the W series that is also a modified indala format.
most other series are not PSK.
Offline
also the rawdemod commands are just that, raw demodulation of the tag transmitted waveform (or detected tag backscatter), with no decoding/interpretation of the bits done.
Offline
Just Keri imprint. No printing or indication of K or W series on it. Gray, one side "Keri" other side nothing.
I was hoping to view the raw, identify known block data, start stripping out bits that made sense so i could identify which blocks to rewrite. I've done this many times before with other very odd formats, but, in those cases was able to get all block data. Trusting that its similar to indala would mean i am assuming its the same format. I can try it but run out of time to have fob on hand in lab.
So is that the best approach here? To just assume the best data I can work with is to work with the assumption of the indala format and go from there? I saw the post in the link you just posted. It wasn't descriptive enough for me to fully follow. The hex's given are for what block (2nd?, doesn't state). I'm scratching me head at what you posted referring to the bits (not sure what the bits stand for (or where you are generating those from, or what "h" stands for). but that may be what i'm looking for....thanks
Offline
FYI, regarding rawdemod. Why would it only give me a couple blocks at most? Is there a way to get all raw binary from all blocks? Going back to original question this is where i got stumped and wanted to close the gap. Without it i'm just trying to work with data not in view. hope tat makes sense (trying best to explain intent/objective)
Offline
Dumb LF tags know no blocks or memory segments, just a stream of binary it spews upon being excited by a reader. This binary is what the bits are. Aka The rawdemod output.
How much data is spewed is dependent on the chip config
Offline
Only in special modes do the dumb LF tags allow for block r/w. But those often are password protected.
Offline
I wish we could speak and clear this up in 2 minutes ;-) I think we are talking two separate things.
I understand what the binary of RFID being backscattered and read is. Sidenote, are you saying blocks technically do not exist on the chip or interpret by the reader? Either way binary being streamed needs to have header data to tell reader what type to expect. When i get the rawdemod of the Keri, it looks as if its missing binary data that i would suspect. I can go back and recount exctly but form memory i believe it was only about 70+ bits. I would expect more, but when i back out the clone input that I encoded I'm left with bits that don't make much sense (does not have a keri header tha tmost post say nor does it have an indala header I would expect. so this is why i was looking for more raw data (doesn't seem like I am getting all of it).
Offline
Just a thought,
I have seen Keri fobs that appeared to have only 2*32 bits (or 2 blocks if you count as ata55x7 from after configuration block) but they actually keep going from bit 33 "re-printing" the first bits, this goes on for another 128 bits or so until you can actually see some changes. This is where you get tricked into thinking there were only 32 bits of repeated data...
A trace would be nice.
lf read
data samples 16000
data save kerix.pm3then share the file with us.
Last edited by app_o1 (2018-05-03 13:27:24)
Offline