[idea] Registered UID Finder / Historical Data Gathering and Exploiting

[cjbrigato]

Is your feature request related to a problem? Please describe. No

Describe the solution you'd like In French residential systems – all using either Mifare Classic / SAK88 Mifare Classic clones / Hardened Mifare Classic from Mifare Plus – the readers always try to read the MAD (trying to authenticate sector 1 with a0a1a2a3a4a5 key) ONLY when the UID of a tag is unknown to their directory.

This behavior is due to the fact that if a tag is unknown, it could still be a valid 24h Master key from the VIGIK system itself (a tag made e.g. for post services which will be valid only for 24h and signed with private keys with Sectors containing the validity period. The Residential readers will decrypt and decode these alongside with country-wide law-enforced service codes to know if they have to force a door opening). In such case, the reader will try to READ THE MAD as a first operation.

This will avoid in some way the reader attack since unless you get a registered UID from the residential system you will always have a a0a1a2a3a4a5 key as a result fo the reader attack. And if you come testing with Simulated tag with Such A key for sector 0 then you will only get next sectors being tried being authenticated against VIGIK Systems A KEY 314B49474956 (which is 1KIGIV in ascii) / B KEY 010203040506 and won't be able to give anything usefull further (unless you are able to sign and produce the needed content for being validated as a valid master fob, and in such case you don't need any of what I'm writing about here). But This is a really interesting behavior because we can use this behavior to find UID which actually ARE in the residential system. If we want to test if a UID actually is registered in a residential system we just have to start simulation with the a0a1a2a3a4 key A set for sector 0

• If the reader correctly authenticates sector 0 : the UID is definitely not registered
• If the reader fail to authenticates sector 0 : the UID is definitely registered In such case and once we got a registered UID, we just have to start a classic reader attack with such UID : The reader will try to authenticate with the normal expected keys and the reader attack is likely to be a success.

Describe alternatives you've considered I don't know right now how effective this could be once made automatic. Using the reader attack as UID finder is too slow, and emulation is definitely better, but stil it can be quite long using lua. But this could be made an internal behavior / special mode of the reader attack to very quickly simulate random or ranged 4Bytes mifare classic 1K uids always with a0a1a2a3a4a5 A key for sector 0, change UID everytime the auth succeed and then stop once the reader try to authenticate with another key for sector 0. The UID can then be either reported back to user and it's up to him to do something with this information, or the Attack could automatically continue with this UID by starting a new normal reader attack with but with this UID fixed. Additional context May only be usefull for french residential systems but maybe some other places show the same behavior

[doegox]

Interesting! While quite specific obviously. Is it realistic to bruteforce 4b UIDs to find one known in the system? 4+ billions UIDs possible, maybe 200 UIDs known by a system, this is still 1/(2+ millions) chance finding one... If some 7b UIDs start being used, it becomes more interesting as they're not random but sequential so e.g. once you know one UID (maybe one from an expired La Poste?) you can try neighbor UIDs, starting from the left of the UID (after the "04").

[cjbrigato]

I think you won't find Expired 7Bites UID since they would use a non-registered UID with the VIGIK Signature system. But I understand your point.

Still, 4Bytes residential UID are not that random at all here. We got very few Main Brands managing central systems (Cogelec/Noralsy/Intratone...) and how it works is that at residential level, either the "local government" (municipality) if they own the residence(s) or the zone (multiple residences) or the "Syndic" (an association of all the appartment owners in one or a bunch of buildings) will buy a big batch of tags from only one main central system, all contiguous in "some way".

More than that, when you got in high density populated area some residence which are owned by Public instances, the whole area of up to 50+ buildings will all share the same Central systems, keys, Registered UIDS (even if the Access right MIGHT* differ). Statistically (95e percentile) it is enough to test for (1st and 2nd) OR (3rd and 4th bytes as 1 and 2nd) (because some systems invert indianness for no reason) randomness with only one tag uid to be test in every case.

