> 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]
> the network traffic sent and received by mediaanalysisd was found to be empty and appears to be a bug.
I say "supposedly debunked" because empty traffic doesn't mean there's nothing going on. It could just be a file deemed safe. But then the author said:
> The network call that raised concerns is a bug. Apple has since released macOS 13.2, which has fixed this issue, and the process no longer makes calls to Apple servers
They're actually two separate claims, one of which the blogpost does support. The other one is seemingly ought to be supported by some conversations on a Discord server.
The concern is obvious though, not sure what's unclear about that: it's a bit pointless to have E2EE, if the adversary has full access to one of the ends anyways.
I 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.
How many more amateur attempts did these layers thwart? Did its creators collect enough revenue before the crack was produced?
I suppose uncrackable software, in the sense of e.g. license protection, cannot exist. Software is completely beholden to hardware, and known hardware can be arbitrarily emulated, and there's nowhere to hide any tamper-resistant secret bits. Only in a combination with locked-down, uncrackable hardware can properly designed software without critical bugs remain uncrackable; see stuff like yubikeys. Similarly, communication can remain uncrackable as long as the secret bits (like a private key) remain secret.
I'm not ever cracking anything, the software is free to use, I just wanted to mitmproxy it to see the requests and figure out some custom crypto inside of it
> 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"
The TPM itself can actually be discrete, as long as you have a root-of-trust inside the CPU with a unique secret. Derive a secret from the unique secret and the hash of the initial bootcode the CPU is running like HMAC(UDS, hash(program)) and derive a public/private key pair from that. Now you can just do normal Diffie-Hellman to negotiate encryption keys with the TPM and you're safe from any future interposers.
This matters because for some functionality you really want tamper-resistant persistent storage, for example "delete the disk encryption keys if I enter the wrong password 10 times". Fairly easy to do on a TPM that can be made on a process node that supports flash vs a general CPU where that just isn't an option.
POWER9 had quite a few neat things going on. I think it's unfortunate that it never became mainstream. The switch to closed source firmware in Power10 is also a downer.
I 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
> 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.
Readit News
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
> the network traffic sent and received by mediaanalysisd was found to be empty and appears to be a bug.
I say "supposedly debunked" because empty traffic doesn't mean there's nothing going on. It could just be a file deemed safe. But then the author said:
> The network call that raised concerns is a bug. Apple has since released macOS 13.2, which has fixed this issue, and the process no longer makes calls to Apple servers
The concern is obvious though, not sure what's unclear about that: it's a bit pointless to have E2EE, if the adversary has full access to one of the ends anyways.
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.
I suppose uncrackable software, in the sense of e.g. license protection, cannot exist. Software is completely beholden to hardware, and known hardware can be arbitrarily emulated, and there's nowhere to hide any tamper-resistant secret bits. Only in a combination with locked-down, uncrackable hardware can properly designed software without critical bugs remain uncrackable; see stuff like yubikeys. Similarly, communication can remain uncrackable as long as the secret bits (like a private key) remain secret.
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"
This matters because for some functionality you really want tamper-resistant persistent storage, for example "delete the disk encryption keys if I enter the wrong password 10 times". Fairly easy to do on a TPM that can be made on a process node that supports flash vs a general CPU where that just isn't an option.
This is a great quote.
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.