15 ms·

Reverse Engineering Snapchat: Obfuscation Techniques

497 points by 3eed 6y ago

iampims 6y ago
Things were definitely much simpler a couple years ago.
- bri3d 6y ago
  I'm actually a bit surprised it's taken as long as it has for mobile obfuscation to catch up. Both on the Android bytecode and the iOS native code side there are obvious PC analogs in the form of .NET obfuscators for MSIL and packers and game DRM for native code. Of course, the Obj-C runtime throws a little wrench into things on iOS, making it a bit of a hybrid - but the approaches are still similar. It's still an ultimately pointless cat and mouse game as long as an attacker can trace the hardware (and with full-platform emulation tools like Corellium, this capability is unlikely to go away soon), but still an amusing one to watch.
  - dylz 6y ago
    I've seen this for _years_ already - it might also be because of a bit of an app usage difference, where the people that typically do these writeups or browse HN don't install the shitware on the app stores that do these things, except for rare common cases like large communications platforms (Snap) Many Asian mobile games run malware DRM like this - https://www.wellbia.com/home/en/pages/xigncode3-for-android/ https://www.wellbia.com/home/en/pages/xigncode3-for-android/ They are incredibly invasive and insecure, exfiltrate tons of PII (location, private IP, mac, ...) where possible unencrypted to bare IPs in various countries. This company in particular also has a PC-based anticheat rootkit that doesn't prevent cheating and allows the developer to "remote control the user", which is also an advertised feature.
programmarchy 6y ago
How many of these tricks are off the shelf techniques? Seems like a tremendous effort.
- zelly 6y ago
  There are numerous commercial compilers (for C and C++) that specialize in obfuscation. I suspect they are using one because to do that level of obfuscation manually would make the source code unreadable.
  - qvrjuec 6y ago
    Yup, they actually acquired anti-reverse engineering startup Strong.codes after using their software for years
- 3eed 6y ago
  OP here. About half are off the shelf. Joint functions, the breakpoint infinite loop, in-house memmove, the overflowing thing, those I haven’t read about anywhere before.
  - cremp 6y ago
    For the overflow, Jagex with RuneScape did it in Java. They also did stupid Object arrays 7 or so levels deep, doing casts on casts in between. The bytecode itself made the actual runtime slow to a crawl (anywhere from 5 to 10x slowdown.) This was circa 2014.
    - 3eed 6y ago
      That’s interesting to know
  - saagarjha 6y ago
    > the breakpoint infinite loop This is a fairly standard debugging technique. > in-house memmove You sure they didn't just statically link a libc?
    - sudhackar 6y ago
      > the breakpoint infinite loop Have seen multiple times in CTFs
MintelIE 6y ago
Doesn't Snapchat mainly rely upon the iOS or Android platform having some software that prevents screen shots if a 'no screen shots' flag is set? I always thought this was their core defense.
- bri3d 6y ago
  Their "core defense" for an end user is to notify the sender of a message if their post was screenshotted by using native screenshot detection/notification libraries provided by the OS, combined with heuristics to try to prevent them from beeing hooked and bypassed. However, the binary level protection is only tangentially anti-screenshot insofar as it also blocks third-party 'scraper' apps. Fundamentally, it's about requiring use of the Snapchat app to access the Snapchat APIs, and as we know from the ongoing saga with other social networks like Twitter, this is ultimately about business control over posts (preventing spam-bots, scheduled clients, and so on) and at the end of the day, ad revenue.
- dannyw 6y ago
  This is also trivially bypassed by the following technique: 1. Open the Snapchat app for a bit so it is downloaded / cached. 2. Turn on Airplane mode. 3. Screenshot and screen record to your desire. 4. Delete the whole app. 5. Turn off Airplane mode and download the app again.
zelly 6y ago
Snapchat is notoriously difficult to automate/spam. The goal is to get the X-Snapchat token. The most elegant solution is to find the secret in the binary and reverse the algorithm to generate tokens. Wouldn't it be easier to MITM the endpoint; set up a dummy server (which collects tokens) in front of a proxy that spoofs the DNS and TLS certs (may be easier on rooted Android than iOS). In my last attempt I gave up and went for dumb UI automation, but it would be cool (and worth good money) to exploit the private API.
- mox1 6y ago
  Certificate pinning spoils that, no spoofing of certs with pinning. Cert (or hash of) delivered with app. If server cert doesn't match expected value coded into app, someone is messing with something, terminate connection.
  - amerine 6y ago
    Just don’t do something like only trust a specific CA cert. really-really pin to a leaf.
  - zelly 6y ago
    Yes that complicates things. But if you can find the cert in the binary's data section, maybe you can patch it with your own.
    - __float 6y ago
      This probably runs into the same issue mentioned in the article, where the checksums are wrong and you end up in an infinite loop.
    - brendonjohn 6y ago
      Assuming this is for Android, the APK would no longer be signed and would cause all login attempts to fail. Have a read about "SafetyNet Attestion API" for Android.
      - 6y ago
akersten 6y ago
Wow, that seems really messy. If you're just after the API key or whatever, wouldn't reversing the Android app be simpler? As far as I know, you can't do all these low-level tricks on the Java platform.
- somehnguy 6y ago
  Java obfuscators exist too. I don't know how they compare in terms of complexity to reverse though.
- zelly 6y ago
  I think it's mostly native code on Android too except for the UI.
- georgiecasey 6y ago
  Android was way easier until Google started helping out and introduced SafetyNet attestation. I think it was orginally coded for Google Wallet/Pay but Snapchat were definitely using it from early on. Pokemon Go use it as well. Apple have no such system as far as I can know, and if they do, don't share it with 3rd party developers.
- pjmlp 6y ago
  Not only does Android use obfuscators as part of the build process, most applications make use of native code for their secure modules.
xuki 6y ago
Snapchat acquired Strong Codes in 2017. Before the acquisition they used Strong Codes compiler for obfuscation. https://www.bloomberg.com/news/articles/2017-07-21/snap-hires-swiss-team-behind-software-protection-startup https://www.bloomberg.com/news/articles/2017-07-21/snap-hire...
sbuccini 6y ago
I remember back in 2013(?) I went to a collegiate hackathon in Santa Monica. Evan Spiegel showed up to walk the floor and someone showed him how they had sniffed the API and did something interesting with it (forget the particulars now, getting old). If I recall correctly, Evan offered the kid a job on the spot but the kid turned him down. They've come a long way since then!
- 3eed 6y ago
  Hey Spiegel! If you see this I’m available for hire.
