(02-21-2017, 01:21 PM)SxTxN Wrote: Not sure if this is the correct section, but what is the point in jail breaking your AP(Android Phone).

(02-24-2017, 07:10 AM)TheCouchPullsOutButIDont1234 Wrote: Jailbreaking is a term used to describe the removal of certain restrictions put on iOS devices. Before that it was used for UNIX systems (see https://en.wikipedia.org/wiki/Chroot).

TheCouchPullsOutButIDont1234 Wrote:A jailbreak consists mostly of modifying the fstab file that controls the read/write permissions to the system partition. The end result is that the user is able to freely access the system partition and all of the files in it with rw permissions.

• System partition must be mounted with nodev (eliminating /dev/disk0s1)
  
• All partitions must be mounted as superuser, from OUTSIDE of a sandbox (even launchd is in a sandbox, so this is tricky with CS_ENFORCE)
  
• No partitions can hold superuser device nodes
  
• No partition can be remounted with write or execute permission unless in single-user mode, or they were removed in userspace
  

1. NX-bit (no-execute, is applied on all data segments, and many stack-reserved blocks, your 'buffer overflow exploit' won't work with this intact)
   
2. task_for_pid(0) (See example below. This call is what allows us to do those cool 'oh hey, i got root' and all that 'tweaking, theming, and hooking' depends on it)
   
3. AMFI modification (this one is the huge one. AMFI is basically the police when it comes to CS_ENFORCE and code signatures. With this in its stock state, you're stuck with apple-only SDK's, limited hardware access, oh and of course no root/kernel/substrate)
   
4. Sandbox patch (this one is obvious, if you want root filesystem access, or really anything aside from your dinky documents directory, you need this. See link below list for code)
   
5. vm_map_* check patches (replace exit jumps in vm_map_enter, vm_map_remap, and vm_map_protect with no-operations to allow memory to be allocated as write and execute. Another required component for cydia substrate)
   
6. Early init bug (unless you have a hardware, or pre-os software exploit, you'll need this to be able to re-apply patches at boot)
   
7. Massive amount of FS manipulation (iOS has changed drastically over the years, but most software-including Cydia-has not, meaning for anything to work large pieces have to be rearranged, linked, or even replaced)
   
8. HUGE workload and effort input from many people for a very long time.... (these are hacks, really complicated hacks. This isn't just thinking outside of the box anymore, it's hard, it's slow, and it's a lot of moving parts)
   

TheCouchPullsOutButIDont1234 Wrote:On Android it's called rooting. Rooting is a little different and generally not needed unless you intend on running certain applications which require root. I suggest that you do not root unless you know what you're doing (as in you've managed other Linux systems as root before). There are different kinds of root as well. Temporary root means that you'll no longer be rooted after a reboot. Permanent root means that it's persistent across system restarts. Systemless root is available too (as provided by SuperSU) and is a bit more complex.

TheCouchPullsOutButIDont1234 Wrote:Then you have bootloader unlocks. The bootloader is deeper than the userland/kernel that you'd be modifying with rooting. Your operating system which consists of the kernel/userland and some apps is signed cryptographically. This means that the key is checked by the bootloader at boot. Rooting and running things as root user or modifying your system partition in any way on some KNOX enabled Samsung devices will invalidate this chain on trust and result in a non-operational device. A bootloader unlock will shut off the signature checking and allow a custom operating system to be installed. Really anything with a Linux kernel will do, since that what Qualcomm, HTC, and (I think) Samsung bootloaders are set to search for.

TheCouchPullsOutButIDont1234 Wrote:For more info on availability of tools to root or unlock the bootloader of your mobile, search the model number on XDA.

(02-24-2017, 09:21 AM)phyrrus9 Wrote: Firstly, I want to make something clear... With this reply I'm by no means trying to be a dick or anything of the sort. Even though this thread isn't really ever going to be seen by a lot of people, it pains me to see inaccurate information like this. Maybe you already know the corrections I'm about to make, maybe not; either way, I'm making them for the purpose of accurate information only, not a flame war or a pissing match. Thanks <3

(02-24-2017, 07:10 AM)TheCouchPullsOutButIDont1234 Wrote: Jailbreaking is a term used to describe the removal of certain restrictions put on iOS devices. Before that it was used for UNIX systems (see https://en.wikipedia.org/wiki/Chroot).

This one is actually spot on, minus some minor semantics. in the past (like 80's and early 90's), Jailbreaking was quite literally breaking out of a jail. The BSD jail, to be exact (yes, BSD is a derivative of UNIX). Most of the time, these jails were made up of chroots like above (your username is too long for me to type man...) said. The end result of these chroot jails was that the binary would be tricked into believing that one small folder was an entire system. The operator could be assured that one program wouldn't maliciously place some dynamic linker preload segment into an arbitrary, but commonly used binary, because if it did that it would only effect itself.

There's just one huge problem with chroot jails: THEY ONLY WORK ON THE FILESYSTEM! As computers progressed and we started getting "protected memory" (if you've ever had a program segfault, or got a general protection fault in windows, that's what that is) built into our processors at the hardware level, we built real jails. Applications could only load certain types of memory segments at a time, could NEVER mark a segment as executable if it has ever been writable (the W^X check is huge in jailbreaks today), data segments had to be on the other end of the memory map (solution to row hammers), and 90% of the code that's used by a binary is now housed in a completely different memory zone, and often owned by someone else.

With all of that, applications are now in what we call a 'virtual machine', 'sandbox', etc. The term 'jailbreaking' still very much represents the old term, it's just a lot more complicated now.

As far as it only referring to iOS (let's just go wide and say any Apple product--or clone), that's not entirely true. Many embedded, mobile, and even full class hardware and software packages include extreme security measures. For example, My car, which is 18 years old, has a plethora of equipment onboard with the sole purpose of making sure it is IMPOSSIBLE for me to own a spare key. Believe me, I've tried to fool it, remove it, even reverse engineer it. In a way, if I ever made it work right, I'd have jailbroken my car.

TL;DR - Jailbreaks historically were simple UNIX hacks, but as the jails evolved they also spread to just about everything. A jailbreak isn't necessarily an iOS/Apple thing, and for the sake of simplicity it's often used interchangeably with 'rooting'

---

TheCouchPullsOutButIDont1234 Wrote:A jailbreak consists mostly of modifying the fstab file that controls the read/write permissions to the system partition. The end result is that the user is able to freely access the system partition and all of the files in it with rw permissions.

That one's actually completely false. In fact, since iOS 7 (beta builds and forward), there are explicit kernel checks for this sort of thing. Example known rules are:

• System partition must be mounted with nodev (eliminating /dev/disk0s1)
  
• All partitions must be mounted as superuser, from OUTSIDE of a sandbox (even launchd is in a sandbox, so this is tricky with CS_ENFORCE)
  
• No partitions can hold superuser device nodes
  
• No partition can be remounted with write or execute permission unless in single-user mode, or they were removed in userspace
  

A jailbreak (iOS) actually has quite a few parts involved. It would be pointless to do a full writeup about them all (if you'd like one as its own thread, feel free to let me know), so for now I'll just give you a list of the major obstacles that must be tackled before it can even remotely be considered a jailbreak.

1. NX-bit (no-execute, is applied on all data segments, and many stack-reserved blocks, your 'buffer overflow exploit' won't work with this intact)
   
2. task_for_pid(0) (See example below. This call is what allows us to do those cool 'oh hey, i got root' and all that 'tweaking, theming, and hooking' depends on it)
   
3. AMFI modification (this one is the huge one. AMFI is basically the police when it comes to CS_ENFORCE and code signatures. With this in its stock state, you're stuck with apple-only SDK's, limited hardware access, oh and of course no root/kernel/substrate)
   
4. Sandbox patch (this one is obvious, if you want root filesystem access, or really anything aside from your dinky documents directory, you need this. See link below list for code)
   
5. vm_map_* check patches (replace exit jumps in vm_map_enter, vm_map_remap, and vm_map_protect with no-operations to allow memory to be allocated as write and execute. Another required component for cydia substrate)
   
6. Early init bug (unless you have a hardware, or pre-os software exploit, you'll need this to be able to re-apply patches at boot)
   
7. Massive amount of FS manipulation (iOS has changed drastically over the years, but most software-including Cydia-has not, meaning for anything to work large pieces have to be rearranged, linked, or even replaced)
   
8. HUGE workload and effort input from many people for a very long time.... (these are hacks, really complicated hacks. This isn't just thinking outside of the box anymore, it's hard, it's slow, and it's a lot of moving parts)
   

task_for_pid(0) example
Sandbox patch - ARM

TheCouchPullsOutButIDont1234 Wrote:On Android it's called rooting. Rooting is a little different and generally not needed unless you intend on running certain applications which require root. I suggest that you do not root unless you know what you're doing (as in you've managed other Linux systems as root before). There are different kinds of root as well. Temporary root means that you'll no longer be rooted after a reboot. Permanent root means that it's persistent across system restarts. Systemless root is available too (as provided by SuperSU) and is a bit more complex.

Couldn't have said it better -- 'nuff said

TheCouchPullsOutButIDont1234 Wrote:Then you have bootloader unlocks. The bootloader is deeper than the userland/kernel that you'd be modifying with rooting. Your operating system which consists of the kernel/userland and some apps is signed cryptographically. This means that the key is checked by the bootloader at boot. Rooting and running things as root user or modifying your system partition in any way on some KNOX enabled Samsung devices will invalidate this chain on trust and result in a non-operational device. A bootloader unlock will shut off the signature checking and allow a custom operating system to be installed. Really anything with a Linux kernel will do, since that what Qualcomm, HTC, and (I think) Samsung bootloaders are set to search for.

Pretty close, yeah. I just want to elaborate a little on that "chain of trust" you mentioned. That one is actually really important, because it's been the reasons for unbreakable security as well as a giant hole into "unbreakable security" in its day. The chain works pretty simply. Like (above) said, everything on that device is "signed" (not really though, most of the core OS isn't, and those aftermarket apps don't have to be). What that means is the OS (still talking apps at this point) knows both who made the software, and that it hasn't been tampered with. Most of the time, these signatures are just SHA-1 hashes that have been encrypted (signed) with someone important's private key (or in the old Apple days, the manufacturer's private key. I don't know if Google does this, but it's possible).

Now, if we jump down to the OS, it gets hit a little stricter. Software developers don't usually put modification restrictions on open source software, so don't try and come up with a reason about it being ripped off, or that they want to limit you or anything like that. They do it because with large markets like Android and iOS, there is a massive potential for malware. The last place you want that malware is in a core component like the OS. So, everything with any sort of authority is signed and checked periodically by usually the kernel, sometimes other processes can do this and report back or signal to another to kill it.

So, if the kernel checks the OS, who checks the kernel?
The kernel monitors itself, it being linux at its core means it's doing this quite well, and very strict. It would rather kill itself than let some process mess something up in there. But, you can't trust it completely, So on boot it is checked with a low level (direct hardware) process inside a RAMDISK. If it fails a signature check, a minimalistic "emulator" of the OS core is already loaded, and can attempt to recover. This is also the same place that firmware updates are applied.

Who checks the ramdisk?
Nobody. I kid you not, nobody. In the early days, companies thought people wouldn't ever figure this one out...we did. So, their solution was to encrypt the ramdisk with a hardware key. What this means, is that Google makes the low level ramdisk, and then they just encrypt the entire thing with their special in house private key (most use different keys for different parts of the system). Burned onto the SoC of the device, is Google's public key, so when the device boots up, it loads the ramdisk into memory, then decrypts it with its burned-in key. This will never fail, but if you've tampered with it AT ALL, it won't be the right data, and you'll end up with a seemingly bricked device.

So wait...wasn't the bootloader supposed to do something?
Of course, it's the job of the bootloader to transition the device, setup memory protection zones, load the ramdisk, and give it the info it needs to kick off the kernel. All this 'unlocked bootlader' stuff really is, is storing the ramdisk unencrypted, and just loading it and going off like it doesn't matter. In a pure sense, this is BROKEN, but you'll do what you want and nobody's going to stop you.

TheCouchPullsOutButIDont1234 Wrote:For more info on availability of tools to root or unlock the bootloader of your mobile, search the model number on XDA.

I've got to add some critical comments on that one... XDA is a good place if you've got a common problem, because it's likely the answer is there (probably 400 times), and you might even get some kickass tutorials on how to fix it. However, if you're not exactly a wizard, be careful. XDA has one of the worst memberbases out there if you're looking at something that might get some people mixed up. Avoid the pissing competitions, it's just not worth it. If you've got real troubles, or you want to learn a lot more than you will ever need or want to know, jump on IRC. Freenode has a few VERY active channels with extremely talented people who literally have nothing better to do than help newcommers and tinkerers with their struggles.

Quote: Jailbreaks historically were simple UNIX hacks, but as the jails evolved they also spread to just about everything. A jailbreak isn't necessarily an iOS/Apple thing, and for the sake of simplicity it's often used interchangeably with 'rooting'

Quote:That one's actually completely false. In fact, since iOS 7 (beta builds and forward), there are explicit kernel checks for this sort of thing.

Quote:I just want to elaborate a little on that "chain of trust"

Quote:I've got to add some critical comments on that one... XDA is a good place if you've got a common problem, because it's likely the answer is there (probably 400 times), and you might even get some kickass tutorials on how to fix it. However, if you're not exactly a wizard, be careful. XDA has one of the worst memberbases out there if you're looking at something that might get some people mixed up

(02-24-2017, 09:21 AM)phyrrus9 Wrote: Firstly, I want to make something clear...

(02-26-2017, 07:48 AM)Ender Wrote:

(02-24-2017, 09:21 AM)phyrrus9 Wrote: Firstly, I want to make something clear...

Dude.... This could've made up an entire thread.