Proxmark3 community

jof

Contributor

Registered: 2021-01-23

Posts: 3

Salto Locks Exploration

I'm exploring a Salto lock system I'm working with for some time. I'm just a user of the system, so I am curious to see how much I can explore about this lock system from the outside, and I figure I should share with the community.

So.... this is a lock system for a multi-user building with some common house/building doors, and some more personal internal doors. This is an all-Salto installation by some kind of local reseller/locksmith company.

Most of the building doors appear to be connected to a central controller. In contrast, the internal doors are standalone, battery-powered cylinder or escutcheon lock/readers/PCD (Salto "XS4" types, it seems). From what I can surmise, the networked readers update some kind of binary certificate-like object on the PICC/fob, which is authenticated by the readers.

The PICCs/fobs are Mifare Classic 1k with known-default Salto A/B keys in mfc_default_keys.dic (*facepalm*). Looking through some documentation I could find about Salto ProAccess SPACE online, I couldn't find anything in the Mifare classic setup about changing the keys. Maybe they all have the default keys and hope that their cryptographic certificate is sufficient?
It appears that only sectors 5-15 have the Salto keys set. So far, only sectors 7,8,9,13,14,15 appear to get used.

I dumped one of my fobs and loaded it onto a Chameleon device and used it as my day-to-day key for a while, taking a dump after each PICC/PCD interaction. Then, I used mfdread.py and vimdiff to compare the dumps, change by change and took notes on what goes on.

(I index everything from 0)
Nearly always, Sector 9 / Block 37, at byte 1 is incremented and 2 is decremented at the reader.
With the offline readers, it seems to also update some 8 bytes elsewhere, and it seems to rotate around from place to place. Maybe this is some kind of anti-tearing mechanism for storing a rolling code of some sort?

Then, at the networked readers, it seems to update Block 52 (bytes 0-15), Block 53 (bytes 0-15), and Block 54 (bytes 0-4) (37 bytes in total) with some big object. Maybe some cryptographic certificate?

I also started recently messing around with the hf_14asniff standalone mode at the readers and seeing if I can tell what gets written. As (somewhat) expected, it seems to read blocks 52, 53, and 54, then 37, then some other block (I didn't sync up my notes/traces to see if this matches with the last-updated 8 bytes), and then updates it's 8 bytes.
I often see a lot of CRC errors in my trace output. Is it possible that it's trying to do something proprietary, or maybe it's just errors from the weak field?

Also notable is that the networked-readers sends what looks like the Magic Card wipe command (0x41) after selecting the card, but isn't preceded by a 0x40. (Maybe this is a distraction, and I'm being mislead by the "trace list -t mf" output)

If somebody is passionately interested, I have some dumps and traces I could share, as I am leaving this building soon.

Are these system details known? Does anybody know what the 37 byte "key" / "certificate" object could be?

Searching around for more information online, I found some firmware files for Salto for these locks, if you Google around, you'll find the same stuff. I have a backup if it disappears. These files seem to be in some kind of obscured hex-ascii format. Since they all seem to get loaded over a serial cable to a Portable Programming Device, maybe this is some kind of 7-bit safe transport?
I started trying to go a reverse-engineering route by looking up the FCC IDs of the cylinder locks. For example: https://fccid.io/UKCG90/Internal-Photos … os-2285833
On the standalone, battery-powered systems, it looks like these are running TI MSP430-based microcontrollers. Given the low power requirements, this makes some sense as a platform choice.
I am a bit stuck trying to find some kind of reasonable transformation on these hex-ascii files that results in some kind of object with embedded compression tables or reasonable-looking MSP430 opcodes.

If anybody has any insight into these firmware file formats or the details of the Salto cryptosystem, I would be really interested to learn/audit a bit more.

Stay warm and safe out there.

iceman

Administrator

Registered: 2013-04-25

Posts: 9,468

Website

Re: Salto Locks Exploration

... Good data collections is always welcome.

I take a backup of your files,

jeroenimo

Contributor

Registered: 2022-08-02

Posts: 3

Re: Salto Locks Exploration

I'm in a similar situation and building, with similar settings.
When needed I could provide dumps and stuff, I'm also the administrator on the Salto lock system.

vik0t0r

Contributor

Registered: 2021-09-25

Posts: 8

Re: Salto Locks Exploration

