Hacker Newsnew | past | comments | ask | show | jobs | submit | ridafkih's commentslogin

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


Out of interest, why not? I've needed to reverse engineer APIs in the past and using Android apps was always much easier so we always did that when the APIs were available.


Since the Messenger Application on desktop is much closer to the usage model of the Texts.com client. We want to replicate the desktop client as closely as possible. It can be assumed there’s going to be properties that are unique to the desktop client and vice versa.


Their Android application in particular allows the participation in a developer program which allows access to one of these menus. Not available on macOS and iOS unfortunately!


Years ago I did manage to get into the impressively huge debug menu in the iOS Messenger app on a jailbroken device. So they do exist there, or at least did back then.


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.


Very cool. I got so used to using burp all these years I never bothered to look into anything else. I’ll try this out.


Not the case with asymmetric encryption, you could encrypt with a public key and only the server's private key would be able to decrypt it. Not even the client could.


I think the person you're replying to perhaps meant that if you have total control of the hardware and the binary you can pull the value prior to being sent to the encrypt function.


Fair! In that case, yes you totally have access to the payload before its encrypted.


Asymmetric encryption is very computationally expensive - there's a reason that it's typically only feasible to use for signing a hash or as part of a key exchange to agree upon a shared symmetric key.


Envelope encryption works for that - client generates a random symmetric key, encrypts the data symmetrically, then asymmetrically encrypts just the key (which is then thrown away on the client). Both the symmetrically encrypted body and asymmetrically encrypted key are sent.


You just modify the client to leak the data before it's encrypted symmetrically. Keys don't matter at that point.


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. :)


I will say that ChatGPT did a decent job of explaining non-documented instructions in prior attempts of binary patching.

Now if I could feed an AI a binary and have it tell me where what is happening in a very broad scope, that'd be a game changer, and I'd say that's quite attainable with a high-context window LLM as they seemingly understand hex-formatted byte-code quite well.


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.


> 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.


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.



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.


Ok, that makes sense! Sometimes when you read a blog post that is well written and cogent it makes it feel like the author did it in 20 min!

If I end up in the same arena I think I’ll look for debugging code next. I love certificate pinning as a user, but as a forensic analyst I fucking loath it.


Even as a user I don’t there’s a good reason to love cert pinning. If you’re going up against adversaries that can compromise web pki they also probably have some other exploits up their sleeve to pwn you.

Cert pinning pretty much serves to protect companies from people reversing their protocols and little else imo.


It prevents attack vectors that involve attacker-owned certificate authorities as well as compromised certificate authorities from exposing user-data.

https://sslmate.com/resources/certificate_authority_failures


As a westerner I can only speak for others a little bit, but this is a very western perspective. Even Kazakhstan has been caught doing sketchy stuff with their CA.


If it’s managed well, certificate pinning takes the web PKI out of the implicit trust envelope for your app.

From a pure security perspective, why trust someone you don’t have to trust? The web PKI CA bundle is great for cases where it’s hard to have a unique trust root for your application - like you’re running in a browser with no privileges - but if you’re distributing code then you’ve already solved that problem.

Managed well, it should be completely transparent to users as well. Managed poorly and it can be catastrophic (your app is dead until users upgrade it).


i agree, feels sort of like "we have a walled garden dont anybody else use it cuz our stuff is super secret and secure, trust us(tm)"; it's a layer of obscurity for their "security" - in reality its the app on a users pc that both has this "secrecy" as well a the "handshake" to open it


Useless trivia: I believe Hassan Mostafa is the referee from the Quidditch World Cup in the fourth Harry Potter book. Obscure characters are my favorite SNs and dummy data.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: