Patching sepolicy in the ramdisk to achieve root without permissive kernel - Galaxy Note 10.1 (2014 Edition) Android Developmen

UPDATE 2: Tutorial and Patched Boot.imgs available here.
UPDATE: Chainfire's suggestion to patch sepolicy in the ramdisk for Samsung LL ROMS works perfectly. For unknown reasons, ODIN flash would not work, but flashing the patched boot.img with TWRP allowed me to successfully achieve root with a fully stock kernel and SEAndroid Enforcing. All the information you need is in the sources I quote below. Once I am confident that everything is working fine, I will create another thread with a concise guide and my patched boot.img for those who don't want to get their hands dirty. In the meantime, anybody who sees this should know that the same process can be done with the P605 as well, with your native ROM instead of a ROM from a different region. Also, stock kernel means no wifi dropping problems either!
@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/supersu/wip-android-6-0-marshmellow-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/showpost.php?p=63250893&postcount=26
garyd9's application of Chainfire's idea to the Note 5, which appears to have worked successfully.
http://forum.xda-developers.com/showpost.php?p=63552454&postcount=2375
My attempt to replicate garyd9's method on the P607T, which failed.
http://forum.xda-developers.com/showpost.php?p=63555137&postcount=2376
garyd9's recommendation on how to troubleshoot.
And finally the results from following Gary's advice:
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?
Click to expand...
Click to collapse
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.

---

Can you post a boot.img that's known good? I don't use kitchens, dining rooms, or even bathrooms. I use my own compiled tools... (Are you doing all this work in linux or using win-blows?)

---

I've attached "imgtools.zip." Within are the linux binaries I use for unpacking and repacking boot images. They should work under ubuntu 64-bit 14.04.
Here's some idea of how you might use them (again, linux..)
Code:
# assumes "boot.img" in the cwd is the original boot image.
mkdir stockboot
# unpack the boot image into a new directory called "stockboot"
unpackbootimg -i boot.img -o stockboot
That will dump a bunch of files into that new directory...
Now, to remake it:
Code:
cd stockboot
mkbootimg --kernel boot.img-zImage --ramdisk boot.img-ramdisk.gz --base `cat boot.img-base` --pagesize `cat boot.img-pagesize` --kernel_offset `cat boot.img-kerneloff` --ramdisk_offset `cat boot.img-ramdiskoff` --tags_offset `cat boot.img-tagsoff` --dt boot.img-dtb -o ../newboot.img
What that does is goes into the directory we unpacked the original image to, and then just puts it back together in the original directory under a new name (newboot.img.) For all the parameters, we just re-use the values and items extracted from the stock boot image. The new image won't be identical to the old one, but the sizes should be close.

---

garyd9 said:
Can you post a boot.img that's known good? I don't use kitchens, dining rooms, or even bathrooms. I use my own compiled tools... (Are you doing all this work in linux or using win-blows?)
Click to expand...
Click to collapse
tar of stock boot.img attached. Until Carliv's kitchen, all attempts were on Slackware 14.1. Only Carliv's was done on Win 10.
garyd9 said:
I've attached "imgtools.zip." Within are the linux binaries I use for unpacking and repacking boot images. They should work under ubuntu 64-bit 14.04.
Click to expand...
Click to collapse
Will take a shot at it tomorrow with your binaries and post results.

---

