App with jailbreak detection rejected by Apple

前端 未结 1 2082
自闭症患者
自闭症患者 2021-02-09 13:26

the App we are working on was rejected because the Device in the Review Process was detected as jailbroken ^^

To detect a jailbroken Device, several Tests were performed

1条回答
  •  别跟我提以往
    2021-02-09 13:35

    From https://www.theiphonewiki.com/wiki/Bypassing_Jailbreak_Detection

    While there are countless ways apps can implement checks for jailbroken devices, they typically boil down to the following:

    Existence of directories - Check your file system for paths like /Applications/Cydia.app/ and /private/var/stash, amongst a handful of others. Most often, these are checked using the -(BOOL)fileExistsAtPath:(NSString*)path method in NSFileManager, but more sneaky apps like to use lower-level C functions like fopen(), stat(), or access().

    Directory permissions - Check the Unix file permissions of specific files and directories using NSFileManager methods as well as C functions like statfs(). Far more directories have write access on a jailbroken device than on one still in jail.

    Process forking - sandboxd does not deny App Store applications the ability to use fork(), popen(), or any other C functions to create child processes on non-jailbroken devices. sandboxd explicitly denies process forking on devices in jail. if you check the returned pid on fork(), your app can tell if it has successfully forked or not, at which point it can determine a device's jailbreak status.

    SSH loopback connections* - Due to the large portion of jailbroken devices that have OpenSSH installed, some apps will attempt to connect to 127.0.0.1 on port 22. If the connection succeeds, it means OpenSSH is installed and running on the device, therefore it is jailbroken.

    system() - Calling the system() function with a NULL argument on a device in jail will return 0; doing the same on a jailbroken device will return 1. This is since the function will check whether /bin/sh exists, and this is only the case on jailbroken devices.[1]

    dyld functions - By far the hardest to get around. Calling functions like _dyld_image_count() and _dyld_get_image_name() to see which dylibs are currently loaded. Very difficult to patch, as patches are themselves part of dylibs.

    *Only a very small number of applications implement this (as it is not nearly as effective as the others)

    These methods seem like they would be less likely to be rejected by apple and are very simple to use.

    The above passage has been edited for brevity

    0 讨论(0)
提交回复
热议问题