- plausibility 6y ago
  Was this perhaps LA Hacks [0] in 2014, or Hacktech [1]? Evan Spiegel attended LA Hacks, but I had someone who was attending Hacktech email me for help with the Snapchat API for their project. (I was part of Gibson Security, and published some early Snapchat API research [2] online in 2013) [0] https://en.wikipedia.org/wiki/LA_Hacks https://en.wikipedia.org/wiki/LA_Hacks [1] https://medium.com/hacktech-2014/everyones-watching-hacktech-5b58c3859747 https://medium.com/hacktech-2014/everyones-watching-hacktech... [2] https://gibsonsec.org/snapchat/fulldisclosure/ https://gibsonsec.org/snapchat/fulldisclosure/
  - sbuccini 6y ago
    Almost certainly HackTECH; it was held in a mall in Santa Monica right by the beach. I’m almost sure Evan came but it wasn’t to give a formal talk, but rather take a pretty low-key stroll-through. Maybe my mind is playing tricks on me. I did attend LA Hacks as well but I think it was in 2015, it was in Pauley Pavilion for the first time. Your research looks fascinating and sounds similar to what I remember of the hack. Might be the same person we’re talking about. Small world!
    - plausibility 6y ago
      I did some more searching, and I think it was Hacktech then. According to [0], Evan dropped by because of the project by Ash Bhat and Ankit Ranjan, apparently some of the organisers called him since he lived nearby. Seems you were right. [0] http://appstorechronicle.com/2014/01/exclusive-snapchat-hackers-friend-4-million-users-and-show-work-ceo-snapchat.html http://appstorechronicle.com/2014/01/exclusive-snapchat-hack...
rvz 6y ago
Well at this point, you might as well run the binary in a Mach-O ARM emulator since Snap has seriously cranked up the reversing difficulty to level 10,000. I suggest anyone looking at this would need to use Corellium such that Snap has made it hard for almost anyone to get their private API.
- 3eed 6y ago
  Your only hope for emulating the whole thing would be Corellium, really. Too many real-device-dependencies.
  - sprite 6y ago
    This was a few years back but I had token generation working with something much simpler than Corellium using https://github.com/unicorn-engine/unicorn https://github.com/unicorn-engine/unicorn emulator [You will need to set up CommPage, handle system and mach traps, load dyld, etc]. They've probably added more security since then but back when I looked at it some of the data that was encrypted in the token off the top of my head was: - Request Path - Timestamp - Snapchat Binary Size - Bit Flags for various hack checks such as jailbreak, checks for various tweaks, etc. - Device Type - iOS Version - A pair of counters, I believe these were being used to detect real devices being used as signature proxies. - A unique device ID generated at startup I can't remember which one of the tokens this was for. There is a X-Snapchat-Client-Token used at login if I remember correctly and X-Snapchat-Client-Auth-Token which is used for every request. I never ended up using it for anything but it was a lot of fun getting token generation working through emulation. I'm not sure if I was actually able to bypass all their checks or if it would have been detected had I actually tried to deploy it for something in production.
jayd16 6y ago
Philosophically I never gave much thought to securing app client code. Why not just track usage stats and ban clearly fake/high throughput users?
- qvrjuec 6y ago
  Because the users who were less clearly fake would still degrade the experience of the rest of the users. To use an analogy, consider currency counterfeiting. The government doesn't just look to see who is spending lots of cash without a job because it's a much harder problem than making the bills extremely difficult for the layman to forge. Same principle here - making the token extremely difficult to forge is the easier route. You don't catch 100% of the bad actors in either scenario, but why not use all of the tools available in your toolbox?
  - jayd16 6y ago
    I'm not sure this analogy tracks very well. The government doesn't bother heightening the quality of one dollar bills, either. The government doesn't have information about every transaction, a web API does.
    - theincredulousk 6y ago
      These techniques are largely automated through metadata during a build process. It takes effort to setup, but not nearly as much effort as you think. The effect is asymmetrical- what takes you 1 hour to do costs a reverser 100. At least as time efficient as implementing backend detection algorithms.
- dylz 6y ago
  Because not so clearly fake users still make it through. The server side is also fairly quick on the trigger if you accidentally send anything that doesn't make sense, you're kicked off to "re-verification land"
- RNCTX 6y ago
  Because Snapchat is ultimately an application designed to trade in porn of amateurs including (and perhaps especially) teenagers. They have a vested interest in playing dumb to that fact. They can't really do so if the content escapes out into the wild and shows up in congressional hearings, lawsuits, FBI investigations, DOJ reports, etc.
just-ok 6y ago
This is an awesome write-up; I’m shocked at the level of effort that went into Snap’s obfuscation process. It implies that are entire teams of engineers out there whose sole job it is to play cat&mouse with reverse engineers and nothing more. Another comment mentioned that this effort is outsourced, so not only are there teams, but entire companies dedicated to this! What a blast that must be... though the immense amount of [invested|wasted] (take your pick depending on cynicism) effort spent on this game makes me a little sad. All of these brilliant minds just... cosplaying Sisyphus?
- zebraflask 6y ago
  I can't help but wonder if it's more of a "a little from Column A, a little from Column B" scenario. There's no doubt they have skilled security staff, but - as a company overall - they also grew very quickly. How much of that obfuscation is intentional and how much might just be old code from a few years ago that nobody got around to removing? Before it was passed through obfuscation.
  - 3eed 6y ago
    The vast majority of these obfuscations (maybe except for the scratch arguments one) are done as LLVM passes, so it's done post-code writing, writing code like this would be unreadable and unmaintainable.
  - xuki 6y ago
    I'd say they make it a priority to keep people from tampering with their code, and maybe maintaining the platform's integrity. They even ban people who use tweak on jailbroken iPhone/Android. I found these articles about avoid Snapchat detection a while ago, it's a cat and mouse game. https://aeonlucid.com/Snapchat-detection-on-Android/ https://aeonlucid.com/Snapchat-detection-on-Android/ https://aeonlucid.com/Snapchat-detection-on-iOS/ https://aeonlucid.com/Snapchat-detection-on-iOS/
- deleted 6y ago
  [deleted]
- dylz 6y ago
ed25519FUUU 6y ago
> To make your life even more miserable, Snap ocassionally deprives you of recognizing some basic standard lib functions ... You won’t be very happy after spending a day or two reversing a function to find it’s memmove in the end. That sounds particularly devious.
deleted 6y ago
[deleted]
mises 6y ago
This is some pretty heavy-duty obfuscation. What is the business case for this amount of work towards preventing reverse-engineering? Decent rate limiting should be much more effective than making such a herculean effort to obfuscate one's API. Edit: another comment mentions that snap chat uses an existing solution, which makes more sense than the expense of developing this sort of obfuscation in-house: https://news.ycombinator.com/item?id=23558784 https://news.ycombinator.com/item?id=23558784
- dannyw 6y ago
  Specifically, Snapchat wants to stop "tweaks" and alternate frontends that allow for bypassing of Snapchat's self destruction controls. This is especially important given that Snapchat is widely used to trade amateur underaged pornography.