karthikrr said:
tar of stock boot.img attached. Until Carliv's kitchen, all attempts were on Slackware 14.1. Only Carliv's was done on Win 10.
Click to expand...
Click to collapse
I'm not going to talk about that. I have a semi-religious belief that anyone using windows to manipulate linux kernel images is BEGGING for trouble. (It's not that I'm anti-windows. I'm just against mixing the platforms.)
Anyway, followed my own directions to unpack and repack your boot.img. I took the resulting newboot.img and zip'd it up (and attached it here.) This is NOT a TWRP/CWM flashable zip. It's just archived to save space (and make XDA's file manager happy.)
I didn't see any strange messages about non-standard images or anything like that. In fact, the process was outright boring.
(FYI, I might not be capable of responding to messages again until late tomorrow night or Sunday...)
Code:
~/temp$ unpackbootimg -i boot.img -o stockboot
BOARD_KERNEL_CMDLINE console=null androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3
BOARD_KERNEL_BASE 00000000
BOARD_PAGE_SIZE 2048
BOARD_KERNEL_OFFSET 00008000
BOARD_RAMDISK_OFFSET 02000000
BOARD_TAGS_OFFSET 01e00000
BOARD_DT_SIZE 1574912

---

oh, that might not boot for you. my repack cmdline doesn't pull in the cmdline from the kernel unpack. Add something like this to the mkbootimg cmdline:
Code:
--cmdline "`cat boot.img-cmdline`"
(You might have to actually type out the cmdline inside the quotes instead)

---

garyd9 said:
I didn't see any strange messages about non-standard images or anything like that. In fact, the process was outright boring.
Click to expand...
Click to collapse
Not surprised . Most tools available won't give this information. Its typically only available as a cosmetic feature. My work is derived from Xialou's as seen here but modified to work for Linux and ARM alike.
I have attached images showing me unpacking and repacking his stock boot.img from my device.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
With that said, I have been researching this error, "unsupported dev_type", and most of what I have came across points to it being a specific issue with Odin itself. However, I can't really rule this out because his device does not have root so I presume he can't write the boot image to his boot partition using the dd command in a terminal to verify if it will boot up using this method. If it were to boot up then it would clearly point the problem towards the Odin program being used.
Sent from my Ascend Mate 2 using Tapatalk
---------- Post added at 02:21 PM ---------- Previous post was at 01:59 PM ----------
@karthikrr, when making an Odin compatible package you are using the command:
Code:
tar -cf
I don't own a Samsung device but I have helped build TWRP for some so given my experience shouldn't the command actually be:
Code:
tar -H ustar -c boot.img > Odin_boot.tar
Where Odin_boot.tar is the package used to install via Odin.
Please use that command i just shared with you and try again.
Sent from my Ascend Mate 2 using Tapatalk

---

garyd9 said:
oh, that might not boot for you. my repack cmdline doesn't pull in the cmdline from the kernel unpack. Add something like this to the mkbootimg cmdline:
Code:
--cmdline "`cat boot.img-cmdline`"
(You might have to actually type out the cmdline inside the quotes instead)
Click to expand...
Click to collapse
SHM said:
I don't own a Samsung device but I have helped build TWRP for some so given my experience shouldn't the command actually be:
Code:
tar -H ustar -c boot.img > Odin_boot.tar
Where Odin_boot.tar is the package used to install via Odin.
Please use that command i just shared with you and try again.
Click to expand...
Click to collapse
Short version: No luck!
Long version:
In all cases, just unpack stock boot.img and make new stock boot.img, no changes.
Gary, everything except for the ODIN flash was done on Linux for the following.
SHM, all tars created using your command.
1) Used Gary's tools following all instructions including cmdline to create garyboot.img and then .tar
2) Used SHM's tools to try again, this time with his tar cmd to create shmboot.tar
3) Found a mkbootimg binary in the P607T KK Source from Samsung's opensource portal. Used that to create P607Tboot.tar from the img unpacked by Gary's tools.
4) This might have been completely off-base, but ... Used xialou's mkboot-master source code; edited mkbootimg.c with the Non-Standard addresses from SHM's image above. Ran make to compile a new binary, used it to create recboot1.tar
5) umkbootimg from another toolset gave me a different set of addresses to change in the mkbootimg.c file, this time to change kernel offset, ramdisk offset and second offset. New binary again, after make clean and make, used it to create recboot2.tar
ODIN 3.10.6 failed with the same unsupport dev_type error with ALL of these images.
Tried the first two with ODIN 3.09, no difference, same error again.
Questions:
SHM, your image above, as well as the warning on umkbootimg both say Modify mkbootimg.c and try again ... Should I look into this more?
Is there ANY chance that the problem is not with mkbootimg, but with unpackbootimg?
SHM, you mentioned unsupport dev_type in context with ODIN problems. Where can I find more info on this? FWIW, I have never had ODIN problems before, flashing firmware updates and twrp on this tablet, as well as on my Note 2 phone. Can't think why only in this case, it should fail like this.
What are my alternatives to ODIN? Can I flash using twrp? I have never created a twrp flashable zip, so will go read up on that some now, but do you think it makes sense to try that? If not, are there any other methods of flashing to try before being absolutely sure the problem is with mkbootimg?

---

@karthikrr, if you have the latest twrp for your device than there is something you need to try to see if in fact this is a problem with Odin specifically. I want you to take your boot.img that has been unpacked and repacked but don't make it into a tar. Leave it as an image. Boot up TWRP then select Install. At the bottom right of your screen will be a button that says, zip. If you click on it you will see it change to, image. This allows you to install either a flashable zip or flash a boot/recovery.img. Select to install the boot.img. The next screen will ask you to select either the boot or recovery partition based upon the image you chosen. In this case, choose the boot partition. Swipe to proceed. When done, reboot your system. If your device boots up successfully then your problem lays with Odin. Let me know if these instructions are a bit confusing.
Sent from my Ascend Mate 2 using Tapatalk

---

