a more detailed explanation of how this project even occurred.
repo: trustdissues
twitter and apple insider brought my attention to this. after most of my twitter feed was tweeting about how apple can see what you're opening, when you're opening it (supposedly), the first idea was: how can we prevent this?
the linked article above mentions how it won't send to the ocsp server unless you're connected to wifi. obviously, turning off the wifi every time you launch an app is just annoying. so the thought was - the daemons always running right? if there's not an if statement and it's trying to send information to that server, how can we change it to prevent it?
that took some thought, until i came up with the best idea would probably be to send it to something that doesnt exist, to try to simulate an "offline" feeling. so thats what we did. but lets walk through the experiments:
originally the thought was, what if we could stop it from communicating at all? at first, i just removed the daemon. yeah. bad idea. made my session UNBOOTABLE, and caused a reinstall (yay!). so the thought is, system, probably (most definitely) looks for this daemon on boot right? (this is true, even on recovery boot).
so we cracked open the tools, and our favorite: strings, and changed the link in which we think it's authenticating with.
when turning off the wifi and looking at console for trustd, we can see that it fails to connect. the only LINK i found in the binary was valid.apple.com which contradicts the article, which says it connects to ocsp.apple.com.
after [examination], i found a decent-ish approach of changing the link available to me (i mean it makes sense). the c-strings listed that would definitely be something to do with validation servers and whatnot were:
valid.apple.comvalid.apple.com/seedvalid.apple.com/carry(doesn't exist on the aarch64 binary however)
so we changed the first bit of those from 76 to 61, giving us aalid.apple.com/$(whatever).
however, this is untested so it very much could be ineffective, because as of RIGHT NOW, big sur wont let me fucking write to my disk and test the patches. should definitely be appliable on catalina, and might work. or disallow you to enter the session. oh well! lol
after doing an annoying amount of work to write to the big sur file system, we loaded in the patched binary. killed the filesystem, doing a reinstall currently. the binary ITSELF has only a change in 6 c-strings, however after some reading on the SSV, i can only assume that perhaps it checks binaries and whatnot by hashes, and that replacing it with something with a new/different hash is just going to kill the filesystem. my original snapshot happened to die in this process, so now i have to reinstall. this leaves a couple questions:
- are system binaries checked and validated via hashes?
- does it know if values were changed and is it able to disable a boot into session that way?
- if any of the above are true, how do we work around them?