surround 6y ago
There are already alternative front-ends for YouTube, Facebook, and Reddit. I’d love to see one for Snapchat and Instagram, although it looks like one for Snapchat would be incredibly difficult.
- SXX 6y ago
  Most usable alternative front-ends for such services are usually just parse web API or even plain html in case of YouTube. Snapchat don't have any web app so parsing it is tricky and Instagram provide only limited set of features on the web.
Commodore_64 6y ago
Great write up! Thanks for posting!
htgb 6y ago
Interesting read! I'd love to read the next post, but at least Miniflux can't find any feed. 3eed, would you be open to adding an RSS feed?
- kchr 6y ago
  Yes please!
- 3eed 6y ago
  Sure! I'll consider doing this before the next post
  - htgb 6y ago
    Thanks!
xwdv 6y ago
If you dig very deep, you can also find an offer to come work at Snapchat. Most will never find it.
- Nextgrid 6y ago
  Those who do have the skill to find it probably have better places to work for than a barely profitable company whose only revenue stream is to push trashy clickbait.
  - xwdv 6y ago
    Barely profitable companies regularly pay big salaries for the right people, it’s why they’re barely profitable.
- 3eed 6y ago
  Hmm, I wonder how deep one should look. Why don't you shoot me an email at hot3eed at gmail? I'd appreciate it a lot!
jor-el 6y ago
Some I see are surprised to see the level of obfuscation used in the application. Many pointed, many ingredients for the obfuscation used in the app are off-the-shelf and few of them can be said to be well known in the industry, but still there is a cost in integrating them into a product. Obfuscation is notorious in breaking things which should work normally (normal compilation process) and as a own goal making it hard to debug as well. Integrating, testing, debugging and difficulty in debugging production crash logs is a considerable cost. That said, obfuscation is increasingly being used in mobile applications now. Check your banking application or some government applications, you will find obfuscation being used. With mobile applications getting richer and lot of code executing on the client side, makes it compelling case to secure applications by using obfuscation (as a defense-in-depth approach). Open standards like OWASP MSTG [1] MSTG-RESILIENCE-9 recommend such approach. Obfuscation is applied to programmatic defenses, which in turn impede de-obfuscation via dynamic analysis. [1] https://github.com/OWASP/owasp-masvs/blob/master/Document/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md https://github.com/OWASP/owasp-masvs/blob/master/Document/0x...
- pjmlp 6y ago
  I think that it is due to the copy cats that keep stealing apps and repacking them. Most Android developers lack native coding experience, so after failing attempts to protect their applications with the DEX bytecodes obfuscator, they think that recoding parts of the application with the NDK will save them. However as this article shows, and most here know, they shortly learn that against good attackers, the only benefit from using native code directly is it takes a little longer to decipher what the application does. So then one turns to solutions like what you are describing.
  - grishka 6y ago
    > they think that recoding parts of the application with the NDK will save them. Yeah like that one app I reversed a while ago that generated the API key in a native library. I was able to get the key by building my own app around their library and calling the function that returns the key. Didn't even have to disassemble the thing.
brendonjohn 6y ago
This is brilliant work, I'm hoping in part II we get to see it working against the API. I reverse engineered this in a production environment. It took approximately 7 months to build a scalable solution. The investigation on how to create the x-snapchat-client-auth token is brilliant. One day I hope to do a talk on what my old team did to circumvent it. There's a painful gotcha on the homestretch for this token: You may be creating the token, but it's not obvious what you're supposed to be using the method to sign. What do they use it for? As far as I could tell, it's so they can verify requests at the edge nodes of their network. When you provide a bad x-snapchat-client-auth, you get a near-instant 403.
- krankthat 6y ago
  I'd be fascinated to read about your old team's work!
- bluesign 6y ago
  I think edge node is just checking if x-snapchat-client-auth valid, without checking if x-snapchat-client-auth is valid for this request. The second check is probably done at deeper level.
hn_throwaway_99 6y ago
I'm curious, can anyone recommend any techniques (or companies providing solutions) for attempting something similar with javascript in a browser calling an API? Obviously it's much more difficult to obfuscate an algorithm for generating a client token in JS than it would be in assembly, but I'm just curious if anyone has tried any form of "lock down my API so it's only callable from the web front end I provide" obfuscation.
- nerdbaggy 6y ago
  WASM would be a good option I believe
- londons_explore 6y ago
  Recaptcha tries to do this. Their approach is to make a blob of code which collects all kinds of details about its environment (for example, Object.keys(window) ). It then uses a hash/concat of those details (with some random too) to decode data to decide what else to collect, hashes or concatenates those in too. Repeat a few times. Then send the final data blob back to the server. The server can then run a tiny emulator to run the code with the same seed random to check the results are the same on a whitelist of allowed environments.
- zelly 6y ago
  >"lock down my API so it's only callable from the web front end I provide" Generate secret tokens that the server can validate using some heavily obfuscated process. Compile the JS to WASM. If you can use HTTP3 or WebSockets that's a bonus, because you can create a custom protocol that does some secret handshake before sending the goods.
- the_duke 6y ago
  You can study the Instagram or TikTok web versions for inspiration. Both use some wacky methods for request signing that include encrypted code, obfuscated control flow, hashing the browser environment, ... Assembly obviously allows for much more powerful obfuscation than Javascript. Webassembly is somewhere inbetween, but a viable path since it is pretty universally supported by now. Networks requests can be inspected trivially in the browser though, which makes things a lot easier.
saagarjha 6y ago
> In Mach-O binaries, functions whose pointers are in the __mod_init_funcs run before main. Remember that obfuscation makes your code run slower. This specific one is part of the reason why the dyld team probably hates you.
- theincredulousk 6y ago
  The performance impact is not as much as you’d think, speaking from C/C++ land. I had a secured video player that was using these techniques, and even with the dial turned all the way up, it was costing 1-2% CPU and no human-detectable latency
danbmil99 6y ago
This sort of thing has been prevalent in the game world for decades. I once had the chance to work on a project disassembling casino machines, and they had similar protection appropriate for the technology of the time
grecy 6y ago
Will Apple approve an app with this level of Obfuscation in it's source? I thought they had to have the source itself?
- SXX 6y ago
  Apple don't need the source of your app, but some bytecode that they can optimize for target platform. As for making sure that certain app not using private frameworks they can just do it through the testing.
  - saagarjha 6y ago
    Bytecode is not required for applications targeting iOS. And I will note that the latter is fairly difficult to actually check in principle, and it's mainly enforced (actually, in certain cases it's not ;) ) in practice by the threat of consequences if they catch you doing it rather than testing.
    - SXX 6y ago
      So providing bitcode is still optional for release on App Store?
      - saagarjha 6y ago
        As long as you are not targeting watchOS or tvOS.
        SXX 6y ago
        Thank you for correcting me! I really expected that by now they using it for all devices.