SHM said:
@karthikrr, if you have the latest twrp for your device than there is something you need to try to see if in fact this is a problem with Odin specifically.
Click to expand...
Click to collapse
No confusion, I even have all the imgs loaded on the device to try this. Two reasons I did not try it yet, perhaps you can clarify whether these are legitimate concerns:
1) TWRP is formally not out for LL on my device yet. I, like everybody else out there, is using the latest KK img on this device and it SEEMS to be working properly. The only noticeable difference I have seen is that it seems to take a lot longer to get into twrp than usual. But I made some 5 backups of the device yesterday and all of them seemed to be fine. Given this is not official for LL, I wasn't sure if it was wise to try to flash an image from twrp.
2) I was also concerned that PERHAPS Odin is doing me a favour and aborting the flash because there was something wrong, and that if I went with twrp and it flashed it without any problems, I might find that it killed my device. I was discussing this with a friend (no experience with Android flashing, but a developer who knows these things) and he said it was highly unlikely that this would happen, as long as the img I was flashing was within the size limit for my device, which I believe is 11mb. All the images are 10.5mb. Thoughts?

---

karthikrr said:
No confusion, I even have all the imgs loaded on the device to try this. Two reasons I did not try it yet, perhaps you can clarify whether these are legitimate concerns:
1) TWRP is formally not out for LL on my device yet. I, like everybody else out there, is using the latest KK img on this device and it SEEMS to be working properly. The only noticeable difference I have seen is that it seems to take a lot longer to get into twrp than usual. But I made some 5 backups of the device yesterday and all of them seemed to be fine. Given this is not official for LL, I wasn't sure if it was wise to try to flash an image from twrp.
2) I was also concerned that PERHAPS Odin is doing me a favour and aborting the flash because there was something wrong, and that if I went with twrp and it flashed it without any problems, I might find that it killed my device. I was discussing this with a friend (no experience with Android flashing, but a developer who knows these things) and he said it was highly unlikely that this would happen, as long as the img I was flashing was within the size limit for my device, which I believe is 11mb. All the images are 10.5mb. Thoughts?
Click to expand...
Click to collapse
If the partition table between KK and LP does not vary on your device then it will be fine.
As for flashing a boot image to your boot partition via twrp, this will not brick your device. Worse case, device doesn't get past the bootloader or the boot animation. In this case, use twrp to install your stock boot.img to your boot partition.. If you have a backup of your boot image then restore that. Either way you will be OK.
Sent from my Ascend Mate 2 using Tapatalk

---

SHM said:
If the partition table between KK and LP does not vary on your device then it will be fine.
As for flashing a boot image to your boot partition via twrp, this will not brick your device. Worse case, device doesn't get past the bootloader or the boot animation. In this case, use twrp to install your stock boot.img to your boot partition.. If you have a backup of your boot image then restore that. Either way you will be OK.
Sent from my Ascend Mate 2 using Tapatalk
Click to expand...
Click to collapse
IT WORKS!!!
Flashed a stock boot.img using TWRP to be safe, was fine. Patched the ramdisk again, created a new patchedboot.img using the binary I pulled from the P607T sources, crossed my fingers and flashed it with TWRP, the device booted successfully. There was a SEAndroid Not Enforcing; Set Warranty Bit Kernel message while it booted, but I don't care about Knox. Once I confirmed that it booted and worked alright, back to recovery, flashed SuperSU Beta 2.52, rebooted, and I HAVE ROOT!!!
No idea why Odin would fail to flash, but confirmed working with TWRP. Do you know what the policy is on me creating a thread and uploading my patchedboot.img for others to use? I am no developer, and I have no idea if the rules prohibit me from putting this up. I do know though that not everybody is going to go through this whole manual process to get root, and too many are resorting to permissive kernels to get root. Ideally, I will also repeat this process is someone sent me a P605 boot.img, so they too can have root with stock kernel. Just not sure where this thread should go, and if I can even make one.
In anycase, THANK YOU SO MUCH BOTH OF YOU FOR TAKING THE TIME TO WALK ME THROUGH THIS! Much appreciated

---

Glad you got it working. If you want to post the image, I'd suggest posting in the dev section for the device. (If it's just a repack of the stock kernel, don't use the original dev...) Yes, it is allowed to do that. Being that you aren't recompiling anything, there's no need for you to post any source code (but it might be nice to link to the source from samsung's site. We all know that Samsung doesn't update that anyway.)
Take care
Gary

---

Thanks for the suggestions on how and where to post. I think I will take the time to write out a decent tutorial and then post it with this image in the dev forum. Im sure the P605 users will also want to do this with theirs, so they are not stuck with an unsecure kernel!

---

karthikrr said:
Thanks for the suggestions on how and where to post. I think I will take the time to write out a decent tutorial and then post it with this image in the dev forum. Im sure the P605 users will also want to do this with theirs, so they are not stuck with an unsecure kernel!
Click to expand...
Click to collapse
Good luck with your future endeavors. I'm currently fighting with sepolicy right now with my CM13 builds lol. Whole other battle right there haha.
Sent from my Ascend Mate 2 using Tapatalk