Patching sepolicy in the ramdisk to achieve root without permissive kernel

@garyd9

This thread is to discuss the possibility of rooting the Samsung Note 10.1 (2014 Edition) without resorting to a permissive kernel. The background information for this thread can be found from the following posts:

http://forum.xda-developers.com/apps...ellow-t3219344
Chainfire's method of patching the device's sepolicy with a reference device to give sudaemon the required permissions that open the doors for rooting and more.

http://forum.xda-developers.com/show...3&postcount=26
garyd9's application of Chainfire's idea to the Note 5, which appears to have worked successfully.

http://forum.xda-developers.com/show...postcount=2375
My attempt to replicate garyd9's method on the P607T, which failed.

http://forum.xda-developers.com/show...postcount=2376
garyd9's recommendation on how to troubleshoot.

And finally the results from following Gary's advice:

Quote:

0 - Check 1 - Check 2 - Fail Tools and Process: Listing all of them. The one I followed for this methodical approach is the first one. Including the others for context, in the hopes that it will indicate what the next step should be. 1) Carliv's Kitchen Followed instructions, placed boot.img in the boot_resources folder, unpacked it with the tool, changed nothing, repacked with the same tool, made tar using "tar -cf boot_stock_repack.tar bootxxx.img" bootxxx.img is what Carliv generated, of course. To compare, made tar of the stock boot.img as well, naming it boot_stock.tar. Flashing boot_stock.tar works, device boots, no problems. Flashing the boot_stock_repack.tar fails with "Unsupport dev_type" on the device. Additional Info: ------------------------------------------------ 2) bootimg_tools split_boot to extract the kernel and ramdisk and unpack the ramdisk. No warnings are issued, nothing suggests there is any problem. repack_ramdisk to repack ramdisk, no problems here either. mkbootimg to create new boot.img; no arguments are specified since apparently it would automatically create the right image. tar -cf to create ODIN flashable tar. Flashing this would succeed in ODIN, but the device would reboot in Download Mode with "Unable to boot normal mode" showing on the device. 3 suggests an explanation why. 3) To extract the kernel and ramdisk, used umkbootimg instead of split_boot from the same toolset. This time, it issued a warning about the original img being created with a non-standard mkbootimg, said I should edit mkbootimg.c before making the new image. Despite the warning, it also provided a mkbootimg command to use to ensure the new img is created correctly. Googling the warning suggested downloading android source code to get the mkbootimg.c file, but nothing beyond that on what needs to be done. While not optimistic, I still tried the mkbootimg command it gave me, as well as with extra arguments to correct the addresses till boot_info in the toolkit matched for the stock and new images. SAME outcome as with 2. 4) Modding_My_Mind/SHM's toolset This one claimed to automatically make the necessary corrections for a non-standard boot image and definitely did something different. Unlike the other generated images which were smaller in size than the original, this one was the same size. Making a tar and flashing it though failed with Unsupport dev_type showing on the device. I have contacted SHM to see if he can shed some light on this. NOTE: In the thread where I got this from, when dealing with a non-standard image, his output seems to show this warning. BUT, I got no such warning when I did this on my image. 5) Carliv's as in the first item here. It generated a boot.img that matched in size and failed with the same error as the previous, suggesting it is definitely making SOME changes to the mkbootimg arguments to work with the 'non-standard stock image', BUT I have no idea what these changes are, nor where to look for them. Next Step? I never tried a full manual repacking of the ramdisk and generation of the image. Not sure if the error could be in the way the ramdisk is being repacked (which seems improbable, since its a gzip + cpio command that does this, not much to mess up there), or if its the way in which the new img is being created (seems probable, given that many arguments need to be passed here and Im using binaries that I do not know and understand at all). I tried to look for other ways to create the img file, BUT pretty much everything keeps pointing to these same toolsets and binaries. With regards process, I have not been able to find anything on how to make 'manual adjustments' to the addresses/offsets. Any advice on where to go/look next?

This thread is started to continue exploring this option specifically for the Note 10.1 (2014 Edition). The idea is to achieve root by modifying only the ramdisk and not touching the kernel, and definitely NOT going to the extreme step of using a permissive kernel.