- saagarjha 6y ago
  No, they don't. You can provide them with symbol files for your application so they can symbolicate crashes on your behalf, but this isn't required. (Interestingly, there are teams at Apple that reverse engineer applications for compatibility reasons, and the occasional "someone got an obfuscated binary past app review and we need to know what it does".)
pjmlp 6y ago
Very nice article. Great piece of work.
yamrzou 6y ago
How does one go about learning reverse engineering? Is it mostly by practicing? Are there any good up-to-date resources? I remember taking a reverse engineering course in the university where the professor didn't even bother to explain the basics, it was like black magic and left me frustrated, but I still feel amazed when I read blog posts like these.
- JohnTClark 6y ago
  I am interested in learning RE also. After some search on the internet I found that most people recommend Practical Malware Analysis book. I started reading it, it's seems pretty interesting. I didn't get to the RE part yet but from looking at it seems to be pretty good for beginner.
- 3eed 6y ago
  https://news.ycombinator.com/item?id=23563556 https://news.ycombinator.com/item?id=23563556
mmhsieh 6y ago
I have been advised by researchers in the field that it takes about a day with an optimizing compiler to de-obfuscate most any piece of commercial software of this size, with a good team. With a less than great team, perhaps about a week. Is that true?
- 3eed 6y ago
  Definitely not true.
  - deleted 6y ago
    [deleted]
obvboasio 6y ago
to answer everyone asking 'why do they do it????' its because of spam, that simple. they dont want: a) outbound bots that send messages to users created in bulk messaging millions of users. b) inbound chatbots that answer messages c) when they had snapcash, they didnt want bots generated collecting cash. spam is a multi million dollar industry. @3eed i guess it's not considered obfuscation but you gotta pass the correct version # or you won't be able to connect either, old versions are immediately obsolete.
- obvboasio 6y ago
  oh whoops forgot they also dont want scripts following users then logging all their private pics/posts without flagging it as beeing screenshotted which defeats the purpose of the app.
ffritz 6y ago
I was wondering if there are any steps a developer of a small app can take to add such a header and lock down the API so it only answers to said header. This level of obfuscation doesn’t seem doable for smaller shops. Is there something simpler, that is “good enough”?
- alasdair_ 6y ago
  JWT perhaps?
- 3eed 6y ago
  Security is a continuum, how much resource you can put into fending off prying eyes depends on how valuable your assets are and so how many prying eyes are targeting you. But as a start OLLVM is open source and not bad at all.
conradev 6y ago
I’m surprised that no one has mentioned how this is actually accomplished. The answer is: largely automatically, at the compiler level. Snapchat acquired Obfuscator-LLVM and the people behind it in 2017, which was actually partially open source for a period of time. It is a compiler backend for LLVM that obfuscates your code for you. You can read a bit about some of the techniques used on their old wiki: https://github.com/obfuscator-llvm/obfuscator/wiki/Features https://github.com/obfuscator-llvm/obfuscator/wiki/Features (outdated) https://www.bloomberg.com/news/articles/2017-07-21/snap-hires-swiss-team-behind-software-protection-startup https://www.bloomberg.com/news/articles/2017-07-21/snap-hire...
- underdeserver 6y ago
  Funny thing about things like that is that you can likely write tools to automatically deobfuscate, if you know the mechanisms. Of course, this takes time and effort, and is beyond most spammers' capabilities.
  - bluesign 6y ago
    Very unlikely you can actually. It is kinda similar to why we cannot have the source of binary even if we know how the compiler works.
    - q3k 6y ago
      We cannot have _the_ source, but we can have a good enough approximation of it, especially if a human is in the loop (see: commercial decompilation software like the Hex-Rays decompiler, Binary Ninja, and even Ghidra).
      - pfundstein 6y ago
        The point is that we cannot automate reversing these obfuscation mechanisms the same way we cannot automate reversing a binary file to a higher level than assembly.
bluesign 6y ago
Best value of this kind of obfuscation is they usually rely on a random seed, and every time you obfuscate you have different results. So once you update the app (and change hash function), for new version, spammer need to the all reversing once again.
- 3eed 6y ago
  Not all of it, really ;)
bob1029 6y ago
Seems like hooking the UI layer and intercepting data on the wire would be a much simpler approach. I wouldn't even try to circumvent the UI flow or animations. The more 'user-like' the activity, the more difficult it is to distinguish automation from human traffic. This doesn't scale as well well as many would like, but it can work. You could probably bundle something like this up and resell it as a grey-market API. There may be some money in standing up a datacenter that is filled almost exclusively with smartphones.
unnouinceput 6y ago
All these to make Snapchat not being recorded. Well, it's a mouse and cat game and currently the cat is winning, as in using Memu on my PC allows me to record everything happening there, your crush nudes and dances included.
jwyatt1995 6y ago
How would one go about understanding the content of this write-up? Even after the first paragraph it begins to go completely over my head.
- 3eed 6y ago
  You need some assembly background, then OWASP's guide[1], has all basics. [1]: https://github.com/OWASP/owasp-mstg https://github.com/OWASP/owasp-mstg
  - jwyatt1995 6y ago
    Thank you very much.
akaktsn 6y ago
I would love to be able to make a bot for the snapchat group my friends and I have. We already have a blast using it now. A bot that could randomly do things that we could all interact with would be hilarious. Sadly I don't think this functionality will be introduced. So it will be cool to maybe slap something together before all of this gets fixed.
shay_ker 6y ago
Are any of these obfuscation techniques possible on the web? My guess is no, but just curious.
llacb47 6y ago
Do tiktok next, their obfuscation techniques are quite interesting. :)
- 3eed 6y ago
  Why not ;)
trishume 6y ago
One thing I'm curious about is what they do to try to stop you from just ripping out the obfuscated token generation library and setting up a harness to run the whole thing in https://www.unicorn-engine.org/ https://www.unicorn-engine.org/ or something. Like presumably they don't compile their whole app with obfuscation and it's just some library that's linked in with some kind of stable-ish API contract with the rest of the app. I wouldn't be surprised if they do interesting things to try and stop you from ripping it out and it'd be cool to learn what those are.
- ponker 6y ago
  Why wouldn’t they obfuscate the whole app?
  - 3eed 6y ago
    That'd be a noticeable performance hit I'd say.
- benmmurphy 6y ago
  I think someone used this route but ran the real binary on real phones that had been injected with his code that allowed tokens to be generated.
- 3eed 6y ago
  You could manage to isolate these functions. The problem is that it's much of a hassle to run the whole thing on an emulator because there are way too many real environment dependencies, and even if you go the hackery way and patch all those, you won't know if you're generating one with the correct parameters because you're treating the whole thing as a black box.