Theres also an schematic of the electronics  of the lock on one of the fcc archieves, although it seems to only hold the nfc transceiver and antenna and not the main MCU / memory.
In the place where I am, there are mifare classic 1k and 4k in use, on the first casse the data is stored in the last two sectors while  on the other the data is stored in the last one. In my case, (the multiple times that I have checked it) data is not written from locks to cards, the data on the card is only updated once you pass it through an online reader.
When someone is given new accesses, he just needs to update his card on the online reader, so the information of his news privileges must travel through his own card.
Cards also expire when a determined amount of time has passed without interaction with an online reader, for example, a normal user may need to pass through an online readed once in a month while the master key must pass everyday, so I guess that the time of update is stored inside the card.
Data on the card is also bounded to the UID, so cloning the data without the UID won't work.
Personally, I have been trying to reverse engineer salto apps on the playstore (one is for opening locks directly while the other is for updating the data on your card). It's pretty obfuscated, but I can assure you that the data written into the card is fetch as a whole from they servers, so info on a field to field basis is not available.
This two apps are not the only ones interacting with salto locks, I don't know why, but the official app from any spanish university (which in reality are the same but with different flavour) contains a salto api, which is the same as in the salto official apps, but in this case they have forgotten to remove the class names which gives more insights.
@jof through the  course of my investigations I have not been able to find the firmware files which you are talking about so I would be really grateful if you could point me in the right direction (or send me the files xdd)
@jeroenimo you say that you are the administrator of the system? could you send a copy of the software being used to write the cards? I guess that a lot of information can be retrieved from reverse engineering it.

vik0t0r

Contributor

Registered: 2021-09-25

Posts: 8

Re: Salto Locks Exploration

the schematic is on the UKCA9XX id, its from 2007, but maybe can be used as a starting point.

jeroenimo

Contributor

Registered: 2022-08-02

Posts: 3

Re: Salto Locks Exploration

@jeroenimo you say that you are the administrator of the system? could you send a copy of the software being used to write the cards? I guess that a lot of information can be retrieved from reverse engineering it.

Can't send you a PM.. other means of comms?

Last edited by jeroenimo (2022-08-04 12:37:42)

vik0t0r

Contributor

Registered: 2021-09-25

Posts: 8

Re: Salto Locks Exploration

Discord? I'm 0xf33ldead over there

vik0t0r

Contributor

Registered: 2021-09-25

Posts: 8

Re: Salto Locks Exploration

I have been looking through the binaries that you provided me for two months and forgetting about them for another two months. Now I’ll write everything I have discovered during this time:

Each salto system has a network of devices which it controls, (doors, readers, …). Once a reader is registered onto a system a number of parameters is sent to this. (SAM & Issuing options), this includes the mifare classic keys, but do not forget that salto systems supports a wide variety of physical supports.
A codrom (mifare classic uid), does not have to be unique, this means that is possible for the same system to have two users with the same codrom. Moreover, there are physical supports that do not have any codrom (as AT88SC153, HIDSEOS or BLE). When the physical support has a codrom, this codrom is XOR with the codsys, this means that if the key is cloned to another card (without cloning uid) it wont work, as the codsys will decipher to another one, and the reader will think that the card belongs to another system.

When interacting with the reader, there is another level of abstraction which prevents me from knowing which data field goes to which byte position into the salto card. But I have been able to view which data is stored into each card. Each card contains three files:
IDFile ->from my point of view, this is what identifies a user in a system
ATFile -> holds attributes, (for example the system blacklist, or the card expiration date if there are no updates)
Card Application Definition, seems to hold data about how the card is layed out, this bytes are the only ones which can be found on a dump of the mifare card easily.
I have uploaded some traces of the bytes interchanged between the reader and the server to read_key.pdf , as you can see, the server asks for one of the “files” and the reader answers. (maybe it would be possible to fuzz an emulated card and establish a relationship by seeing which bytes changes??)

Data is stored into the database mostly as cleartext, some columns are ciphered with AES, but the key is hardcoded into the code, which makes it a little bit useless.
   
That's all I can remember now.

Decompiling info, de4dot does a pretty decent job. Some important classes:
Class8188 -> crypto constants, (key for ciphering database)
Class8180 -> crypto functions, (functions for ciphering and deciphering)

Class3106 -> IDFile, this is extended by Classes NormalIdFile(Class3109), WorkingIdFile(Class3110), DeletedIdFile(Class3107), GobernantIDFile(Class3108)

Class3056 -> contains a list of all the supported ChipTypes

Each command sent to the encoder has its own class, for example:
Class287, checks the SAM parameters of the key by checking a checksum, (this is the command AF, which in the traces appears at the beginning)

And here are some breakpoints that i have been using for debugging (dnspy):
breakpoints

PD: I hope that this information is useful for somebody, if you have any doubts you can contact me, I’ll try to answer them.

vik0t0r

Contributor

Registered: 2021-09-25

Posts: 8

Re: Salto Locks Exploration

Opening up the encoder is clear that it has two cpu (and I think that this is usual in salto devices for example view the schematic of this old saltolock ), my best guess is that one is used for communicating with network / usb (server), and the other one is used for controlling the pn532 interface and the ble.

Extracting the firmware in this two socs, probably would be enough for unveiling the salto card format in its wholeness. On my own, I have tried by sniffing with a logic analyzer the communication between this two socs with little success.
It utilizes a RS-485 transceiver for implementing a protocol, where packets are sent continuously, even when there is no data to transmit. trace

vik0t0r

Contributor

Registered: 2021-09-25

Posts: 8

Re: Salto Locks Exploration

The major security flaw that i have think of is that if you were able to know which codsys a card contains, you could install a instance of the salto software with that codsys which will allow you to read / write / modify the contents of the card without problem.

And of course, if the system is using mifare classic keys, you can always clone them