I have been particularly trying to find the most effective measures to protect an apk from Reverse engineering and abusive use. While continuing my research I came across various top rated apps and one of them which garnered most of my attention(as well as others perhaps) was Snapchat.

Now, Snapchat had tried to rebuild its security measures and tighten its knots to prevent abusive use of its app following 2017 fall releases. Long story short, Snapchat started using a special header called X-Snapchat-Client Auth Token to sign all requests originating from the App. The beauty being a simple decompile and recompile leaves the app useless and it perhaps boils down to the special header which helps detect Snapchat servers that the request is illegitimate and originated from untrusted sources and hence should not be entertained.

This special header is actually prepared by a special native library called libscplugin.so which is called by the app during initial login and helps generating the header and signing the requests. On doing a bit digging I discovered this library(which is actually a shared object(.so) and cannot be decompiled easily unlike other .dex files) makes following java method calls :

  • com.snapchat.android.app.shared.crypto.DeviceTokenManager.getInstance
  • com.snapchat.android.app.shared.crypto.DeviceTokenManager.getDeviceToken1

which is understood as it might be doing some stuffs with Device token.

And, There are following calls as well :

  • java.lang.ClassLoader.loadClass
  • dalvik.system.BaseDexClassLoader.findClass
  • dalvik.system.DexPathList$Element.toString
  • and a lot number of other Dalvik and String method calls

I want to understand what this particular method of protection is and how it helps Snapchat identify an unauthorized app. What do the above method calls symbolize or convey a message? Is it trying to attain the App signature from the native layer or trying to compute the state of the dex files or anything which I'm not aware of and is very interesting and helpful and using it further to generate the attestation token?

Whatever these calls do, it's pretty obvious it is very successful and has stood the test of time.

Any further thoughts and insights are most welcome and appreciated.

  • I doubt that the app becoming useless after recompiling has to do with that header, lots of things can go wrong there. Also see this post for how that header is used: sociallei.wordpress.com/2015/05/10/…
    – J.A.K.
    Feb 4, 2019 at 1:01
  • I agree. Though, the subsequent method calls shows Snapchat servers not responding to the login request. In addition to this, I couldn't find any other trace where integrity of app is checked though there are tons of such typical tests present in the app as methods which are never called or atleast were never called between the startup and failing of app. What else could go wrong? Feb 4, 2019 at 8:54
  • Depending on what you use for de/recompiling, dex2jar or other software might have screwed up something critical that contributes to the sent data. Snapchat might be aware of this as a common defect, or maybe even have purposefully introduced it. Not too sure about all this, hoping someone with arm RE skills pitches in
    – J.A.K.
    Feb 4, 2019 at 19:31
  • The recompiled app doesn't crashes. Even a minor corruption either prevents installation or causes a crash. I haven't witnessed either of them so I disagree with you here. It's clearly evident from the trace that Snap servers did not recognize the request as legitimate and hence responded with an error code 403. Feb 5, 2019 at 2:28
  • 1
    Code signing is a good technique to detect such changes in applications.
    – Khopcha
    Feb 10, 2019 at 21:54

1 Answer 1


So you can still reverse engineer the .so binary to attempt to learn more about the algorithm and see if you can forge validation tokens. See the below softwares:



Both are very strong pieces of decompilation software, able to convert machine code (ASM) into human readable C++ for reverse engineering. It increases the difficulty of RE, but it's not impossible.

As for how they did that? Code signing can be used to verify the integrity of the code before execution. But all a .so is is a Linux shared object that was compiled from C/C++ code. So if you want to make it difficult for attackers to learn more about your model, you can if you so choose, write the algorithm in C++ and then link it as a shared object to the app, and then import/use its functions in your android project. That will provide a layer of abstraction between the app and the validation algorithm.

  • Ghidra looks interesting as it's free. I have heard of IDA Pro before. Can you help me with this entire decompilation? May 31, 2019 at 19:09
  • There is an IDA freeware too. I don't think I can help you but I'd recommend going on YouTube and looking up, "Reversing with Ghidra" and do some crackmes if you're new to RE. Start with something small so you can see yourself improve and find your weaknesses. Jun 1, 2019 at 20:20
  • After spending lots of hours searching for good resources about binary analysis, reverse enginnering and anti-debugging I stumbled upon this cool youtube-channel where a person takes 1-2 hours per video in explaining how exploitation and anti-reverse-enginnering tricks work. I advise to take a look there: youtube.com/user/GynvaelEN but he is using mostly IDA. Also there other binary analysis tools like: radare, binary ninja and as said above ghydra (NSA reversing tool). Aug 4, 2019 at 20:23
  • additionally there is a funny trick how one can make life harder for reverse engineers by modifying (slightly) the binary: youtube.com/watch?v=OZvc-c1OLnM (Uncrackable Program? Finding a Parser Differential in loading ELF - Part 2/2 - bin 0x08) so it cannot be simply opened with gdb (debugger) or radare (reverse engineering tool) Aug 4, 2019 at 20:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .