This was initially an internal post at Texts.com that we decided to share, and I scrapped mention of the fact I had tried the exact same approach a few weeks prior and reached my time-box as well.

I initially spent two hours trying to modify different instructions, and then gave up. I saw another blog post written by a reverse engineer by the name of "Hassan Mostafa" (aka cyclon3) that previously succeeded in the same approach (taking Hopper Disassembler to Instagram on iOS) and I was inspired to try again that night, but I had no luck. I even found and attempted to modify the same instructions.

I decided to call it quits, and then a few weeks later with a bit of a grudge, I spontaneously tried again and I had it done in about 30 minutes after finding the sandbox function.

That's handy, and you can almost certainly hook the TLS send/receive functions in other ways, like with Frida, but being able to bypass pinning instead means that the researcher can route the traffic through existing tools like Burp Suite or mitmproxy.

Routing real app traffic through an intercepting proxy can be a real time-saver depending on what the researcher is trying to do. E.g. if they want to automatically tamper with a parameter in a request that doesn't happen until after some kind of authentication/session setup, it's much faster to let the app do all of that and configure the proxy to just make the one change, versus having to write a whole client that does all of the initial steps and then makes the modified request, or writing an eBPF filter that makes the changes the researcher is interested in.

Side note: this wouldn't work with Rust programs that statically link to `rustls`, the most popular Rust TLS library.

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.

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.

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

I always feel nostalgic when I see references to +Orc, or Fravia (RIP).

But I think there's still a lot of people doing the NOP-patching thing, albeit with more complexity. There continue to be people breaking DRM, and investigating random [mobile] apps with hex-editors & etc.

It's harder to get started these days as programs are more complex, but at the same time the knowledge required is more accessible.

This only works on Android, we had no interest in intercepting the Android application.

macOS (desktop), not iOS (mobile).

You have to resign the binary when you modify anyway which achieves the same thing.

On non-jailbroken platforms you generally do this with a developer certificate.

At least when I worked there, protecting against reverse engineering was never a goal. Cert pinning is to make it harder for an adversary to tamper, not to make it harder for the user to.

Meta's apps come with entire debug menus in production builds. The string that author found is likely part of such a menu.

Not really an AI problem though: that's just fuzzing. If the fail case is well defined then really all you need to do is prune the candidates down.

Now if AI could crack something like Denuvo in a 0-shot way...

Had tools like that already in the 90s, no AI, just brute force.

As the person who made this call originally at Facebook for the apps--it's not worth it. Any sufficiently advanced or motivated person/group/government would break through eventually...such is the nature of shipping client binaries. You can spend a ton of time and money trying to prevent it (for example Pinterest once was trying to ship their own custom language + vm, which I advised against) OR...just accept that your client code is compromised by default, put logic on the server, and move on with your life.

Cert pinning is basically free and is sort of a "you must be this tall to ride the ride" thing--not secure, but keeps the riff raff out.

Obfuscation has costs, and certificate pinning is more to make it more difficult for user-adversarial MITM than to prevent reverse engineering. Although the impact on reverse engineering is more than a happy accident.

At the end of the day, your code runs on user machines, and they can observe what the code does, so it's always possible to deobfuscate, and if one person does it and shares their results, it becomes very easy to replicate. That doesn't mean obfuscation is useless, but you shouldn't put too much time into it.

Because doing so is pointless for a mobile/front-end app. The attacker has physical access to the device; there's no way to stop them at this point. The only thing you can do is make the process more annoying in hopes that they will get frustrated and give up.

It's probably a matter of priorities, as well as cost v. benefit.

Obfuscation would've had very little effect on the outcome of this experiment, but might've changed the approach to involve dynamic instrumentation a little more. The most effective obfuscation I've seen is VM obfuscation, but that presents a significant performance impact. Obfuscation would also make legitimate debugging harder.

Preventing modified binaries is done at the system level, and could feasibly be implemented at the application level and is common, but this functionality itself could be both bypassed, or modifications could simply be implemented after security checks have completed (once again, through dynamic instrumentation libraries like Frida).

Engaging in a cat-and-mouse game with reverse engineers probably isn't in Meta's best interest.

How come every bank isn't secured like Fort Knox?

It's probably there just to prevent malware or company proxy from intercepting user messages... etc easily. Anything other is a happy accident.

Because they don't care.

Good question, Proxyman is the one I'm using in the writeup. It does route all application through it on macOS, and you can proxy iOS devices as well by installing a self-signed certificate on the device and connecting it through the proxy.

Unfortunately while this thing helps it doesn't actually conclusively stop any speculation. If I wanted to spy on you via app, I would encrypt the data inside the HTTPS stream and only decrypt it on my server.

And if spying works without using the microphone or whatever, the alternative is almost worse - it means Meta et al has such a good virtual “mind reading” Skinner model of you that they have a good hunch of what you will talk and think about. If we are not there yet, it’s only a matter of time with enough machine learning…

It's typically against terms of service to decompile or reverse engineer applications you download in this way, but it's also typically against terms of service to use their services from unofficial clients, so I think they're already way past T&Cs.

RE for interoperability is allowed in many jurisdictions (afaik, ianal)

What does copyright have to do with this?

Developers can store items in keychain on your device/icloud account that are only visible to the apps made by that developer (and not you). It is a feature that it works this way, and this whole concept is fucking insane to me.

I don't know why but your comment reminded me of learning about $SSLKEYLOGFILE and the ability to retroactively decrypt traffic captured in Wireshark: https://everything.curl.dev/usingcurl/tls/sslkeylogfile (I was expecting there to be an entry on MDN since my first contact with that env-var was from Mozilla's TLS library but no luck)

I guess it's the fact that in my mental model any supporting library doesn't have to be modified to allow viewing the traffic, and no cert-pining-breaks required

Cert pinning protects against compromised certificate authorities. There are hundreds of trusted root certificates in most operating system stores so one of them gets breached every once and a while.

Integrity checking is user-hostile, but certificate pinning can be good for users.

Eh, clearly it raises the barrier to entry significantly. You’re never safe from a truly determined adversary, but you can keep out the riff raff.

> With Meta’s Messenger application for macOS being so close to the Texts.com model—that being a standalone desktop application—Batuhan İçöz who is leading the Meta platform project at Texts.com thought we could gain some valuable insight by analyzing it.

Often the web interface will be using a different API or be missing characteristics that are being investigated.

And from Android 14 - adding a system CA certificate is a nightmare: https://httptoolkit.com/blog/android-14-install-system-ca-ce...

They're being hostile to security researchers - app developers don't like people snooping around their private APIs and whatnot. Nor does google, for that matter.

Every move Apple and Google are making on their platforms is about turning the devices we pay for into devices for the companies whose apps we install.

>I don't get why it has to be this hostile toward developers and why no option is offered to disable it.

If you can convince someone to install a certificate to violate their privacy you can just block the network, forcing the user to flip the setting. This allow apps to be able to protect their user's privacy from nosy enterprise network administrators.

Cracking (abbreviated “[k]”) is the term of art for making small modifications to a compiled binary to toggle functionality (usually disabling license/serial checks, but in this case cert pinning).

This usage is completely consistent with the typical and is well in-bounds.