mvkel 6y ago
This is what the top 1% of MIT grads work on. Obfuscating IP for a user data company. It’s clever, but man... I have to believe these talented folks were destined for something greater.
DLA 6y ago
CORRECT LINK: https://hot3eed.github.io/2020/06/18/snap_p1_obfuscations.html https://hot3eed.github.io/2020/06/18/snap_p1_obfuscations.ht...

497 points by 3eed 6y ago

iampims 6y ago

Things were definitely much simpler a couple years ago.

bri3d 6y ago
I'm actually a bit surprised it's taken as long as it has for mobile obfuscation to catch up. Both on the Android bytecode and the iOS native code side there are obvious PC analogs in the form of .NET obfuscators for MSIL and packers and game DRM for native code. Of course, the Obj-C runtime throws a little wrench into things on iOS, making it a bit of a hybrid - but the approaches are still similar. It's still an ultimately pointless cat and mouse game as long as an attacker can trace the hardware (and with full-platform emulation tools like Corellium, this capability is unlikely to go away soon), but still an amusing one to watch.
- dylz 6y ago
  I've seen this for _years_ already - it might also be because of a bit of an app usage difference, where the people that typically do these writeups or browse HN don't install the shitware on the app stores that do these things, except for rare common cases like large communications platforms (Snap) Many Asian mobile games run malware DRM like this - https://www.wellbia.com/home/en/pages/xigncode3-for-android/ https://www.wellbia.com/home/en/pages/xigncode3-for-android/ They are incredibly invasive and insecure, exfiltrate tons of PII (location, private IP, mac, ...) where possible unencrypted to bare IPs in various countries. This company in particular also has a PC-based anticheat rootkit that doesn't prevent cheating and allows the developer to "remote control the user", which is also an advertised feature.

programmarchy 6y ago

How many of these tricks are off the shelf techniques? Seems like a tremendous effort.

zelly 6y ago
There are numerous commercial compilers (for C and C++) that specialize in obfuscation. I suspect they are using one because to do that level of obfuscation manually would make the source code unreadable.
- qvrjuec 6y ago
  Yup, they actually acquired anti-reverse engineering startup Strong.codes after using their software for years
3eed 6y ago
OP here. About half are off the shelf. Joint functions, the breakpoint infinite loop, in-house memmove, the overflowing thing, those I haven’t read about anywhere before.
- cremp 6y ago
  For the overflow, Jagex with RuneScape did it in Java. They also did stupid Object arrays 7 or so levels deep, doing casts on casts in between. The bytecode itself made the actual runtime slow to a crawl (anywhere from 5 to 10x slowdown.) This was circa 2014.
  - 3eed 6y ago
    That’s interesting to know
- saagarjha 6y ago
  > the breakpoint infinite loop This is a fairly standard debugging technique. > in-house memmove You sure they didn't just statically link a libc?
  - sudhackar 6y ago
    > the breakpoint infinite loop Have seen multiple times in CTFs

MintelIE 6y ago

Doesn't Snapchat mainly rely upon the iOS or Android platform having some software that prevents screen shots if a 'no screen shots' flag is set? I always thought this was their core defense.

bri3d 6y ago
Their "core defense" for an end user is to notify the sender of a message if their post was screenshotted by using native screenshot detection/notification libraries provided by the OS, combined with heuristics to try to prevent them from beeing hooked and bypassed. However, the binary level protection is only tangentially anti-screenshot insofar as it also blocks third-party 'scraper' apps. Fundamentally, it's about requiring use of the Snapchat app to access the Snapchat APIs, and as we know from the ongoing saga with other social networks like Twitter, this is ultimately about business control over posts (preventing spam-bots, scheduled clients, and so on) and at the end of the day, ad revenue.
dannyw 6y ago
This is also trivially bypassed by the following technique: 1. Open the Snapchat app for a bit so it is downloaded / cached. 2. Turn on Airplane mode. 3. Screenshot and screen record to your desire. 4. Delete the whole app. 5. Turn off Airplane mode and download the app again.

zelly 6y ago

Snapchat is notoriously difficult to automate/spam. The goal is to get the X-Snapchat token. The most elegant solution is to find the secret in the binary and reverse the algorithm to generate tokens. Wouldn't it be easier to MITM the endpoint; set up a dummy server (which collects tokens) in front of a proxy that spoofs the DNS and TLS certs (may be easier on rooted Android than iOS). In my last attempt I gave up and went for dumb UI automation, but it would be cool (and worth good money) to exploit the private API.

mox1 6y ago
Certificate pinning spoils that, no spoofing of certs with pinning. Cert (or hash of) delivered with app. If server cert doesn't match expected value coded into app, someone is messing with something, terminate connection.
- amerine 6y ago
  Just don’t do something like only trust a specific CA cert. really-really pin to a leaf.
- zelly 6y ago
  Yes that complicates things. But if you can find the cert in the binary's data section, maybe you can patch it with your own.
  - __float 6y ago
    This probably runs into the same issue mentioned in the article, where the checksums are wrong and you end up in an infinite loop.
  - brendonjohn 6y ago
    Assuming this is for Android, the APK would no longer be signed and would cause all login attempts to fail. Have a read about "SafetyNet Attestion API" for Android.
    - 6y ago

akersten 6y ago

Wow, that seems really messy. If you're just after the API key or whatever, wouldn't reversing the Android app be simpler? As far as I know, you can't do all these low-level tricks on the Java platform.

somehnguy 6y ago
Java obfuscators exist too. I don't know how they compare in terms of complexity to reverse though.
zelly 6y ago
I think it's mostly native code on Android too except for the UI.
georgiecasey 6y ago
Android was way easier until Google started helping out and introduced SafetyNet attestation. I think it was orginally coded for Google Wallet/Pay but Snapchat were definitely using it from early on. Pokemon Go use it as well. Apple have no such system as far as I can know, and if they do, don't share it with 3rd party developers.
pjmlp 6y ago
Not only does Android use obfuscators as part of the build process, most applications make use of native code for their secure modules.

xuki 6y ago

Snapchat acquired Strong Codes in 2017. Before the acquisition they used Strong Codes compiler for obfuscation. https://www.bloomberg.com/news/articles/2017-07-21/snap-hires-swiss-team-behind-software-protection-startup https://www.bloomberg.com/news/articles/2017-07-21/snap-hire...

sbuccini 6y ago

I remember back in 2013(?) I went to a collegiate hackathon in Santa Monica. Evan Spiegel showed up to walk the floor and someone showed him how they had sniffed the API and did something interesting with it (forget the particulars now, getting old). If I recall correctly, Evan offered the kid a job on the spot but the kid turned him down. They've come a long way since then!

