Tuancc's /var/jb-XXXXX path proposal
I'm moving the section posted to the article page by Tuancc here - this doesn't seem like it should be in the main namespace since it's a proposal, not a statement of fact (at least not yet).
This seems to also have been posted on https://github.com/ProcursusTeam/Procursus/issues/1378 and there is a discussion about it there.
Dilemmas
Since the introduction of SSV security mechanisms in iOS 15, jailbreak development has encountered many great challenges and difficulties. However with the efforts of developers such as @xina520 and @opa334, we have seen a new dawn. They use a rootless mechanism in their jailbreaks to successfully avoid the security measures that SSV proposes, which also makes jailbreaking enter a new era.
But for the /var/jb root path, many people have been very worried about that rootless jailbreak stores all data and files in it, it is a completely fixed path. All jailbreak apps, daemon, tweaks will refer to this path, and hardcode into the final released binary.
/var/jb is the main directory for a rootless jailbreak, once the jailbreak community in the rootless era forms this specification, it is very difficult for anyone to change and adjust it.
However this fixed path is very easy to be detected, only one line of code is needed to call the access/stat function in order to detect it, any iOS development rookie can do it. Although we can bypass this via temporarily removing the /var/jb symlink (like XinaA15), however this is a very lazy and bad method. Doing it like this will cause two main issues that will cause major trouble in the future:
- It becomes repeatedly annoying for end-users when they have to remove & restore it upon opening different apps, and those users will get tired of it fairly quickly.
- Most to almost all jailbreak apps, daemons, tweaks, will all use this path. Upon temporarily removing it, maybe a jailbreak app, daemon, tweak that are accessing this path or is about to access this path will fail or error. This creates a confusing situation which can cause the device to panic and corrupt data.
However there are better ways to better fix this issue: First we add a random suffix to the /var/jb path, like /var/jb-xxxxx, and then use environment variables as the rootless jailbreak interface. For example: we create an environment variable named JBRoot and set it to /var/jb-xxxx, then we can also easily access it via:
in shell code:
cat $JBRoot/my_file_path
in Objective-C code:
NSString* my_file_path = [NSString stringWithFormat:@"%s/my_file_path", getenv("JBRoot")];
in C/C++ code:
char my_file_path[PATH_MAX]={0};
snprintf(my_file_path, sizeof(my_file_path), "%s/my_file_path", getenv("JBRoot"));
So what is the difference between this method and the fixed path /var/jb?
The difference is that the fixed path of /var/jb is visible to all processes, but environment variables can be set individually for each process. In the future, we can create a blacklist, and we can choose to hide the JBRoot environment variable for some apps. In this way, they will not be able to detect the existence of /var/jb-xxxxx, and will not interfere with other rootless jailbreak apps/daemon/tweak's access to /var/jb-xxxxx.
Why is hiding /var/jb so important?
First of all, the data in the file system is the easiest to detect. as said before, any rookie in iOS development can detect the existence of /var/jb with a single line of code. This will make the detection of /var/jb very widespread and ubiquitous, eventually a large number of apps will detect this path, making jailbreaking difficult to use if you don't handle /var/jb.
Secondly, the /var/jb path is used as the interface standard for rootless jailbreaks, and every jailbreak app/daemon/tweak will use it, and it is hardcoded into the released binary. This means that if we do not deal with it now, we will not be able to deal with this problem in the future as time goes on.
Over the period of time that jailbreaking has been in existence, we have witnessed the brilliance of jailbreak from iOS 5 to iOS 9, and also witnessed the wisdom of the community starting from iOS 10, and then again in iOS 15. Jailbreaking has started to enter a new era, and everyone in the jailbreak community should need to consider more about this problem.