How to compile a program with root permission on the cracked iPhone

 

 

How to compile a program with root permission on the cracked iPhone

 

Normally, the program we wrote is published on the App Store, using the official SDK. however, in some cases, functions that cannot be implemented through normal channels can be implemented on the cracked iPhone. take the file management software ifile on cydia as an example. ifile can modify any file in the system. This requires the root permission of ifile, which cannot be implemented without cracking the iPhone.

 

 

For iPhone systems, there are two directories that will install applications

1./Application

2./var/mobile/Applications

 

Applications under/var/mobile/applications have many restrictions. It seems that the program under this directory will certainly run in the sandbox, and it is useless to set permissions. the program restrictions in the/application directory are smaller. To obtain the root permission, the first step is to install the program in the/application directory.

 

Fortunately, cydia. after the system is cracked, most of them will install cydia. build your own cydia source. Third-party software can also be released through cydia. one step to build the cydia source is to package the compiled program into Deb. during packaging, you can specify the directory structure after installation. as for how to set up the cydia source, Google will have a detailed tutorial, which is not mentioned here. We have assumed that the program can be installed in the/application directory.

 

 

 

First, let's briefly review the Unix permission management. The IOS system is actually a small UNIX.

Each file under Unix has its own ownership and access permissions.

For example, the user complex_ OK is a member of the Mobile Group. When he logs on, he creates a file a. By default, a belongs to the user complex_ OK and the group is mobile.

In addition, file a can also specify its own access permissions, which can be divided into three levels: user, group, and other people. Each level can specify whether the file itself is readable, writable, and executable.

 

For example, file a belongs to the user complex_ OK and the group is mobile.

Its access permission is set to user-readable and executable, group-readable and writable, and others are read-only.

 

At this time, the user can execute file a when logging on to complex_ OK. If the user hellokitty also belongs to the group mobile, hellokitty can read and write file a but cannot execute it, others in different groups are read-only.

 

 

 

When we use the iPhone, we actually Log On As a user mobile or a group mobile. if a file belongs to the root user and the permission is set to read-only for the group and other users, the file cannot be modified normally.

Fortunately, Unix can also specify the setuid bit for the object access permission, which is very important.

For example, executable program a is a file, and program a belongs to the root user. assume that user mobile runs program A. If the setuid bit is not set for program a, program a runs with the user mobile permission. if the setuid bit is specified, even if the user is mobile, it is not root, but because program a belongs to the root user, program a can run with the root permission.

 

To understand the role of setuid, it seems that obtaining the root permission is very easy. for example, if we want to write our own file management program afile so that afile runs as root, We will modify the afile program to be a root user, and then set the permission bit to executable, and has the setuid bit. use cydia to install the program to/application. Click the ifile icon to run the ifile program as root.

 

The idea is good, but this is not good. when a user clicks the program icon, the program is called through the iPhone system. The iPhone system will have a security check, which will check that the program will run with the root permission and will not execute, you will see the program flash and it will be over.

 

 

 

Therefore, we need an indirect layer to write a Bootstrap program a and call B through.

First, set the permission of a to read and execute by other people, set the permission of B to root, set the permission to read and execute by other people, and set setuid.

When the user clicks the icon, the iPhone system calls program a. It determines that program A does not have the root permission and runs normally. program a calls program B at this time because it is called by, program a is written by ourselves and does not perform security checks. In this way, after B has a setuid bit, it belongs to root and can be executed as root.

 

 

 

So how can I enable the iPhone system to call boot program a instead of calling normal program B? It's easy to change the name.

For example, if the project you created is afile, an afile is compiled normally. right-click the app file and select "show Package content". Change the executable file "afile" to "afile _" and change your Bootstrap program to "afile". After installation, click the icon and the system will automatically call your Bootstrap program. the compilation of the guiding program is very simple, generally

Int main (INT argc, char * argv [])

{

NSAID utoreleasepool * Pool = [[NSAID utoreleasepool alloc] init];

Nsstring * string = [[nsbundle mainbundle] pathforresource: @ "afile _" oftype: Nil];

 

Argv [0] = (char *) [String utf8string];

Execve ([String utf8string], argv, null );

[Pool release];

Return 0;

}

 

After obtaining the root permission, you can do a lot of things. Be careful when writing your program.

 

 

When packaging the file as Deb, you can use the script to automatically modify the file permissions and permissions.

The command for permission modification is CHMOD and the command for permission modification is chown. Check the usage.