XACv2 security flaw

Something for someone smarter than me,
@amal , @darthdomo, @Pilgrimsmaster, @TSMC55

Poking around at a lot of the xac variations or clones

A couple of them appear to include the IR receiver that the xac is wired for but doesn’t include

And it looks like the ir port is for some higher level programming stuff

Maybe you guys can make a bit more sense of this than me

I actually know the answer, but you didn’t ask me, so I’m not telling

eddbbc0d94f8d1ce40c63fe88545aa1f

3 Likes

Me too!

3 Likes

:roll_eyes: fine I’ll time travel and also ask you

Also I probably didn’t word my thought well… nothing new

But perhaps we can use the IR function on the xac (the sensor isn’t included though so we’d need to make one)

To maybe tweak the exploit… assuming it could be some version of the programming code mentioned above

2 Likes

@Pilgrimsmaster @TSMC55 well let’s hear it

The control unit above has it. All it does is allow you to add or delete cards by using the remote to enter programming mode and then either swiping the cards or entering their UID (via the remote).

Some of the controllers can also use a keypad (which is connected wirelessly 433KHz) and the code for that can also be programmed via the remote.

It allows for bulk deleting of cards as well, and for changing the length of time the relay is activated.

There is not really anything special about it.

Fair enough, I was hoping maybe the it port might allow to get a little more into the firmware

1 Like

What’s also interesting is

I doubt it would allow you to delete the exploit ID, but worth a try

1 Like

I was looking at the “new programming password”

1 Like

That’s probably similar to what I tried,

I burned a iso card with the exploit ID

I then tried to delete it with the
Master remove tag
Exploit tag
Master remove tag

No dice

All that does is change the default code (123456 from memory) to enter programming mode (which is the mode I described above).

1 Like

I think the reason that doesn’t work is that the exploit I’d is their “empty” state. They clear the memory to the exploit id so when you scan the card again it doesn’t have it in the memory. The fix would be to not scan the whole memory, just the number of addresses corresponding to the number of registered ids. That way it won’t see the “empty” memory as a valid user id

it doesnt make much sense for that to be the case tho. as the even parity bits and column even parity for an em410x id of FFFFFFFFFF would be 0. so the payload sent to the reader would have to be a correct 64 bit payload every time for it to authorise as the FFFFFFFF ID.

it being due to some empty memory buffer doesnt make sense even if you are just thinking of the ID and not the actual way EM410X works. as F is a positive value. if it was really due to empty storage it would be 0000000s and that would have the even parity but a value header of 1111111111

That’s why I put “empty” in quotes. It could be that they have a memory block for the ids that they initialize to FFFFFFFF when they want to indicate that it’s not a valid id. It would be interesting to sump the memory and see if that’s the case.

i think its less of a buffer memory problem and more of just its baked in for some unknown reason probably factory quality testing if you think about it. turn it on, have it scan an emulated UID that never has to change and then move on to the next one.

A blank EEPROM will be all FF’s same with flash, If it does not store the 64 bits (encoded data) but rather the actual ID then with 40 bits (5 Bytes), then yes a default slot would have FFFFFFFFFF id

Kind of think of it more like the Weigand … it’s encoded to transmit, but only the actual UID is used in the backend. but that would cause every single refresh when not in use to cause it to open the door/activate whatever its hooked up to

I mean… I was trying to be a bit more subtle about the uid… didn’t want to hand the proverbial key out to everyone but w/e

What do you mean by a “refresh when not in use?”

What about this one??

It looks the same as the xAC ?
But it’s not?

If the Uid is out of the bag maybe somebody could send me a tag with it, since I don’t have a writer yet,? Lol.

I’d be happy to get some and rest them.
I just don’t have the knowledge to help by deciphering the tag.

Hoping there’s a solution!!

Thanks for working on it guys!

Let’s just be clear… these is no such thing as an empty anything when it comes to digital memory. There is always a value. A bit is always zero or one. There isn’t any 3rd option for the bit to not exist. Therefore, at some point, the system needs to agree on and design around what represents “empty”. In the ASCII chart, character 0 represents null or no value… but it is a value. But why would eeprom follow ASCII convention? Why couldn’t the firmware developer choose all FF bytes as their “empty”? There’s simply no reason to favor 00 over FF.

I think what’s most likely is laziness over extra effort. To intentionally put a back door for FF is extra effort, but putting an index counter and shift all the “slots” in memory every time you remove an ID from memory…that’s a lot of effort. What is absolutely the MO of most software developers is to simply scan through memory slots until you find the ID and overwrite i with FF and jump out… because “nobody is going to have a card with all FF” … and it’s far easier this way.

To test the amount of laziness here… we could add the two tags. Add tag A, then tag B, then tag A again… remove tag A, the test with tag A. If they were super lazy, the second time you added tag A, it would have been written a second time. Then when you removed it, it would have removed the first one and stopped checking memory, leaving the second addition in memory. This would be the ultimate lazy approach… because “who would add the same card twice?”.

Granted it’s effort to check for an ID already in the system when adding, but two identical IDs doesn’t hurt anything… but when removing, the choice to dump out or keep looking and removing IDs is a tossup, because both approaches are practically equal effort… so hard to say.

My point here is that you can’t really reverse engineer the code without seeing it, but you can probably make assumptions based on the human nature of a badly paid Chinese coder who doesn’t give two shits about outliers in a country that is riddled with key cloners that would work with the very thing they are working on… so why bother.

5 Likes