3eed 6y ago
Hey Spiegel! If you see this I’m available for hire.
plausibility 6y ago
Was this perhaps LA Hacks [0] in 2014, or Hacktech [1]? Evan Spiegel attended LA Hacks, but I had someone who was attending Hacktech email me for help with the Snapchat API for their project. (I was part of Gibson Security, and published some early Snapchat API research [2] online in 2013) [0] https://en.wikipedia.org/wiki/LA_Hacks https://en.wikipedia.org/wiki/LA_Hacks [1] https://medium.com/hacktech-2014/everyones-watching-hacktech-5b58c3859747 https://medium.com/hacktech-2014/everyones-watching-hacktech... [2] https://gibsonsec.org/snapchat/fulldisclosure/ https://gibsonsec.org/snapchat/fulldisclosure/
- sbuccini 6y ago
  Almost certainly HackTECH; it was held in a mall in Santa Monica right by the beach. I’m almost sure Evan came but it wasn’t to give a formal talk, but rather take a pretty low-key stroll-through. Maybe my mind is playing tricks on me. I did attend LA Hacks as well but I think it was in 2015, it was in Pauley Pavilion for the first time. Your research looks fascinating and sounds similar to what I remember of the hack. Might be the same person we’re talking about. Small world!
  - plausibility 6y ago
    I did some more searching, and I think it was Hacktech then. According to [0], Evan dropped by because of the project by Ash Bhat and Ankit Ranjan, apparently some of the organisers called him since he lived nearby. Seems you were right. [0] http://appstorechronicle.com/2014/01/exclusive-snapchat-hackers-friend-4-million-users-and-show-work-ceo-snapchat.html http://appstorechronicle.com/2014/01/exclusive-snapchat-hack...

rvz 6y ago

Well at this point, you might as well run the binary in a Mach-O ARM emulator since Snap has seriously cranked up the reversing difficulty to level 10,000. I suggest anyone looking at this would need to use Corellium such that Snap has made it hard for almost anyone to get their private API.

3eed 6y ago
Your only hope for emulating the whole thing would be Corellium, really. Too many real-device-dependencies.
- sprite 6y ago
  This was a few years back but I had token generation working with something much simpler than Corellium using https://github.com/unicorn-engine/unicorn https://github.com/unicorn-engine/unicorn emulator [You will need to set up CommPage, handle system and mach traps, load dyld, etc]. They've probably added more security since then but back when I looked at it some of the data that was encrypted in the token off the top of my head was: - Request Path - Timestamp - Snapchat Binary Size - Bit Flags for various hack checks such as jailbreak, checks for various tweaks, etc. - Device Type - iOS Version - A pair of counters, I believe these were being used to detect real devices being used as signature proxies. - A unique device ID generated at startup I can't remember which one of the tokens this was for. There is a X-Snapchat-Client-Token used at login if I remember correctly and X-Snapchat-Client-Auth-Token which is used for every request. I never ended up using it for anything but it was a lot of fun getting token generation working through emulation. I'm not sure if I was actually able to bypass all their checks or if it would have been detected had I actually tried to deploy it for something in production.

jayd16 6y ago

Philosophically I never gave much thought to securing app client code. Why not just track usage stats and ban clearly fake/high throughput users?

qvrjuec 6y ago
Because the users who were less clearly fake would still degrade the experience of the rest of the users. To use an analogy, consider currency counterfeiting. The government doesn't just look to see who is spending lots of cash without a job because it's a much harder problem than making the bills extremely difficult for the layman to forge. Same principle here - making the token extremely difficult to forge is the easier route. You don't catch 100% of the bad actors in either scenario, but why not use all of the tools available in your toolbox?
- jayd16 6y ago
  I'm not sure this analogy tracks very well. The government doesn't bother heightening the quality of one dollar bills, either. The government doesn't have information about every transaction, a web API does.
  - theincredulousk 6y ago
    These techniques are largely automated through metadata during a build process. It takes effort to setup, but not nearly as much effort as you think. The effect is asymmetrical- what takes you 1 hour to do costs a reverser 100. At least as time efficient as implementing backend detection algorithms.
dylz 6y ago
Because not so clearly fake users still make it through. The server side is also fairly quick on the trigger if you accidentally send anything that doesn't make sense, you're kicked off to "re-verification land"
RNCTX 6y ago
Because Snapchat is ultimately an application designed to trade in porn of amateurs including (and perhaps especially) teenagers. They have a vested interest in playing dumb to that fact. They can't really do so if the content escapes out into the wild and shows up in congressional hearings, lawsuits, FBI investigations, DOJ reports, etc.

just-ok 6y ago

This is an awesome write-up; I’m shocked at the level of effort that went into Snap’s obfuscation process. It implies that are entire teams of engineers out there whose sole job it is to play cat&mouse with reverse engineers and nothing more. Another comment mentioned that this effort is outsourced, so not only are there teams, but entire companies dedicated to this! What a blast that must be... though the immense amount of [invested|wasted] (take your pick depending on cynicism) effort spent on this game makes me a little sad. All of these brilliant minds just... cosplaying Sisyphus?

zebraflask 6y ago
I can't help but wonder if it's more of a "a little from Column A, a little from Column B" scenario. There's no doubt they have skilled security staff, but - as a company overall - they also grew very quickly. How much of that obfuscation is intentional and how much might just be old code from a few years ago that nobody got around to removing? Before it was passed through obfuscation.
- 3eed 6y ago
  The vast majority of these obfuscations (maybe except for the scratch arguments one) are done as LLVM passes, so it's done post-code writing, writing code like this would be unreadable and unmaintainable.
- xuki 6y ago
  I'd say they make it a priority to keep people from tampering with their code, and maybe maintaining the platform's integrity. They even ban people who use tweak on jailbroken iPhone/Android. I found these articles about avoid Snapchat detection a while ago, it's a cat and mouse game. https://aeonlucid.com/Snapchat-detection-on-Android/ https://aeonlucid.com/Snapchat-detection-on-Android/ https://aeonlucid.com/Snapchat-detection-on-iOS/ https://aeonlucid.com/Snapchat-detection-on-iOS/
deleted 6y ago
[deleted]
dylz 6y ago

ed25519FUUU 6y ago

> To make your life even more miserable, Snap ocassionally deprives you of recognizing some basic standard lib functions ... You won’t be very happy after spending a day or two reversing a function to find it’s memmove in the end. That sounds particularly devious.

deleted 6y ago

[deleted]

mises 6y ago

This is some pretty heavy-duty obfuscation. What is the business case for this amount of work towards preventing reverse-engineering? Decent rate limiting should be much more effective than making such a herculean effort to obfuscate one's API. Edit: another comment mentions that snap chat uses an existing solution, which makes more sense than the expense of developing this sort of obfuscation in-house: https://news.ycombinator.com/item?id=23558784 https://news.ycombinator.com/item?id=23558784

dannyw 6y ago
Specifically, Snapchat wants to stop "tweaks" and alternate frontends that allow for bypassing of Snapchat's self destruction controls. This is especially important given that Snapchat is widely used to trade amateur underaged pornography.

surround 6y ago

