stgl | 1 month ago | on: Ask HN: Share your personal website
https://stefan-gloor.ch
stgl's comments
stgl | 9 months ago | on: Root shell on a credit card terminal
Very interesting!
stgl | 9 months ago | on: Root shell on a credit card terminal
Thanks! Yep, I feel foolish. I just could not imagine it would be that easy on a locked-down terminal. But I learned for next time :)
stgl | 9 months ago | on: Root shell on a credit card terminal
Linux does not handle any secure binaries. It only shares a filesystem where the signed and encrypted secure images are.
The loadercode verification is not done in Linux, rather the insecure bootloader will read it from the filesystem load it to some memory address, that's it. From there, it is integrity-checked (?) and then executes on the second, secure core. This will then verify and chainload the secure image.
stgl | 9 months ago | on: Root shell on a credit card terminal
The binary that decides whether to boot or go into tamper mode is the "loadercode", which is integrity-protected (I think by a Boot ROM or similar).
The secure firmware can be updated, but it is signed as well.
stgl | 9 months ago | on: Root shell on a credit card terminal
Yes, 0.1 mm diameter enameled copper wire.
Chasing GPL violations sounds like a fun hobby :)
stgl | 9 months ago | on: Root shell on a credit card terminal
I had the same idea, but no, I tried with a second, untampered one and I also got a working shell. So it does not seem to be dependent on the tamper state.
stgl | 9 months ago | on: Root shell on a credit card terminal
Well, I felt like I first had to get a feeling for what I am working with. Hardware, what SoC, interfaces, flash etc... Otherwise I am too much in the dark. But sure, in hindsight I could've just tapped the debug connector and could have been done with it.
No, I got a shell on second, untampered one, as well.
stgl | 9 months ago | on: Root shell on a credit card terminal
No, it cannot load a separate bootloader. I tried to tamper with the loadercode (the "secure" bootloader), but it wouldn't boot. So I am guessing there is some third party (boot ROM) that verifies it.
Also, I think Linux always loads loadercode + mp1.img, regardless of the tamper state. The different code paths depending on tamper state are taken within the (integrity protected) loadercode.
stgl | 9 months ago | on: Root shell on a credit card terminal
I cannot tell for sure. I didn't have time to really look at the Linux applications and what they do exactly. My guess is that most of the sensitive stuff is done on mp1 (reading the card, verifying the pin etc.) and the Linux just acts as untrusted relay to the network. Denial of service should be possible in the sense that it could just put the system in a boot loop.
stgl | 9 months ago | on: Root shell on a credit card terminal
No, I don't think so. I think the tamper logic is implemented in hardware and cannot be easily fooled. It seems like both mp1 and mp2 access memory-mapped registers of the tamper subsystem to check its status (and other hardware system stuff like reset reason etc.)
However, I am assuming that there is a way to gain write access to the hardware registers from Linux. After all, the manufacturer has the ability to "un-tamper" devices and there is this nor_update tool in Linux that might be able to do it. But my guess would be that first a key has to be loaded through some authenticated interface in order to unlock that functionality.
page 1