Hacker News new | ask | show | jobs
by dvt 839 days ago
Very clever way of doing this (though I have a feeling you could probably enforce pinning even in sandboxed mode). I remember trying to MitM Snapchat back in college and couldn't figure it out as they were also using cert pinning.
4 comments

I tried the same thing, and while I managed to patch the application and intercept the requests, I gave up when trying to RE the shared object responsible for request signing. I couldn't even find the entry point. For a relatively small social media app they had insane security already back in 2015.
> I couldn't even find the entry point.

Ha, same. I think I was eventually trying to hook into kernel-level functions and do it that way (I was using the Android client) but couldn't get far there either, though I think it's technically doable. IIRC, they were using some kind of vtable patching protection around kernel functions to ensure integrity.

I built anti-cheat software (and hardware) before, and it felt like anti-cheat level security. I had an axe to grind with Snapchat, as they rejected me after the first interview round :P

Snapchat’s founding principle and only differentiator from day one has been untrusted client security. There were way too many years where the general public believed that a Snapchat could not be saved. I give huge credit to Snapchat for accidentally teaching the public that if human eyeballs can see something, it can be recorded forever. Now that is taken for granted, even last week’s Saturday Night Live TV sketch referenced what a fundamentally flawed security model Snapchat has.
What? That wasn't a principle of theirs. They explicitly exclude "screenshot detection avoidance" from their bug bounty policy: https://hackerone.com/snapchat?type=team . They always have. As far as they're concerned, that's not a security issue.
BBP policies don’t align with anything except “we cba paying for that”
Snap has always had pretty beefy client security. Since, of course, a hacked client breaks the entire premise of their app.
Snapchat and TikTok both boast pretty gnarly RE-prevention measures.
For the uninitiated: TikTok is known to send and receive telemetry packages through headers in other requests (IIRC), and employs the use of a virtual machine(!) to execute encrypted client code.
Any source for that? What does "other" requests mean? Other than what? I doubt it could modify the headers of other apps.
Requests it makes for things required to function at all, video data etc. I guess? But this is the first time I've heard this claim.
Fundamentally, it’s hard to enforce certificate pinning if the user can modify the binary. Even if sandbox mode used certificate pinning, there would likely be some other way of removing the pinned cert checks.
> there would likely be some other way of removing the pinned cert checks

Yes, but it's significantly harder than flipping a bit. There's also clever ways of countering this (e.g. checksumming the public key). Of course, even this is technically hackable, but extremely time-consuming in practice. Imagine getting the public key and adding a bunch (and by a bunch, I mean like 16k) of random ops throughout the control flow that crash the app if any random byte of the key is wrong. For extra fun, offset the byte by the instruction pointer. Good luck debugging that.

This is a large part of Apple's control/Secure Enclave decisions. These decisions can seem arbitrary and anti-completive from the outside.
I wouldn't call it anti-competitive. Treacherous is a more apt description.

https://www.gnu.org/philosophy/can-you-trust.html

Apple is a west coast company and they like their west coast BSD licenses.
Not only anti-competitive but also treacherous. They exist to protect corporations from us, the users of the computers.
This seems unrelated?
I saw is as related by an entities ability to control certificates on platforms with zero trust.
Apple designs the platform, though. Seems like a different model to me?
Exactly I was pointing out why some may choose certain models. I would say that building a platform takes many considerations and the choices made led to this outcome. Apple made different choices and is often vilified for trying to maintain these protections.

Apple has been slowly making progress of opening up their platform. The next 3 years will introduce a new landscape for apps. People will still be complaining.

It prevents very basic RE / MITM.
You're right, it probably could have been implemented by only assigning the output of the sandbox flag function in the consumer function to true, but in this case it worked fine. :)
amusing how many of us have tried this with mobile apps to be thwarted

….until now