There are already alternative front-ends for YouTube, Facebook, and Reddit. I’d love to see one for Snapchat and Instagram, although it looks like one for Snapchat would be incredibly difficult.

SXX 6y ago
Most usable alternative front-ends for such services are usually just parse web API or even plain html in case of YouTube. Snapchat don't have any web app so parsing it is tricky and Instagram provide only limited set of features on the web.

Commodore_64 6y ago

Great write up! Thanks for posting!

htgb 6y ago

Interesting read! I'd love to read the next post, but at least Miniflux can't find any feed. 3eed, would you be open to adding an RSS feed?

kchr 6y ago
Yes please!
3eed 6y ago
Sure! I'll consider doing this before the next post
- htgb 6y ago
  Thanks!

xwdv 6y ago

If you dig very deep, you can also find an offer to come work at Snapchat. Most will never find it.

Nextgrid 6y ago
Those who do have the skill to find it probably have better places to work for than a barely profitable company whose only revenue stream is to push trashy clickbait.
- xwdv 6y ago
  Barely profitable companies regularly pay big salaries for the right people, it’s why they’re barely profitable.
3eed 6y ago
Hmm, I wonder how deep one should look. Why don't you shoot me an email at hot3eed at gmail? I'd appreciate it a lot!

jor-el 6y ago

Some I see are surprised to see the level of obfuscation used in the application. Many pointed, many ingredients for the obfuscation used in the app are off-the-shelf and few of them can be said to be well known in the industry, but still there is a cost in integrating them into a product. Obfuscation is notorious in breaking things which should work normally (normal compilation process) and as a own goal making it hard to debug as well. Integrating, testing, debugging and difficulty in debugging production crash logs is a considerable cost. That said, obfuscation is increasingly being used in mobile applications now. Check your banking application or some government applications, you will find obfuscation being used. With mobile applications getting richer and lot of code executing on the client side, makes it compelling case to secure applications by using obfuscation (as a defense-in-depth approach). Open standards like OWASP MSTG [1] MSTG-RESILIENCE-9 recommend such approach. Obfuscation is applied to programmatic defenses, which in turn impede de-obfuscation via dynamic analysis. [1] https://github.com/OWASP/owasp-masvs/blob/master/Document/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md https://github.com/OWASP/owasp-masvs/blob/master/Document/0x...

pjmlp 6y ago
I think that it is due to the copy cats that keep stealing apps and repacking them. Most Android developers lack native coding experience, so after failing attempts to protect their applications with the DEX bytecodes obfuscator, they think that recoding parts of the application with the NDK will save them. However as this article shows, and most here know, they shortly learn that against good attackers, the only benefit from using native code directly is it takes a little longer to decipher what the application does. So then one turns to solutions like what you are describing.
- grishka 6y ago
  > they think that recoding parts of the application with the NDK will save them. Yeah like that one app I reversed a while ago that generated the API key in a native library. I was able to get the key by building my own app around their library and calling the function that returns the key. Didn't even have to disassemble the thing.

brendonjohn 6y ago

This is brilliant work, I'm hoping in part II we get to see it working against the API. I reverse engineered this in a production environment. It took approximately 7 months to build a scalable solution. The investigation on how to create the x-snapchat-client-auth token is brilliant. One day I hope to do a talk on what my old team did to circumvent it. There's a painful gotcha on the homestretch for this token: You may be creating the token, but it's not obvious what you're supposed to be using the method to sign. What do they use it for? As far as I could tell, it's so they can verify requests at the edge nodes of their network. When you provide a bad x-snapchat-client-auth, you get a near-instant 403.

krankthat 6y ago
I'd be fascinated to read about your old team's work!
bluesign 6y ago
I think edge node is just checking if x-snapchat-client-auth valid, without checking if x-snapchat-client-auth is valid for this request. The second check is probably done at deeper level.

hn_throwaway_99 6y ago

I'm curious, can anyone recommend any techniques (or companies providing solutions) for attempting something similar with javascript in a browser calling an API? Obviously it's much more difficult to obfuscate an algorithm for generating a client token in JS than it would be in assembly, but I'm just curious if anyone has tried any form of "lock down my API so it's only callable from the web front end I provide" obfuscation.

nerdbaggy 6y ago
WASM would be a good option I believe
londons_explore 6y ago
Recaptcha tries to do this. Their approach is to make a blob of code which collects all kinds of details about its environment (for example, Object.keys(window) ). It then uses a hash/concat of those details (with some random too) to decode data to decide what else to collect, hashes or concatenates those in too. Repeat a few times. Then send the final data blob back to the server. The server can then run a tiny emulator to run the code with the same seed random to check the results are the same on a whitelist of allowed environments.
zelly 6y ago
>"lock down my API so it's only callable from the web front end I provide" Generate secret tokens that the server can validate using some heavily obfuscated process. Compile the JS to WASM. If you can use HTTP3 or WebSockets that's a bonus, because you can create a custom protocol that does some secret handshake before sending the goods.
the_duke 6y ago
You can study the Instagram or TikTok web versions for inspiration. Both use some wacky methods for request signing that include encrypted code, obfuscated control flow, hashing the browser environment, ... Assembly obviously allows for much more powerful obfuscation than Javascript. Webassembly is somewhere inbetween, but a viable path since it is pretty universally supported by now. Networks requests can be inspected trivially in the browser though, which makes things a lot easier.

saagarjha 6y ago

> In Mach-O binaries, functions whose pointers are in the __mod_init_funcs run before main. Remember that obfuscation makes your code run slower. This specific one is part of the reason why the dyld team probably hates you.

theincredulousk 6y ago
The performance impact is not as much as you’d think, speaking from C/C++ land. I had a secured video player that was using these techniques, and even with the dial turned all the way up, it was costing 1-2% CPU and no human-detectable latency

danbmil99 6y ago

This sort of thing has been prevalent in the game world for decades. I once had the chance to work on a project disassembling casino machines, and they had similar protection appropriate for the technology of the time

grecy 6y ago

Will Apple approve an app with this level of Obfuscation in it's source? I thought they had to have the source itself?

SXX 6y ago
Apple don't need the source of your app, but some bytecode that they can optimize for target platform. As for making sure that certain app not using private frameworks they can just do it through the testing.
- saagarjha 6y ago
  Bytecode is not required for applications targeting iOS. And I will note that the latter is fairly difficult to actually check in principle, and it's mainly enforced (actually, in certain cases it's not ;) ) in practice by the threat of consequences if they catch you doing it rather than testing.
  - SXX 6y ago
    So providing bitcode is still optional for release on App Store?
    - saagarjha 6y ago
      As long as you are not targeting watchOS or tvOS.
      - SXX 6y ago
        Thank you for correcting me! I really expected that by now they using it for all devices.
