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.

Avoiding bans

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.
• UnSub
  • Hooks and filters libc file system calls.
  • Spoofs the libc getenv to remove the DYLD_INSERT_LIBRARIES variable.
  • Spoofs _dyld_image_count and _dyld_get_image_name to hide tweak related dylibs.
• Shadow
  • Too much to list.. it hooks way too much.
  • Still misses lots of stuff for Snapchat specifically.

Even Snapchat themselves recommend NoSub ..

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.

• xnu/bsd/kern/kern_proc.c.html#csops
• xnu/bsd/kern/kern_proc.c.html#csops_internal

They execute the following operations:

CS_OPS_STATUS
CS_OPS_CDHASH
CS_OPS_ENTITLEMENTS_BLOB

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_GET_TASK_ALLOW
CS_INSTALLER
CS_PLATFORM_BINARY
CS_DEBUGGED
CS_VALID

A normal device would have these flags:

CS_VALID
CS_HARD
CS_KILL
CS_ENFORCEMENT
CS_REQUIRE_LV
CS_DYLD_PLATFORM
CS_SIGNED

For all available flags and their descriptions, see this page .

The result of CS_OPS_STATUS and CS_OPS_CDHASH are stored and later sent to the Snapchat servers, encrypted.

Bundle check

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)

Dyld check

Snapchat has two methods to iterate all loaded dylibs.

First attempt

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.

Second attempt

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 sys_access(33) syscall.

First list

• /Library/Application Support/PhLite/phlite.bundle/AuthAPI.pem
• /private/var/tmp/cydia.log
• /bin/bash
• /usr/sbin/sshd
• /usr/libexec/ssh-keysign
• /usr/libexec/sftp-server
• /etc/ssh/sshd_config
• /.installed_yaluX
• /Library/LaunchDaemons/dropbear.plist
• /usr/local/bin/dropbear
• /System/Library/Caches/com.apple.dyld/enable-dylibs-to-override-cache
• /.cydia_no_stash
• /var/log/jailbreakd-stdout.log
• /etc/motd
• /usr/lib/libsubstitute.dylib
• /var/tmp/slide.txt

Second list

• /private/var/containers/Bundle/Application/AD659AF8-68C3-4E4B-BF02-236E1F733005/Snapchat.app/Ghay
• /private/var/containers/Bundle/Application/AD659AF8-68C3-4E4B-BF02-236E1F733005/Snapchat.app/Snapchat.crc
• /private/var/containers/Bundle/Application/AD659AF8-68C3-4E4B-BF02-236E1F733005/Snapchat.app/embedded.mobileprovision

Last one (and expected to exist)

• /private/var/containers/Bundle/Application/AD659AF8-68C3-4E4B-BF02-236E1F733005/Snapchat.app/PlugIns

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 .

SCOthmanPrefs
SCOthmanSnapSaver
SCOFiltersOthman
SCSnapchPrefs
SCSnapchLocation
SCOFiltersSnapch
PHSnapSaver
PHRegisterViewController
phlite
dfnvrknsv
PHSSaver
PHMainSettingsVC
SCPPrivacySettings
SCPSettings
SCPSavedMediaSettings
SNAPCHAT_SCPSnapUsageSettings
SNAPCHAT_SCPSegmentedController
SNAPCHAT_CZPickerView
CTAdBase
CTRequestModel
CTBannerView
CPAdManager
MMNativeAdController
TweakBoxStartupManager
SNAPCHAT_GPHelper
SCKsausaPrefs
SCSCGoodSnapSaver
SNAPCHAT_XXXXXXX_GPHelper
SCOFiltersHelper
_xxx
PHSSaver
SIGMAPOINT_GPHelper
SCS SnapSaver
SCW wSnapSaver
CYJSObject
P D
R t
AVCameraViewControlIer
SCAppDeIegate
FLEXManager
oJXM
fJWs
yytp
FLManager
DecryptScriptAlertView
DzAdsManager

Obj-C - Method checks

They also check methods. This happens using objc_getClass and then class_getInstanceMethod . If any exists, you get flagged.

• NSMutableString

  a
  b
  c
  

• SCAppDelegate
  • MZ42SGH98C:
• SCOperaPageViewController
  • saveButtonPressed
• UIViewController
  • dzDidTapGalleryButton

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.

SCAppDelegate
MainViewController
SCChatMainViewController
SCChatViewControllerV3
SCScreenshotDetector
SCBaseMediaOperaPresenter
SCOperaPageViewController
SCLoginService
SCAdsHoldoutExperimentContext
SCExperimentManager
SCCaptionDefaultTextView
SCChatTypingHandler
Story
SCChatMessageV3
SCOperaViewersLayer

Thanks to dzan for telling me to check the __text segment. :-)

Symbol checks

They also check for a couple of symbols using dlsym . If the result is not null, you get flagged.

MSHookMessageEx
MSHookFunction
_Z17replaced_readlinkPKcPcm
hooksArray
_OBJC_METACLASS_$__xxx
_OBJC_CLASS_$_PHSSaverV2
plist
flexBreakPoint
convert_coordinates_from_device_to_interface
OBJC_METACLASS_$_DzSnapHelper
ChKey2

Symbol hook checks

A few symbols are resolved using dlsym to check whether they have been hooked. They first resolve dlsym using 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.

dlsym
objc_getClass
class_getInstanceMethod
sel_registerName
class_copyMethodList
_dyld_image_count
_dyld_get_image_header
dladdr

Environment variables

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.

DYLD_INSERT_LIBRARIES=/usr/lib/TweakInject.dylib
_MSSafeMode=0

Sandbox check

Probably not an issue for anyone.

Fingerprinting

Not much detection done here but still relevant, using sys_sysctl(202) they request at least the following properties.

kern.version
kern.osversion
kern.proc.pid.<PID>
hw.machine

Other

The syscall sys_proc_info(33) is also called a couple of times, which could reveal stuff that is ptracing the process. They also use sys_open(5) , mmap , sys_close(6) and 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.

You could alternatively trace the syscalls using any of the methods discussed in the WhoYouGonnaSyscall talk by Hexploitable . Slides of the talk can be found here .

A story on how I wasted hours on fixing syscalls

Let’s take 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.

Conclusion

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!