Rootless

Rootless is a scheme designed and implemented by the Procursus project. Since the very start of jailbreaking, packages have always been installed directly to the system partition of the device. This had advantages in ensuring package files are organised in expected locations in the filesystem, typically in /Applications, /Library, and /usr, allowing sandbox rules to work as intended. This mixed user-installed packages with the base operating system install, and write access to the system volume is now mitigated by the implementation of Sealed System Volume in iOS 15. Rootless moves all jailbreak packages to /var/jb, predominantly as a long-term solution to the problem posed by SSV. Rootless is implemented starting with palera1n 2.0.

/var/jb
/var/jb is a symbolic link to a path located at /private/preboot/''$boot-manifest-hash. '/procursus. The goal of this is two-fold: to install to a path that is writable, but not affected by sandbox rules that forbid the execution of binaries in /var, and to allow the link to be quickly and safely deleted to evade jailbreak detection.

The dilemma of /var/jb root path
Since the SSV security mechanism of 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 the rootless mechanism to successfully avoid the restrictions of SSV which makes jailbreaking enter a whole new era.

But for the /var/jb root path, many peoples 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.

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 access/stat function, and any iOS development rookie can do it.

Although we can temporarily remove the /var/jb symlink (like xina15 did), but 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, daemon, 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 get failed/error, this would create a confusing situation, even cause device crash and data corruption.

Maybe 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, then we can also easily access it: -- 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-xxxx, and will not interfere with other rootless jailbreak apps/daemon/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 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 hardcode 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, we 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, everyone of the jailbreak community need to consider this problem.

Packaging
Packages intended for installation on rootless iOS use a deb  value of , to differentiate them from the original  , now referred to by the community as "rootful". The architecture name is misleading - this does not change anything relating to arm64 packages prior to iOS 15. APT and dpkg's excellent support for multiple architectures allows a package to be released simultaneously for both rootful and rootless devices, while retaining the same package identifier and version numbers. APT will only install the version of the package that matches the appropriate architecture, even if it has an older version number, and dpkg will refuse to install a package of an architecture it hasn't been configured to support.

Releasing on a self-hosted repo
To release a rootless package on a self-hosted repo, edit  to declare support for the new architecture:

If your repository have  or   packages, they will be available on both rootless and rootful. As the paths for rootless and rootful are different, this is usually not the desired outcome. In this case, it is recommended that repos/suites for rootless and rootful are seperated.

Zebra currently doesn't check this field, however, Sileo, Cydia, and /  require it to include the device's expected architecture, and will display an error message during refresh if it doesn't.

Once the repository has declared support for the architecture, you can release rootless packages on it just as you would have released a rootful package.

If your package still supports rootful in addition to rootless, you can release both packages on the one repo, even if the package identifier and version number are identical. If you intend to discontinue your rootful package and continue only with rootless, you can likewise continue to use the same package identifier and version numbering. APT knows to ignore packages released for architectures not supported by the device.

Ecosystem support
As can be expected, rootless requires a concerted community effort to fully support. The status of some critical pillars of the community are indicated below.

This list is intended only to document areas of the ecosystem that require attention. Specific tweaks should not be added to this list.