saagarjha 6y ago
No, they don't. You can provide them with symbol files for your application so they can symbolicate crashes on your behalf, but this isn't required. (Interestingly, there are teams at Apple that reverse engineer applications for compatibility reasons, and the occasional "someone got an obfuscated binary past app review and we need to know what it does".)

pjmlp 6y ago

Very nice article. Great piece of work.

yamrzou 6y ago

How does one go about learning reverse engineering? Is it mostly by practicing? Are there any good up-to-date resources? I remember taking a reverse engineering course in the university where the professor didn't even bother to explain the basics, it was like black magic and left me frustrated, but I still feel amazed when I read blog posts like these.

JohnTClark 6y ago
I am interested in learning RE also. After some search on the internet I found that most people recommend Practical Malware Analysis book. I started reading it, it's seems pretty interesting. I didn't get to the RE part yet but from looking at it seems to be pretty good for beginner.
3eed 6y ago
https://news.ycombinator.com/item?id=23563556 https://news.ycombinator.com/item?id=23563556

mmhsieh 6y ago

I have been advised by researchers in the field that it takes about a day with an optimizing compiler to de-obfuscate most any piece of commercial software of this size, with a good team. With a less than great team, perhaps about a week. Is that true?

3eed 6y ago
Definitely not true.
- deleted 6y ago
  [deleted]

obvboasio 6y ago

to answer everyone asking 'why do they do it????' its because of spam, that simple. they dont want: a) outbound bots that send messages to users created in bulk messaging millions of users. b) inbound chatbots that answer messages c) when they had snapcash, they didnt want bots generated collecting cash. spam is a multi million dollar industry. @3eed i guess it's not considered obfuscation but you gotta pass the correct version # or you won't be able to connect either, old versions are immediately obsolete.

obvboasio 6y ago
oh whoops forgot they also dont want scripts following users then logging all their private pics/posts without flagging it as beeing screenshotted which defeats the purpose of the app.

ffritz 6y ago

I was wondering if there are any steps a developer of a small app can take to add such a header and lock down the API so it only answers to said header. This level of obfuscation doesn’t seem doable for smaller shops. Is there something simpler, that is “good enough”?

alasdair_ 6y ago
JWT perhaps?
3eed 6y ago
Security is a continuum, how much resource you can put into fending off prying eyes depends on how valuable your assets are and so how many prying eyes are targeting you. But as a start OLLVM is open source and not bad at all.

conradev 6y ago

I’m surprised that no one has mentioned how this is actually accomplished. The answer is: largely automatically, at the compiler level. Snapchat acquired Obfuscator-LLVM and the people behind it in 2017, which was actually partially open source for a period of time. It is a compiler backend for LLVM that obfuscates your code for you. You can read a bit about some of the techniques used on their old wiki: https://github.com/obfuscator-llvm/obfuscator/wiki/Features https://github.com/obfuscator-llvm/obfuscator/wiki/Features (outdated) https://www.bloomberg.com/news/articles/2017-07-21/snap-hires-swiss-team-behind-software-protection-startup https://www.bloomberg.com/news/articles/2017-07-21/snap-hire...

underdeserver 6y ago
Funny thing about things like that is that you can likely write tools to automatically deobfuscate, if you know the mechanisms. Of course, this takes time and effort, and is beyond most spammers' capabilities.
- bluesign 6y ago
  Very unlikely you can actually. It is kinda similar to why we cannot have the source of binary even if we know how the compiler works.
  - q3k 6y ago
    We cannot have _the_ source, but we can have a good enough approximation of it, especially if a human is in the loop (see: commercial decompilation software like the Hex-Rays decompiler, Binary Ninja, and even Ghidra).
    - pfundstein 6y ago
      The point is that we cannot automate reversing these obfuscation mechanisms the same way we cannot automate reversing a binary file to a higher level than assembly.

bluesign 6y ago

Best value of this kind of obfuscation is they usually rely on a random seed, and every time you obfuscate you have different results. So once you update the app (and change hash function), for new version, spammer need to the all reversing once again.

3eed 6y ago
Not all of it, really ;)

bob1029 6y ago

Seems like hooking the UI layer and intercepting data on the wire would be a much simpler approach. I wouldn't even try to circumvent the UI flow or animations. The more 'user-like' the activity, the more difficult it is to distinguish automation from human traffic. This doesn't scale as well well as many would like, but it can work. You could probably bundle something like this up and resell it as a grey-market API. There may be some money in standing up a datacenter that is filled almost exclusively with smartphones.

unnouinceput 6y ago

All these to make Snapchat not being recorded. Well, it's a mouse and cat game and currently the cat is winning, as in using Memu on my PC allows me to record everything happening there, your crush nudes and dances included.

jwyatt1995 6y ago

How would one go about understanding the content of this write-up? Even after the first paragraph it begins to go completely over my head.

3eed 6y ago
You need some assembly background, then OWASP's guide[1], has all basics. [1]: https://github.com/OWASP/owasp-mstg https://github.com/OWASP/owasp-mstg
- jwyatt1995 6y ago
  Thank you very much.

akaktsn 6y ago

I would love to be able to make a bot for the snapchat group my friends and I have. We already have a blast using it now. A bot that could randomly do things that we could all interact with would be hilarious. Sadly I don't think this functionality will be introduced. So it will be cool to maybe slap something together before all of this gets fixed.

shay_ker 6y ago

Are any of these obfuscation techniques possible on the web? My guess is no, but just curious.

llacb47 6y ago

Do tiktok next, their obfuscation techniques are quite interesting. :)

3eed 6y ago
Why not ;)

trishume 6y ago

One thing I'm curious about is what they do to try to stop you from just ripping out the obfuscated token generation library and setting up a harness to run the whole thing in https://www.unicorn-engine.org/ https://www.unicorn-engine.org/ or something. Like presumably they don't compile their whole app with obfuscation and it's just some library that's linked in with some kind of stable-ish API contract with the rest of the app. I wouldn't be surprised if they do interesting things to try and stop you from ripping it out and it'd be cool to learn what those are.

ponker 6y ago
Why wouldn’t they obfuscate the whole app?
- 3eed 6y ago
  That'd be a noticeable performance hit I'd say.
benmmurphy 6y ago
I think someone used this route but ran the real binary on real phones that had been injected with his code that allowed tokens to be generated.
3eed 6y ago
You could manage to isolate these functions. The problem is that it's much of a hassle to run the whole thing on an emulator because there are way too many real environment dependencies, and even if you go the hackery way and patch all those, you won't know if you're generating one with the correct parameters because you're treating the whole thing as a black box.

mvkel 6y ago

This is what the top 1% of MIT grads work on. Obfuscating IP for a user data company. It’s clever, but man... I have to believe these talented folks were destined for something greater.

DLA 6y ago

CORRECT LINK: https://hot3eed.github.io/2020/06/18/snap_p1_obfuscations.html https://hot3eed.github.io/2020/06/18/snap_p1_obfuscations.ht...