Nintendo's JB detection on iOS is pretty much malware. It uses an obfuscating compiler, encrypts* its strings, checks for both existing and non-existing files to detect common jailbreaks, does its SVCs by itself to avoid hooking, checks for fork/execl/etc system hooks (1/3)
It also dynamically writes a dylib into the Documents folder to see if they can dlopen it. The dylib reveals the name "JBDetectLib", which is probably some commercial solution Nintendo pays for, see screenshot. Might as well find some private API and snitch to Apple >< (2/3)
* This is very on-character for Nintendo, the strings are "encrypted" with a static XOR key
BTW, each step (e.g. checking for files) has *three* different implementations which have varying implementation details (e.g. one implementation checks for files via a symlink, while the other checks them directly) to make it more cumbersome patch.
@LIJI32 Which part of what you described is malware? Obfuscating code/strings is not malware. Dropping a dylib is also not malware unless it contains malicious code, which it probably doesn't, as you would've mentioned that.
@momo5502 It is checking of the existence of over 120 user files outside of its app sandbox, that’s a sandbox escape and malicious behavior. Malware-grade obfuscation of *jb specific* parts of the code (and nothing else) is just the cherry on top.
@LIJI32 You're describing a protector... no harmful behavior.
@LIJI32 Yikas, wild how much Apple allows if you are big enough brand/company.
@xLordDaniel MS Office for iOS used to use loads of private APIs in plain sight, quite funny tbh
@LIJI32 The idiot isheeps know no more than hitting update iOS button, thats definitely a bad move from them, an appstore app shouldn’t be outside of sandbox