
Reverse Engineering Snapchat: Obfuscation Techniques - 3eed
https://hot3eed.github.io/snap_part1_obfuscations.html
======
conradev
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-
hire...](https://www.bloomberg.com/news/articles/2017-07-21/snap-hires-swiss-
team-behind-software-protection-startup)

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

~~~
3eed
I'm gonna write about this in pt. 2. Basically you can use symbolic execution
to recover the CFG[1] (using something like miasm), you can eliminate dead
code, restore dynamic lib calls with an emulation, and whatever else. But the
point is that it would take an incredible amount of work and co-operation
between tools, and then you wouldn't have even begun understanding anything
about the binary, which is a whole another story. Now there's a kind of a
little shortcut to all of this, which when combined with a couple of tools,
you'd be able to make sense of things in this binary, which I'm gonna reveal
in my next post.

[1]: [https://blog.quarkslab.com/deobfuscation-recovering-an-
ollvm...](https://blog.quarkslab.com/deobfuscation-recovering-an-ollvm-
protected-program.html)

~~~
novaleaf
awesome write up, really engaging! I enjoy the cliff hanger at the last
line... "one strange trick"....

~~~
3eed
"Evan Spiegel Hates this Trick!"

------
just-ok
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?

~~~
elevenoh
>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?

And we wonder why such a high % of tech workers have a deep discontent & are
desperately searching for meaning.

~~~
meowface
I would find that a very fulfilling and meaningful project, personally. I'd
actually consider it way more fulfilling than working on the core product,
which likely mostly involves trying to think of and implement clever ways to
expose users to ads and sponsored content, and otherwise try to directly and
indirectly monetize users.

Here, the goal is to prevent phishers, fraudsters, scammers, spammers,
catfish, impersonators, malware spreaders, etc. from running amok in a
somewhat unprecedented way by tricking users en masse into thinking they're
really receiving photos/videos in real-time, using automated tooling. My
understanding is this heavy degree of obfuscation (combined with other anti-
tampering tactics) has gone a very long way to mitigate a huge amount of
abuse.

From talking to people who've tried to bypass these mechanisms to do
unauthorized and potentially risky things (like send things from a custom
client in a way that could allow for mass automation), they describe this as
an essentially intractable hurdle from their perspective. Of course, it isn't
in actuality, but it is for most people when compared to lots of other social
media apps, and I expect Snap to change things around not long after OP
releases part 2. Cat-and-mouse never ends.

~~~
deanCommie
> Here, the goal is to prevent phishers, fraudsters, scammers, spammers,
> catfish, impersonators, malware spreaders, etc. from running amok in a
> somewhat unprecedented way by tricking users en masse into thinking they're
> really receiving photos/videos in real-time, using automated tooling. My
> understanding is this heavy degree of obfuscation (combined with other anti-
> tampering tactics) has gone a very long way to mitigate a huge amount of
> abuse.

Which is STILL in the service of trying to expose users to ads and sponsored
content.

I find it sad that people in our industry are so easily distracted by the
technical challenge du jour without looking at the bigger picture of what
their work is in service of, which was OP's point.

~~~
ponker
Are you saying you shouldn’t help an app that exposes users to ads prevent
people from running automated fishing-for-nudes campaigns that have been used
in the past to bully teenagers into suicide?

~~~
tekknik
No, not this way. If my goal is really to push content to users I’d get a set
of account and automate the sending/scraping using a device emulator.
Ultimately their efforts are better spent elsewhere if this is the actual
goal. In reality the goal is to attempt to keep people from reverse
engineering the api so they can create a custom, ad free, client.

------
jor-el
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/0x...](https://github.com/OWASP/owasp-
masvs/blob/master/Document/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md)

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

------
xuki
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-
hire...](https://www.bloomberg.com/news/articles/2017-07-21/snap-hires-swiss-
team-behind-software-protection-startup)

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

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

------
sbuccini
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!

~~~
plausibility
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...](https://medium.com/hacktech-2014/everyones-watching-
hacktech-5b58c3859747)

[2]
[https://gibsonsec.org/snapchat/fulldisclosure/](https://gibsonsec.org/snapchat/fulldisclosure/)

~~~
sbuccini
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
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-
hack...](http://appstorechronicle.com/2014/01/exclusive-snapchat-hackers-
friend-4-million-users-and-show-work-ceo-snapchat.html)

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

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

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

~~~
IAmLiterallyAB
You could patch Android and run it in an emulator. Or patch Snap not to care.
Not super familiar, but there should be a way. Client side security can only
do so much.