Let's say we know the used endianness, the worst case is to test XX:XX:00:00 so 65024 tags have to be tested.

More than that, Both "Syndic" and Public instances reuses tags between their different areas, economic and money-wise arguments being throwed in. This means that, even if unactivated or with the wrong keys (because of different central system), an UID working in a public owned area residence as very very strong tendency of at_least being tried to be authenticated not as a VIGIK tag in nearly all Public instance area of this instance (In france, this would be at departemenal level, which is already huge, Very huge when it comes to everything near the capital).

In the same vein, Syndic became bigger and more "mainstream" services making money on the back of appartment owner, and they tend to manage their tagbase and residence security the same way : keeping every possible pennies in their pocket. Syndic makes it National wide, but inconsistent in geographical terms.

That is to say, the intention of this function is not really to have to bruteforce until a know uid. It is to gather Very efficiently historical data which, all of what I said accounted, would make breaking through very quick. Just as my Standalone (now getting quite aged but used to be fool proof in the capital and suburbs) was just using this described public and syndic instances behavior to break 95% of residential tags (when it came out) in under 500ms, What I state know is that with a little more workk on historical data alongside with as an exemple the reader attack, we can make it more up to date or at least very efficient and extensible.

Historical data exemple :

TAG UID  | PI/DEP or S.D.C  | CENTRAL(S)      
DEADBEAF |      PI/94       | Noralsy         
ADBE9912 |  Syndic-one      | Cogelec,Noralsy 

Such historical data would imply, as an exemple : That if you are in the Val de Marne (94) location facing a Public Instance Owned residence, then the DEADBEAF tag is a very strong candidate for a successful reader attack. But if you are also facing a noralsy then This may even be pointless Since we also have complete historical Data for the keys used by Noralsy, it most case we won't have to do such reader attack anyway but we're talking about the worst case here. If neither worked, we'll just have to try another candidate.

Another part of historical data I maintain is wether a central system is "secured" by the SAK88 trick or not. For the recall, some central systems were "secured" against Chinese Magic clones by Using tags with Normal x08 SAK in BLOCK 0, but the tag has to answer with an x88 SAK still. This was quite clever since if you want to send an x88 SAK with mainstream Magic Cards, you have to write the 88 in the BLOCK 0 data, which will not permit a access, since a 08 is still needed in Block 0 by the reader. For the recall again, Simulation by proxmark3 easily solves this problem, just as some Magic cards with enforced SAK88 are available here and there whatever the SAK you put in Block0. This is important historical data to have because on some systems, a failure to provide a SAK x08 in block 0 with a correct SAK88 presented alongside with correct keys and tag content Will trigger at least the ORIGINAL tag to be disabled, sometime with very strong scope (affecting every central system in the country) or triggering a stronger secure behavior on the system for a limited time. in 2019 you don't want to fail againts the SAK88 trick.

All this accounted, maybe the issue is unprecise or even mistitled, you decide. But I'd love to have you feelings on this, "this" being summarized as : we can use known behavior alongside with pm3 feature to efficiently populate and maintain enough historical data for future complex scripted or standalone automation or new attack vectors which would be worth a talk.

(I'm working right know on some "parser" wich will make big changes on my standalone. You can keep the historical data's of central as some "config file" in the flash memory like the key which should trigger the use of historical know keys and the keys known for each sector for the trigger. So we can quickly add or modify known historical data and use my standalone with custom and new cases.)

[doegox]

For sure I find your approach very interesting :) So I'd say go ahead, while trying to keep these additions as flexible/generic as possible, with the French specificities limited to the historical data files for example.

[cjbrigato]

Yes the struggle is to find what feature would be generic enough to be provide or extending the device function and what should not make it more further than standalone mode or Lua scripting.

[iceman1001]

But now @cjbrigato is having fun and interested... Good thing for us. :)