The Future of the /var/jb Root Path

[H5GG]

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.

[CRKatri]

1. It's now easier to hide because it's just one path
2. This is not our issue.

[Cryptiiiic]

https://open.spotify.com/track/7o67roCVsFiCt7Cf0ZLOJq?si=oYE0cyRhRqCoDOBkYZx6dQ

[0xallie]

Fugu15 Max already installs the bootstrap in /private/preboot/<boot-manifest-hash>/jb-XXXXXX, but extending the random suffix to /var/jb itself wouldn't make much sense, the whole point of that symlink is to stay constant even if implementation details change, and it would require everything to resolve the path at runtime. Rootless adoption has already started using the current system and this would be a breaking change, so you're too late with your idea either way.

[H5GG]

Fugu15 Max already installs the bootstrap in /private/preboot/<boot-manifest-hash>/jb-XXXXXX, but extending the random suffix to /var/jb itself wouldn't make much sense, the whole point of that symlink is to stay constant even if implementation details change, and it would require everything to resolve the path at runtime. Rootless adoption has already started using the current system and this would be a breaking change, so you're too late with your idea either way.

Because of the existence of the /var/jb fixed path, the random path in preboot is still easy to detect.
see: https://github.com/tuancc-repo/JBDetect15/blob/2424a9ef349374540cabd5f5fdec811eb8614c3f/main.m#L251

I've been building this idea since the early days of the xina jailbreak, but no one seems to really care about the future of jailbreaks.

[0xallie]

Yes, but it's much easier to temporarily remove one symlink or hide it using hooking than a ton of different paths.

[CRKatri]

I've been building this idea since the early days of the xina jailbreak, but no one seems to really care about the future of jailbreaks.

I take offense at this, we created rootless because it's the future of jailbreaks.

Anyways, your idea doesn't work. I can build every package 238,328 times, once for each /var/jb-XXX, and people can't package their tweaks that many times. It's just not possible.

[H5GG]

Yes, but it's much easier to temporarily remove one symlink or hide it using hooking than a ton of different paths.

temporarily remove the symlink of /var/jb will cause many problems, https://theapplewiki.com/wiki/Rootless#Dilemmas
re

It is a feasible way to redirect the path by using hook, but it will also bring some stability and compatibility problems.

How about randomizing /var/jb and using a unified environment variable to access this random path, after all, environment variables can be isolated for each process individually.

[H5GG]

I've been building this idea since the early days of the xina jailbreak, but no one seems to really care about the future of jailbreaks.

I take offense at this, we created rootless because it's the future of jailbreaks.

Anyways, your idea doesn't work. I can build every package 238,328 times, once for each /var/jb-XXX, and people can't package their tweaks that many times. It's just not possible.

Forgive my wording, I totally agree that rootless is a great project.

I just have some ideas about the fixed path for /var/jb, we dont need build ervery package many times, we only need to randomize the path of /var/jb, and then use a method that can be isolated for each process to access this randomized path, such as setting an environment variable. After all, environment variables can be set individually for each process.

[asdfugil]

almost all of the bootstrap are not jailbreak specific software and it is entirely unfeasible to patch them so they can use a random prefix

[0x6ff]

there is no point in this, /var/jb could already be hidden easily and the boot manifest hash would take years to crack

[CRKatri]

Until apps just do getenv("JBPATH") =! NULL.
Jailbreak detection bypasses is a losing battle, it's not worth completely ruining the stability of the jailbreak and creating a ton of super hacky patches for dpkg and libiosexec and every other package.

[asdfugil]

to clarify, boot manifest hash is visible to every app on iOS 16, so the path under the boot manifest hash would also need to be random there (like /p/p/XXXXX/jb-YYYY)

[H5GG]

Until apps just do getenv("JBPATH") =! NULL.
Jailbreak detection bypasses is a losing battle, it's not worth completely ruining the stability of the jailbreak and creating a ton of super hacky patches for dpkg and libiosexec and every other package.

Environment variables can be set individually for each process. In the future, we only need to build a blacklist selector app to allow users to select apps that need to hide this special environment variable. Other processes not in the blacklist can still access this environment variable normally, without any impact on compatibility and stability.

The detection of /var/jb fixed path is fundamentally different from other jailbreak detections.
1: Any rookie ios developer can detect it by calling access/stat with one line of code.
2: If all the binaries released by the jailbreak community use the fixed path of /var/jb, no one will be able to change this habit in the future.
3: Other jailbreak detections can basically be implemented in the future without affecting compatibility, and people don't need to rebuild their released binaries.

As the upstream of the jailbreak community, I think it is our responsibility to take the lead in addressing and addressing this hassle.

[H5GG]

to clarify, boot manifest hash is visible to every app on iOS 16, so the path under the boot manifest hash would also need to be random there (like /p/p/XXXXX/jb-YYYY)

yes, Fugu15Max already randomize the jailbreak directory in the preboot. but /var/jb is still a fixed path.
And the binaries released by the third party in the future will use this fixed path as the interface, this is the problem.

[CRKatri]

When you have a working dpkg patch to allow packages to be installed into these randomized paths without having to repackage, let me know, until then this will stay closed and this discussion will end.

[H5GG]

Yes, but it's much easier to temporarily remove one symlink or hide it using hooking than a ton of different paths.

And there is a prerequisite for redirecting the path of /var/jb through hooks, that is, the JIT privilege of the process is required.
Considering that jailbreaking will become more and more difficult in the future, maybe a certain jailbreaking tool in the future will not be able to (perhaps in stages) grant JIT privilege to the process, and this solution will not be able to be implemented.
And some jailbreak software will use inline assembly to call svc 0x80 instruction to access files, which will also be difficult to deal with.
In short, the way to redirect /var/jb through hook will bring many compatibility and stability issues, and its not a sustainable way.

[0xallie]

There's always the trivial solution of removing the symlink entirely and rebooting to unjailbroken state, which will always work, assuming the path under /private/preboot/<boot-manifest-hash> is randomized and everything else jailbreak-related is inside it.

It may not be perfect if you also want to use tweaks in the apps you're trying to bypass, but that's always been more problematic anyway.

[H5GG]

There's always the trivial solution of removing the symlink entirely and rebooting to unjailbroken state, which will always work, assuming the path under /private/preboot/<boot-manifest-hash> is randomized and everything else jailbreak-related is inside it.

It may not be perfect if you also want to use tweaks in the apps you're trying to bypass, but that's always been more problematic anyway.

I mean for apps that don't need to use tweak, we can hide the visibility of /var/jb to it, by randomizing.

There are too many apps that even if you don't use the tweaks for it, it will still endlessly prompt you that jailbreak has been detected and deny service, and may even ban you. This really makes jailbreak less and less popular, and the entire jailbreak community got into trouble.

[CRKatri]

I am locking this thread until you can give me a working patch for dpkg.