Snapchat detection on iOS
Previously we took a look at Snapchat’s root detection methods on Android. This time we are taking a look at how they detect jailbreaks, tweaks and hooks on iOS.
All the research in this post is based on Snapchat 10.65.0.66 (832559634).
This is the message you see when you try to login with a detected tweak, although not all tweaks trigger this message. Two examples that trigger this message are Flex 3 and Wraith. Some just flag your account and will get you banned later in a ban wave if you are unlucky.
So obviously the first thing we want to look at is, what has the community tried so far to stay hidden? If you google around a bit you will most likely end up with these result. For a few of them, I will list the most notable features.
- NoSub (or variants)
- Disable Cydia Substrate / Substitute entirely for specific apps.
- Only if you can find an updated version and don’t want to use tweaks on Snapchat.
- Hooks and filters libc file system calls.
- Spoofs the libc getenv to remove the
_dyld_get_image_nameto hide tweak related dylibs.
- Too much to list.. it hooks way too much.
- Still misses lots of stuff for Snapchat specifically.
But it seems that nobody knows what Snapchat is exactly doing to detect everything. Which is why I am writing this post. Only one that I have seen publicly making efforts to figure this out is the developer of Phantom, CokePokes.
How are they doing it?
I will try my best to explain every check they do in Snapchat 10.65.0.66.
When you launch the app they create a new thread using pthread_create that runs all the checks. At the end of these checks an integer is stored with flags of everything that was detected on the device. Some of these checks are then ran every 31 seconds.
All the code executed for these checks is obfuscated with Snapchats in-house obfuscation tools and thus very annoying to look at using tools such as IDA.
Code signature checks
One of the first things they do is checking and storing stuff from the code signature. This happens using the
sys_csops(169) syscall, which is pretty much undocumented but is very similar to the code here.
They execute the following operations:
The most important one of this is the
CS_OPS_STATUS, this retrieves the current codesigning status of the process. A jailbroken device can respond with messy status flags. Such as:
CS_DEBUGGED(Process was debugged / is being debugged)
- Or missing
A normal device would have these flags:
For all available flags and their descriptions, see this page.
The result of
CS_OPS_CDHASH are stored and later sent to the Snapchat servers, encrypted.
This is a simple check but quite effective if not noticed by a tweak developer. Pseudo code looks like this.
x0 = CFBundleGetMainBundle() x1 = CFBundleGetIdentifier(x0) x2 = CFStringGetCStringPtr(x1) strncmp("com.toyopagroup.picaboo", x2)
Snapchat has two methods to iterate all loaded dylibs.
One way is using dyld_get_image_header and dladdr. They iterate over
dyld_get_image_header until it returns null and checks if it has seen everything with dyld_image_count. The
dladdr method provides them with the path of the dylib. These are checked against a few unknown strings but removing everything substrate related from the dyld list fixes this check.
The other method they use is calling task_info with flavor
TASK_DYLD_INFO. This also gives them a list of all loaded dylibs and must be fixed separately from the first dyld check.
File system checks
There are a couple of file system checks, of which all use the
- /Library/Application Support/PhLite/phlite.bundle/AuthAPI.pem
Last one (and expected to exist)
The last one makes it a bit harder to fix, since you can not simply replace the arm instructions with something that makes it always return false. Thus requiring an inline hook as replacement for the syscall so you gain full control over it.
Obj-C - Class checks
A lot of classes are checked from a lot of different tweaks. This is done using objc_getClass.
Obj-C - Method checks
Obj-C - Method integrity checks
Next up is Snapchats own methods. For the classes listed below they first call class_copyMethodList. Then for every Method they check if the
IMP pointer (address of the function) is within its own
__text segment. This is how they detect whether a method has been hooked.
dzan for telling me to check the
__text segment. :-)
They also check for a couple of symbols using dlsym. If the result is not null, you get flagged.
Symbol hook checks
A few symbols are resolved using dlsym to check whether they have been hooked. They first resolve
dlsym.. yeah.. That result gets used for the
dlsym of the symbols below. For every address returned, the first 4 bytes are checked for common hook related instructions.
I need to be honest, this is a very annoying way how they check for injection because it is annoying to fix. Instead of using getenv they use the environ variable. Since it is a variable, you can not “hook” it.
At least the following variables are detected.
Probably not an issue for anyone.
Not much detection done here but still relevant, using
sys_sysctl(202) they request at least the following properties.
sys_proc_info(33) is also called a couple of times, which could reveal stuff that is ptracing the process. They also use
sys_lstat64(340) on the
Snapchat binary. Probably to check for modifications or generating a checksum.
How all this stuff was found
A lot of the work was done using a small iOS emulator build on top of Unicorn. Using an emulator you can see everything they do. Building this was also teached me a lot about the CoreFoundation library of iOS.
Later I implemented a counter for all of my discoveries in a tweak called SnapHide while carefully keeping track of how my changes modified the detection flags and slowly getting rid of all of them. You can easily find fixes for checks mentioned in this blog post in the “Detections” directory.
A story on how I wasted hours on fixing syscalls
sys_access(33) as an example. It’s implementation looks like this. In short, when a file exists and permission is granted, return
0. Otherwise return
-1. First thing I did was force both of the results in my emulator but I saw no changes happening to the detection flags.
Later when implementing a fix for this in the SnapHide tweak, I was unable to have it fail. The arm instructions look like this:
MOV X0, X27 ; path MOV X1, #0 ; mode MOV X16, #0x21 SVC 0x80 ; SYS_access MOV X0, #0xFFFFFFFFFFFFFFFF CSEL X0, X0, XZR, CS MOV X27, X0 ; Use result
In pseudo code:
v23 = mac_syscall(SYS_access, a20, 0); v24 = -1; if ( !v20 ) v24 = 0; *(v21 + 496) = v24;
Coming from android I was very confused what happened here. Looking at the instructions, they seem to directly clear the result from the syscall. Looking at the pseudo code reveals a bit more information. Apparently what happens is, “A syscall return errno an sets the carry flag on error” from here. Setting and clearing the carry flag resulted in detection changes. This took me a few hours to figure out for some reason. Later I found out that I could simply remove the MOV & CSEL instruction. Which gave me 8 bytes more space for patching.
Thanks to @iGio90 for telling me to check all registers for changes in lldb.
I use Unsub and haven’t been banned (yet)
Awesome! That’s a good thing. However, keep in mind that some of the checks above are not countered by UnSub at this moment. Everything that has
syscall mentioned for example is not countered and you will not be able to sign in if you have
Flex 3 installed. UnSub does not prevent Cydia Substrate from loading, it attempts to hide it. Which also fails because Snapchat does not even use this call.
Written with the assumption this is the UnSub everybody uses.
This was a very fun but also very annoying 2 weeks with a lot of headaches. I hope this brings some light into why some stuff gets people banned. If there are any issue’s with with tweak feel free to submit an issue on GitHub. If there’s something you’d like me to expand on, let me know!