~~~
looperhacks
You can't patch Snap to not care because the safetynet process is (roughly)
like that: The App asks the Play libraries whether the phone is okay. This is
verified (in part) on the Google servers, so the Snap servers can ask Google
whether a call came from a non-tampered phone. The client can't do anything
about it, except tricking google into believing the phone is not tampered
with. Which is notoriously hard, because nobody knows how the process really
works.

~~~
ss3000
In my experience, SafeteyNet bypass on rooted devices has been a solved
problem for a long time through Magisk Hide.

------
rvz
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
Your only hope for emulating the whole thing would be Corellium, really. Too
many real-device-dependencies.

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

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

~~~
Nextgrid
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
Barely profitable companies regularly pay big salaries for the right people,
it’s why they’re barely profitable.

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

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

~~~
historyremade
Other methods out there to hide network requests in-browser.

~~~
the_duke
Sure, you could do all kinds of things. Using GET requests with a encrypted
payload in the URL, websockets with some wacky custom protocol on top, WebRTC
shenanigans, ...

I haven't seen anything like that in the wild, though.

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

------
jayd16
Philosophically I never gave much thought to securing app client code.

Why not just track usage stats and ban clearly fake/high throughput users?

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

~~~
snazz
I think you wildly misunderstand how many people (teenagers included) who use
Snapchat for PG-rated things exclusively. The end-to-end encryption (of snaps)
and “disappearing” nature makes it work well for anything sensitive, but porn
is certainly not the only thing people use it for.

Also, any party to a conversation can use the report button to send the
unencrypted message to Snap for review. They employ actual content moderators
as well, who have made reports to federal law enforcement before.

~~~
RNCTX
Sounds like a bit of lipstick on a billion dollar pig. I'm sure we all
remember their early days, their marketing material was straight out of any
drunken frat boy's phone.

I mean, pornstars say 90% of pornstars are selling content on Snapchat.

[https://www.wired.co.uk/article/premium-snapchat-adult-
model...](https://www.wired.co.uk/article/premium-snapchat-adult-models)

~~~
snazz
I think that's true for the beginning, and I'm not disputing your statistic,
but as a percentage of the total userbase today, people using it for non-porn-
related purposes are the vast majority. Even if nearly 90% of porn stars use
it, nowhere near 90% of Snapchat's users produce or consume adult content on
the platform.

Do you use Snapchat? Do you have friends who do? It's the de facto
communication standard for teenagers because of Quick Add and the gamified
nature, not porn.

~~~
RNCTX
No, I have no purpose for it, but I'm in my 40s. Twitter and Facebook are the
only social media platforms I use.

To say snapchat has no basis in trading porn is to say that pornhub could
relaunch itself tomorrow and say "oh sorry we're just a youtube knockoff now,
we're not in the adult industry."

Well, it would still say pornhub in the URL, wouldn't it. And it would still
be a site whose entire userbase was built on trading porn. That's what
Snapchat built and used to grow its userbase, so trying to re-image themselves
after getting the money is dubious at best.

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

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

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

~~~
3eed
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
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
That’s interesting to know

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

~~~
3eed
Why not ;)

------
bluesign
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
Not all of it, really ;)

------
trishume
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
Why wouldn’t they obfuscate the whole app?

~~~
3eed
That'd be a noticeable performance hit I'd say.

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

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

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

------
jwyatt1995
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
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
Thank you very much.

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

------
htgb
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?

~~~
3eed
Sure! I'll consider doing this before the next post

~~~
htgb
Thanks!

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

~~~
3eed
[https://news.ycombinator.com/item?id=23563556](https://news.ycombinator.com/item?id=23563556)

------
ffritz
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”?

~~~
3eed
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.

------
mmhsieh
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
Definitely not true.

------
DLA
CORRECT LINK:
[https://hot3eed.github.io/2020/06/18/snap_p1_obfuscations.ht...](https://hot3eed.github.io/2020/06/18/snap_p1_obfuscations.html)

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

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

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

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

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

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

------
iampims
Things were definitely much simpler a couple years ago.

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

------
pjmlp
Very nice article. Great piece of work.

------
Commodore_64
Great write up! Thanks for posting!

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

~~~
saagarjha
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".)

~~~
grecy
Huh, thanks. I thought they reviewed the source of all apps to make sure they
aren't doing anything naughty.

~~~
underdeserver
That would be ridiculously expensive.

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

