<- Back
Comments (45)
- MuromecI was dealing with a good old anti-tampering userspace library last week. They did everything right.The process detects that it's traced (by asking the kernel nicely) and shuts down. So I patched the kernel and now I can connect with and poke around gdb.I can't put a software breakpoint because the process computes checksum of it's memory and jumps through a table index computed from a hash, so I had to put the hardware read watchpoint on modified memory location, record who reads it and patch the jump index to the right one.Of course, there is another function that checksums the memory and runs the process into sigsegv, it has tons of obfuscated confusing stuff, so I have to patch it with 'lol return 0'.And then I can finally use frida to disable ssl pinning to mitmproxy it. It all took a week to bypass all the levels of obfuscation, find the actual thing I was looking for and extract it. Can't imagine how much time the people at $securitycompanyname spent on adding all those levels of obfuscation and anti-debug. More than a week for sure. What was it doing? A custom HOTP.It wasn't any better on actual secure boots 20 years ago where bootloader checksummed the whole firmware before transferring control, because bootloader itself was in ROM and of course it had subtle logical bugs and you only need to find one and bootloader is there in ROM bugged forever.
- mmoustafa> All encryption is end-to-end, if you’re not picky about the ends.This reminds of how Apple iMessage is E2E encrypted, but Apple runs on-device content detection that pings their servers, which you can't possibly even think of disabling. [1][2][1] https://sneak.berlin/20230115/macos-scans-your-local-files-n... [2] Investigation in Beeper/PyPush discord for iMessage spam blocking
- bjackmanThe phrase "threat model gerrymandering" is fantastic, is fantastic, I will be using that a lot I think.
- cryptonector> You need an integrated root-of-trust in your CPU in order to solve these.Yes, quite. The BIOS/UEFI absolutely needs to store a public key of a primary key on the TPM, probably the EKpub itself for simplicity. Without that you will be vulnerable to an MITM attack, at least early in boot, and since the MITM could fool you about the root of trust for later, as long as the MITM can commit to always being there you cannot detect the attack.
- badcryptobitch> Unexplainable security features are just marketing materials. I feel this way about a lot of hardware-based security solutions like TPMs, and TEEs. These are actually useful solutions that can help solve problems that we have (as evidenced by this article) but unfortunately, these solutions tend to be poorly publicly documented. As a result, we rely on academics to do the work for us in order to learn how to better contextualize these solutions.
- ragebolI expected something about cryptography keys hidden in a decoration somewhere (kinda like LoTR Gate of Moria style), article was not quite what I expected. Although it is in a sense
- maccard> All encryption is end-to-end, if you’re not picky about the ends.This is a great quote.
- anonundefined
- tucnakI find it surprising that IBM POWER9 had key imprints in 2017 (sic!!) and it's still nowhere to be found on contemporary CPU's...
- dist-epoch> Active physical interposer adversaries are a very real part of legitimate threat models. You need an integrated root-of-trust in your CPU in order to solve these.It's been almost 10 years since Microsoft, based on their Xbox experience, started saying "stop using discrete TPMs over the bus, they are impossible to secure, we need the TPM embedded in the CPU itself"
- maximgeorge[dead]
- Foxboron[flagged]
- jll29Given with yesterday's article on here about the issues of PGP, it looks like all software encryption short of a one-time pad are decorative.I like the idea of a key part of the the CPU (comment below); does anyone know why Intel/ARM/AMD have not picked up this IBM feature?