Live data from Hacker News

Reverse Engineering the Facebook Messenger API

intuitiveexplanations.com

31–40 of 40 posts

Re: Reverse Engineering the Facebook Messenger API

#31
> Remember: Reverse engineering is ethical, pro-democratic, and protected under US law, but you still need to exercise integrity and responsibility when interacting with any online system.

US law is rarely simple enough to summarize in a sentence. This is no exception.

hiQ Labs, Inc. v. LinkedIn Corp might provide a useful sampling of things to consider.

> This case has been a litigation odyssey of sorts, to the Supreme Court and back: it started with the original district court injunction in 2017, Ninth Circuit affirmance in 2019, Supreme Court vacating of the order in 2021, Ninth Circuit issuing a new order in April 2022 affirming the original injunction, and back again where we started, the lower court in August 2022 issuing an order dissolving the preliminary injunction, and the most recent mixed ruling on November 4th, 2022.

> It certainly has been one of the most heavily-litigated scraping cases in recent memory and has been closely followed on our blog. Practically speaking, though, the dispute had essentially reached its logical end with the last court ruling in November – hiQ had prevailed on the Computer Fraud and Abuse Act (CFAA) “unauthorized access” issue related to public website data but was facing a ruling that it had breached LinkedIn’s User Agreement due to its scraping and creation of fake accounts (subject to its equitable defenses).

https://www.natlawreview.com/article/hiq-and-linkedin-reach-...

Re: Reverse Engineering the Facebook Messenger API

#32

I miss the good old days when FB Messenger was usable with ordinary XMPP clients. Platforms should be forced by law to open themselves to third party clients ffs. Yes, spam will be a problem - but seriously: FB is big enough to afford investigation teams that cooperate with law enforcement to tackle the spam at the source.

Matrix has a bridge that interfaces (very well might I add) with messenger. I haven't looked at the code but some control messages suggest the bridge uses a MQTT listener to connect to messenger.

Fun fact: there is a 'wishlist`-priority task sitting in FB's Tasks system with detailed plans for how to change the MQTT API to break third-party clients should any of them become too popular.

Re: Reverse Engineering the Facebook Messenger API

#34
post #17

It would've probably been much less ugly if the author reverse engineered one of the mobile apps instead of the web version. Those must use a much saner API that actually feels like an API. I myself reverse engineered and patched Instagram for Android once because I got fed up with ads in my feed, but there's a high probability that all Facebook apps use the same "proxygen" HTTP client library. This library is notabl…

> Xposed is very underrated as a reverse engineering tool. I fully agree, but on the off chance you don't know about it already, I highly suggest you look into Frida as well. It can do all the same things Xposed can (hook function, see or change output), but is a lot faster to iterate on since you don't need to compile anything and can even do some things in a REPL. That, coupled with the new jadx-gui's "copy as frid…

I heard about Frida but never tried it myself yet.

The thing with Xposed that makes iteration slow isn't even the fact that you need to compile your module. That part is fast. You also need to reboot the device to apply your changes, that's the slowest part.

Re: Reverse Engineering the Facebook Messenger API

#35
post #24
post #17

It would've probably been much less ugly if the author reverse engineered one of the mobile apps instead of the web version. Those must use a much saner API that actually feels like an API. I myself reverse engineered and patched Instagram for Android once because I got fed up with ads in my feed, but there's a high probability that all Facebook apps use the same "proxygen" HTTP client library. This library is notabl…

I know Kotlin and Java. Can you point me to any resources on this?

Not sure. I started reverse engineering Java apps very early in my life — initially it was J2ME games. Decompilers of the time sucked but that didn't stop me from modding Gravity Defied :P

I honestly don't know what's a good way of getting started on reverse engineering. There's a bunch of everything about Windows executables in particular, including "crackmes", but native machine code is a level up from JVM bytecode. Java classes and Android dex files can be decompiled back to sensible source with a good chance that you get something that can be compiled again. No such luck for native code — C/C++ compilation is a lossy process by its nature, especially the optimizations. Ghidra does a decent job but still requires a non-zero amount of manual assistance. Flash games also were good to hone one's reverse engineering skills since ActionScript decompilers did a pretty darn good job.

Anyway. To decompile dex to Java source, there's jadx: https://github.com/skylot/jadx

Since decompilation is sometimes lossy, there's apktool for when you want to put the app back together after tinkering with it: https://github.com/iBotPeaches/Apktool

It goes without saying that you also need a JDK and the Android SDK. In particular, you need apksigner form the SDK to sign the unsigned apks generated by apktool. You can also automate things a bit and use adb to deploy them to your device.

What I usually do is get a high-level overview of the app in jadx, and then modify the smali (dalvik bytecode in text form, very assembly-like) files generated by apktool.

Re: Reverse Engineering the Facebook Messenger API

#36

This amazes me with just how bloated and inefficient simple things have become. In ~4 decades we went from literal 'netcat chat' where your message may be shorter than TCP/IP headers most of the time, to slightly more featureful but still simple with IRC, and then the IM protocols of the 90s/2000s with even more features but usually quite tame (speaking from experience of working with MSNP). After that it started get…

I was building a Google Analytics looking admin interface for a company and I kept glancing over at GA requests/responses for guidance. It would send a ton of redundant data over for each 'next' table rows like the column headings and some styling stuff. It wasn't ugly but it was way heavier than needed. So I did similar and it worked great.

Update: Looking at the mostly unusable GA4, their 'next' table row responses are much more concise. The only problem now is that entire application is a pile.

Re: Reverse Engineering the Facebook Messenger API

#37
post #12

Earlier quoted context omitted.

Lack of incentives due to costs being externalized. It's not that they can't, it's that they don't want to enough.

Their profit motives are entirely aligned with reducing spam. I don’t understand why people always think hard problems aren’t solved because of some deep conspiracy. Sometimes they’re just hard.

> I don’t understand why people always think hard problems aren’t solved because of some deep conspiracy.

I didn't allege any conspiracy. I alleged that it isn't done because it isn't profitable enough.

Moderating is expensive as fuck, so platforms do the bare minimum required by law. Facebook makes 23 billion dollars net profit a year, Microsoft 72 billion dollars, Google/Alphabet around 60 billion dollars.

Even investing just 20% of these insane amounts of money into a joint effort to combat scams and cybercrime at the source (both by assisting law enforcement and by lobbying for laws) would put a serious dent into cybercrime. Imagine what someone like Pierogi of Scammer Payback, Trilogy Media and the other scambaiters could do if they had an actual budget, and now imagine what actual law enforcement could achieve if they had the resources to actually Follow The Money.

Re: Reverse Engineering the Facebook Messenger API

#38
post #32

Earlier quoted context omitted.

Matrix has a bridge that interfaces (very well might I add) with messenger. I haven't looked at the code but some control messages suggest the bridge uses a MQTT listener to connect to messenger.

Fun fact: there is a 'wishlist`-priority task sitting in FB's Tasks system with detailed plans for how to change the MQTT API to break third-party clients should any of them become too popular.

Did you learn about this first hand or is there any source you can cite?

Re: Reverse Engineering the Facebook Messenger API

#39
post #32

Earlier quoted context omitted.

Fun fact: there is a 'wishlist`-priority task sitting in FB's Tasks system with detailed plans for how to change the MQTT API to break third-party clients should any of them become too popular.

Did you learn about this first hand or is there any source you can cite?

There's nothing I can cite. Saw it myself many years ago. I doubt many of the people who worked on that iteration of Messenger are even there any more, but it shows the attitude of the organization as a whole.
Post reply on HN