The Future of the /var/jb Root Path

[H5GG]

The Future of the /var/jb Root Path

Since the SSV security mechanism of ios15, jailbreak has encountered great challenges and difficulties, but with the efforts of big names such as xina and opa334, we have seen a new dawn. They use the rootless mechanism to successfully avoid the restrictions of SSV, Let the jailbreak enter a new era.

But for the /var/jb root path, I have been very worried. Rootless jailbreak stores all data and files in it, it is a completely fixed path. All jailbreak apps, deamon, tweaks will refer to this path, and hard Encoded into the final released binary.

So what is /var/jb, it is the interface of rootless jailbreak, once the jailbreak community in the rootless era forms this specification, it is very difficult for anyone to change and adjust it.

But the fixed path is very easy to be detected, only one line of code is needed to call the acess/stat function, and any ios development rookie can detect it.

Although we can temporarily remove the /var/jb symlink (like xina15 did), but I think this is a lazy way, and this way will cause two things that will cause major trouble in the future:
1: It's really annoying that people have to repeatedly remove and restore it when opening different apps, and people get tired of it very quickly.
2: Almost all jailbreak apps, deamon, tweaks will use this path, when you temporarily remove it, maybe a jailbreak app, deamon, tweak is accessing this path, or is about to access this path, and then they will not be able to find it Well, this would create a confusing situation.

I think we have a better way to deal with this problem, 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, we can also easily access this environment variable:

in shell code:

cd $JBRoot

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 of directly using /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-xxxx, and will not interfere with other rootless jailbreak apps/deamon/tweak's access to /var/jb-xxxx.

Why is hiding /var/jb so important and urgent?
Some people may ask, even if we hide /var/jb, there are still many other ways to detect jailbreak, why do we have to deal with /var/jb first.
First of all, the data in the file system is the easiest to detect. As I 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 difficult 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/deamon/tweak will use it, and it is hard-coded into the released binary, which means that if we do not deal with it now, we will not be able to deal with this problem in the future up.

As a loyal jailbreak fan, I have witnessed the brilliance of jailbreak from ios5 to ios9, and also witnessed the wisdom of the jailbreak community starting from ios10, and starting from ios15, jailbreak has entered a new era, I sincerely hope that the masters of the jailbreak community can consider this issue.