MyMinds_Kernel_Swap
===================
Based on AnyKernel, but pretty much rebuilt in every way so that it will actually work. So, many thanks to Koush for the idea.
The Idea and What It Does...
=======================
Some but not all of this script has been snippets here and there from ArchiKitchen and DSIXDA Kitchen.
This has allowed me to formulate a zip as such without the need to technically build from scratch saving me LOADS OF HOURS.
It currently uses my static compiled mkbootimg, unmkbootimg, and mkbootfs binaries to allow editing, and rebuilding of the boot.img.
Some serious modifications were made to get this to work successfully with MUCH DEBUGGING. If you change something and it breaks another function then that is on you!
# IT IS CURRENTLY STABLE!
1. It will pull your current boot.img using dd.
2. It will search for the Android! header in the boot.img and remove the unnecessary junk before it if needed to.
3. It will split the boot.img in to the kernel and ramdisk.
4. It will unpack the contents inside the ramdisk.
5. It will modify the default.prop file giving you insecure ADB. If you already have it then this will not affect you.
6. It will modify the init.rc file to give support for init.d. If you already have it then this will not affect you.
7. It will write to sysinit and install-recovery.sh for the completion of init.d support. If already done, then this will not affect you.
8. It will make the init.d folder under /system/etc on your device with required permissions.
9. It will place an init.d script to test to see if init.d is fully working. If it works, you will find a file called, HAS_INIT, located in the /dev directory of your device.
10. It will swap out the original kernel with a new prebuilt kernel upon rebuilding the new boot.img
11. It will repack you a new ramdisk using mkbootfs to be applied to your new boot.img upon rebuilding it.
12. It will remove your old modules and push your new modules that came with your new prebuilt kernel.
13. It will write your new boot.img to your boot partition using dd.
14. Hopefully, more to come!
MAKE SURE YOU CHANGE...
=======================
"$BOOT_PARTITION" ACCORDING TO YOUR DEVICE BEFORE USING THIS SCRIPT!!!!!!
How to use it...
==============
1. Place your prebuilt kernel in the prebuilt folder and insure it is named, zImage.
2. Place kernel modules in the modules folder.
3. Zip, and flash in TWRP recovery.
If you have any suggestions then let me know. My ears are open to them.
https://github.com/ModdingMyMind/MyMinds_Kernel_Swap
Sent from my C525c using Tapatalk
I've just got a new Samsung Galaxy TAB A 7.0 LTE SM-T285, For some reason I can't seem to find any resources for this hardware yet in this forum, anyone know where I could find one? I'll try to find out if the current methods (custom recovery and root) for other tab versions work on this.
CUSTOM ROMS
============
Android 5.1.1 Lollipop (Stock)
Tinker V5 Edition based on the Samsung Stock Rom SM-T280/T285
Android 6.0 Marshmallow
Cyanogenmod 13 for the SM-T285 Only
OMNIRom for the SM-T285 Only
Android 7.1 Nougat
Cyanogenmod 14.1 for the SM-T285 Only (Experimental, things are broken, depcrated in favor of LOS 14.1)
LineageOS 14.1 for the SM-T285 Only
Other Operating systems
Porting for Sailfish OS is currently in progress for the SM-T285, stay tuned
TWRP RECOVERY AND ROOT
=======================
TWRP is available for both the T280 and T285. You should find the relevant threads in this Galaxy Tab A forum.
If you want to root stock, easiest way is to install TWRP and go for SuperSU. Please see the TWRP threads for SM-T280/T285 on how to root after TWRP is installed.
KERNEL
======
Custom kernel with working sources for the SM-T285 can be found Here
DEVELOPMENT
============
If you want to build LineageOS 14.1 on your SM-T285 LTE device, you can use this manifest, not that this is still a work in progress:
https://github.com/jedld/android.git
UPDATE 10/06/2016
================
After a couple of weeks of trial and error and tinkering, I've been able to compile a kernel for the SM-T285 from source and so far it seems to work flawlessly!
Screenshot here: http://imgur.com/a/HRgsq
link to my kernel sources here: https://github.com/jedld/kernel_samsung_gtexslte.git
You can also thank samsung for giving us a "broken by default" kernel source. I had to mix and match defconfigs from their other kernel releases just to make this thing work. Download modified boot.img here:
http://forum.xda-developers.com/galaxy-tab-a/development/kernel-galaxy-tab-7-0-2016-lte-sm-t285-t3474967
UPDATE 09/20/2016
================
This device is now ROOTED!
http://forum.xda-developers.com/galaxy-tab-a/help/resources-samsung-galaxy-tab-7-0-2016-t3431022/post68777842#post68777842
Download Pre-rooted Tinker Edition V5 in this thread: Tinker Edition Thread
Post Root Post Mortem Analysis for the SM-T285 (09/21/2016)
=========================
Q: How were you able to find root? What did you do?
A: Surprisingly the SM-T285 bootloader isn't actually locked like we thought it was (Once you OEM unlock of course and disable FRP). The bottomline is that
we simply needed patches to mkbootimg to properly package a boot image for this device as there were additional fields and sections not found on a normal boot image. There were even minor breaking difference between the tab 4 and the boot image for this device.
Q: I thought the bootloader was locked?? Why did it take so long?
A: I blame it on the really vague errors the bootloader shows when loading an improperly packaged boot image. What helped was my faith to open up a hex editor when I needed to, and really look at the stock images and the images we were making. What really pushed me to investigate further was the fact that I was able to make a really small modification to the ramdisk and use the abootimg -u update function instead of the create options.
Q: So the bootloader doesn't really check the image?
A: Yup, The bootloader doesn't do any check. I haven't checked if that is the case for the recovery partition though. Even without the SELINUXENFORCE headers at the end it still continues like other samsung devices do.
Q: So the mkbootimg patches are all that we need?
A: Yup, if you have CM, AOSP build env ready you can simply add the modified mkbootimg to system/core:
https://github.com/jedld/degas-mkbootimg/commit/b63ae38e2ab7040cc7ddaef777652a56b2e48322
Sample usage below:
Code:
degas-mkbootimg -o boot.img --base 0 --pagesize 2048 \
--kernel boot.img-zImage --cmdline "console=ttyS1,115200n8" --ramdisk boot_kitchen/boot.img-ramdisk-new.gz --dt boot.img-dt
Next challenge will be getting Cyanogenmod on this device as well as TWRP.
You won't because it has a locked bootloader, therefore not currently rootable and certainly no custom recovery.
jaritico said:
any idea to unlock bootloader?
Click to expand...
Click to collapse
Not unless Samsung provides one.
jaritico said:
any idea to unlock bootloader?
Click to expand...
Click to collapse
Probably no hope for root. the PIT, boot and recovery are basically untouchable, selinux enforcing enabled also does not help. You can still debloat and customize the system partition though:
http://forum.xda-developers.com/android/development/guide-samsung-galaxy-tab-7-0-sm-t285-t3438296
I'm working on getting CM 12.1 to run on this device.
jedld said:
Probably no hope for root. the PIT, boot and recovery are basically untouchable, selinux enforcing enabled also does not help. You can still debloat and customize the system partition though:
http://forum.xda-developers.com/android/development/guide-samsung-galaxy-tab-7-0-sm-t285-t3438296
I'm working on getting CM 12.1 to run on this device.
Click to expand...
Click to collapse
Yes at least the saving grace is that Samsung left Dm-verity off for this device.
If only they'd have left out the root restriction in the kernel too we'd have a rootable device.
I have an idea for this that I haven't tried yet.
Basically Samsung sends out security Policy updates via OTA, they recently released an SEPOLICY update to most devices breaking root. Chainfire patched this.
As this policy is stored in DATA and over rides the one in the boot.img it may be possible to use a patched SEPOLICY by creating a flashable DATA image with the patched SEPOLICY thereby removing the SElinux root restriction.
I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.
I have yet to try this out.
I think it would be difficult to get CM running as the kernel may need some patches and as we know that can't be touched.
ashyx said:
Yes at least the saving grace is that Samsung left Dm-verity off for this device.
If only they'd have left out the root restriction in the kernel too we'd have a rootable device.
I have an idea for this that I haven't tried yet.
Basically Samsung sends out security Policy updates via OTA, they recently released an SEPOLICY update to most devices breaking root. Chainfire patched this.
As this policy is stored in DATA and over rides the one in the boot.img it may be possible to use a patched SEPOLICY by creating a flashable DATA image with the patched SEPOLICY thereby removing the SElinux root restriction.
I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.
I have yet to try this out.
I think it would be difficult to get CM running as the kernel may need some patches and as we know that can't be touched.
Click to expand...
Click to collapse
I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.
I have yet to try this out.
Click to expand...
Click to collapse
Would probably need to brush up on se policies in linux. If there are already files available that I just need to flash over to /data I can try it out and also a means to test it if it works.
I've created a petition here:
https://www.change.org/p/samsung-unlock-the-bootloader-for-the-samsung-galaxy-tab-a-7-0-2016?recruiter=286570213&utm_source=petitions_show_components_action_panel_wrapper&utm_medium=copylink&recuruit_context=copylink_long
Not sure if samsung is the type that listens to this sort of thing though.
ashyx said:
As this policy is stored in DATA and over rides the one in the boot.img it may be possible to use a patched SEPOLICY by creating a flashable DATA image with the patched SEPOLICY thereby removing the SElinux root restriction.
I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.
I have yet to try this out.
Click to expand...
Click to collapse
I made an attempt to patch sepolicy using data however all I got in the logs was
Code:
E/SELinux ( 733): Function: fileToArray, File Open Unsuccessful:
E/SELinux ( 733): Function: getVersionhash, signature is NULL
I/SELinux ( 733): Function: selinux_init_verify_sepolicy, getVersionhash return false
E/SELinux ( 733): Function: VerifyPolicy , selinux_init_verify_sepolicy is failed
So far I have no indication that my patch worked
Code:
sepolicy-inject -s shell -t system -c file -p read -P sepolicy -o sepolicy
The error above only comes up if I place sepolicy in /data/security and sepolicy_version in /data/security/spota
sha256 hashes were also updated in the version file so I'm not sure what I'm missing.
If I could have a copy of a samsung ota that actually updates the policies I can probably have better direction
jedld said:
I made an attempt to patch sepolicy using data however all I got in the logs was
Code:
E/SELinux ( 733): Function: fileToArray, File Open Unsuccessful:
E/SELinux ( 733): Function: getVersionhash, signature is NULL
I/SELinux ( 733): Function: selinux_init_verify_sepolicy, getVersionhash return false
E/SELinux ( 733): Function: VerifyPolicy , selinux_init_verify_sepolicy is failed
So far I have no indication that my patch worked
Code:
sepolicy-inject -s shell -t system -c file -p read -P sepolicy -o sepolicy
The error above only comes up if I place sepolicy in /data/security and sepolicy_version in /data/security/spota
sha256 hashes were also updated in the version file so I'm not sure what I'm missing.
If I could have a copy of a samsung ota that actually updates the policies I can probably have better direction
Click to expand...
Click to collapse
Finally found a way to patch the kernel on this device. Stay tuned...
jedld said:
Finally found a way to patch the kernel on this device. Stay tuned...
Click to expand...
Click to collapse
Turns out I was just able to modify files in the boot.img, though when I try to update the sepolicy itself, it won't boot.
jedld said:
Turns out I was just able to modify files in the boot.img, though when I try to update the sepolicy itself, it won't boot.
Click to expand...
Click to collapse
Can you at least explain a bit further?
What modifications allow you to create a boot able image?
How have you overcome image signing?
Only way I can think of is hex editing the signature, however I was under the impression this was crc based.
ashyx said:
Can you at least explain a bit further?
What modifications allow you to create a boot able image?
How have you overcome image signing?
Only way I can think of is hex editing the signature, however I was under the impression this was crc based.
Click to expand...
Click to collapse
Yeah I was able to flash a modified boot.img using heimdall, turns out that you just need to use abootimg -u boot.img -r yourmodifiedramdisk so that you don't overwrite the SELINUXENFORCE headers appended at the end of the boot.img file, it appears the bootloader only checks for the presence of those headers but does not actually compute the sig.
Modifying ramdisk works, haven't tried modifying the kernel itself.
I tried to modify the sepolicy files after using sepolicy-inject but it throws a KERNEL not SEnforced error. I am not certain if this is just a blanket error if the kernel doesn't boot due to modifying the policy files incorrectly or if there is legit checking going on. Nevertheless I am able to modify the init.rc files now.
jedld said:
I tried to modify the sepolicy files after using sepolicy-inject but it throws a KERNEL not SEnforced error. I am not certain if this is just a blanket error if the kernel doesn't boot due to modifying the policy files incorrectly or if there is legit checking going on. Nevertheless I am able to modify the init.rc files now.
Click to expand...
Click to collapse
Continued checking it out. So even though I can modify the ramdisk, I am unable to add more than 1000 - 2000 bytes before setting off the SEAndroid enforce error on bootup. Might be some headers on the boot.img that I fail to update when the ramdisk size gets bigger. Trying to modify the sepolicy in any way even if there is minimal change in size prevents it from booting. I have no idea what is checking it, I'll try to hexedit and see what happens.
jedld said:
Continued checking it out. So even though I can modify the ramdisk, I am unable to add more than 1000 - 2000 bytes before setting off the SEAndroid enforce error on bootup. Might be some headers on the boot.img that I fail to update when the ramdisk size gets bigger. Trying to modify the sepolicy in any way even if there is minimal change in size prevents it from booting. I have no idea what is checking it, I'll try to hexedit and see what happens.
Click to expand...
Click to collapse
So I used a hexedit on the sepolicy file and was able to modify one byte of it effectively changing its sha256sum... and it worked. So the sepolicy file CAN be changed, however current sepolicy-inject and supolicy tools does something to it that trips it, looks like samsung has again added a proprietary modification sepolicy format.
I've never known a kernel not boot due to the kernel not SEANDROID enforcing warning.
It's a meaningless warning and easily bypassed.
However this is on bootloader unlocked devices.
So just let me get this straight, you have been able to repack the boot.img with modifications to the ramdisk then force flash it via Heimdall and it still boots?
ashyx said:
I've never known a kernel not boot due to the kernel not SEANDROID enforcing warning.
It's a meaningless warning and easily bypassed.
However this is on bootloader unlocked devices.
So just let me get this straight, you have been able to repack the boot.img with modifications to the ramdisk then force flash it via Heimdall and it still boots?
Click to expand...
Click to collapse
yup. that's correct. I'll post my modified boot.img in a while
jedld said:
yup. that's correct. I'll post my modified boot.img in a while
Click to expand...
Click to collapse
note that using the update only method of abootimg "abootimg -u boot.img -r xxxxxx " is the only one that works for repacking the ramdisk. Trying to build the boot.img from scratch using any other method has so far failed for me.
Here is a flashable boot.img for the SM-T285.
It contains the following modifications to the ramdisk:
a file at /this_device_is_owned
and a modified init.rc that creates a /tmp folder
jedld said:
Here is a flashable boot.img for the SM-T285.
It contains the following modifications to the ramdisk:
a file at /this_device_is_owned
and a modified init.rc that creates a /tmp folder
Click to expand...
Click to collapse
now managed to patch sepolicy using chainfire's supolicy tool. needed to use a customized mkbootimg due to changes in the Tab A image format for this. now attempting to root the device... wish me luck
As the title says, I know it's asking for a lot but im just wondering.
Also mean to say exefat
su
setenforce 0
Ptmaroct said:
su
setenforce 0
Click to expand...
Click to collapse
Yea but I have to type that in on every boot, and the init.d script doesn't work
unpack your boot.img,
add
Code:
androidboot.selinux=permissive
to your kernel cmdline,
pack your boot.img again,
flash boot.img to your boot partition.
yangyangnau said:
unpack your boot.img,
add
Code:
androidboot.selinux=permissive
to your kernel cmdline,
pack your boot.img again,
flash boot.img to your boot partition.
Click to expand...
Click to collapse
Interesting, I'll try that. But also doesn't each MIUI update update the boot.ing?
I see that things like the new su and magisk does some boot.ing unpacking, think that I can modify their script to add in that selinux=permissive line while it's unpacked?
after unpacking the boot.img a see no option like that
and also is their some kind of way to get exfat support?
So in this guide or tutorial i'll show you how to patch boot.img so it doesn't fails to boot.
what you'll need
Python (We're using a python script to unpack/repack)
This python script https://github.com/liudongmiao/bootimg
Text editor (notepad++) for windows is a good thing
Patience
Now if you have python installed navigate to the folder where your bootimg.py & boot.img exist
now open cmd or terminal depending on what system you're using. and enter:
python bootimg.py --extract-bootimg
python bootimh.py --extract-ramdisk
Now we need to disable dm-verity and such
To disable system check change: ro,barrier=1 wait,verify > ro,barrier=1 wait
it is recommended to do this to all partitions u want to be able to modify later.
now you can also remove dm-verity executable and is not needed and it most likely will cause your boot.img to fail.
There's probably need to patch se policy file as well so you could use phh zip to do this.
And thats it. Post 2 is to add superuser access but it'll be later
How to swap from phh to chainfire supersu
Open init.environ.rc and add
export PATH /su/bin:/sbin:/vendor/bin:/system/sbin:/system/bin:/su/xbin:/system/xbin
Above bootlogo
Now download the two zips and extract su folder to root of ramdisk
And the sbin to sbin folder but don't remove any files!
Now if u have trouble with remount system as rw you need to edit the fstab and remove the verify on its partition. Now just repack ramdisk and then repack boot and you should be done
LastStandingDroid said:
So in this guide or tutorial i'll show you how to patch boot.img so it doesn't fails to boot.
what you'll need
Python (We're using a python script to unpack/repack)
This python script https://github.com/liudongmiao/bootimg
Text editor (notepad++) for windows is a good thing
Patience
Now if you have python installed navigate to the folder where your bootimg.py & boot.img exist
now open cmd or terminal depending on what system you're using. and enter:
python bootimg.py --extract-bootimg
python bootimh.py --extract-ramdisk
Now we need to disable dm-verity and such
To disable system check change: ro,barrier=1 wait,verify > ro,barrier=1 wait
it is recommended to do this to all partitions u want to be able to modify later.
now you can also remove dm-verity executable and is not needed and it most likely will cause your boot.img to fail.
There's probably need to patch se policy file as well so you could use phh zip to do this.
And thats it. Post 2 is to add superuser access but it'll be later
Click to expand...
Click to collapse
Sorry, which tool do you use in order to extract boot img from UPDATE.APP?
And after unpack and repack ramdisk and boot is it normale that the new boot.img is smaller than the "original" boot.img?
Thanks, I'm trying to patch honor 5c boot image in order to root it.
Huawei Firmware Extractor will unpack the UPDATE.APP.
LastStandingDroid said:
So in this guide or tutorial i'll show you how to patch boot.img so it doesn't fails to boot.
what you'll need
Python (We're using a python script to unpack/repack)
This python script https://github.com/liudongmiao/bootimg
Text editor (notepad++) for windows is a good thing
Patience
Now if you have python installed navigate to the folder where your bootimg.py & boot.img exist
now open cmd or terminal depending on what system you're using. and enter:
python bootimg.py --extract-bootimg
python bootimh.py --extract-ramdisk
Now we need to disable dm-verity and such
To disable system check change: ro,barrier=1 wait,verify > ro,barrier=1 wait
it is recommended to do this to all partitions u want to be able to modify later.
now you can also remove dm-verity executable and is not needed and it most likely will cause your boot.img to fail.
There's probably need to patch se policy file as well so you could use phh zip to do this.
And thats it. Post 2 is to add superuser access but it'll be later
Click to expand...
Click to collapse
In which file we have to edit this line "ro,barrier=1 wait,verify > ro,barrier=1 wait". I have infinix smart 5 x657b. I extracted the boot file and from some instructions on google, I opened fstab file. But there is nothing like that line.
hassansuriya said:
In which file we have to edit this line "ro,barrier=1 wait,verify > ro,barrier=1 wait". I have infinix smart 5 x657b. I extracted the boot file and from some instructions on google, I opened fstab file. But there is nothing like that line.
Click to expand...
Click to collapse
There is a way to remove dm-verity and forceencrypt by just flashing a file in twrp.
[Deprecated] Universal DM-Verity, ForceEncrypt, Disk Quota Disabler [11/2/2020]
Hi all! For the past couple of months, I've been looking into making a more universal solution to disable dm-verity and forceencrypt. Needing to take different zips, modify them for different devices, and then cross your fingers when you switch...
forum.xda-developers.com
CHECK_123 said:
There is a way to remove dm-verity and forceencrypt by just flashing a file in twrp.
[Deprecated] Universal DM-Verity, ForceEncrypt, Disk Quota Disabler [11/2/2020]
Hi all! For the past couple of months, I've been looking into making a more universal solution to disable dm-verity and forceencrypt. Needing to take different zips, modify them for different devices, and then cross your fingers when you switch...
forum.xda-developers.com
Click to expand...
Click to collapse
but there is not any version of twrp recovery for my device. From where should I download it?
hassansuriya said:
but there is not any version of twrp recovery for my device. From where should I download it?
Click to expand...
Click to collapse
I found this "auto twrp recovery porter"
Mediatek (MTK) Auto TWRP recovery porter by Team Hovatek
If you wish to root your Mediatek Android phone, we'd dropped a guide on rooting using Magisk and stock boot.img at https://www.hovatek.com/forum/thread-21427.html , no custom recovery is required. Se
forum.hovatek.com
I dont know if it would work, you should try
You may have to sign up to get the andorid 9 and 10 version of the tool
I've read a couple posts where folks say they're running their stock rom but with a permissive kernel. I can't seem to find said kernel for the sm-t280. It appears to only be available for the t285.
Is a permissive kernel available for the t280 and if so, where might I find it?
Thanks!
The post was made in one of @_mone's threads for an updated TWRP and Magisk, it is an SELinux Permissive Available kernel.
https://forum.xda-developers.com/showpost.php?p=73181495&postcount=59
_mone said:
Under request of quite few users I've uploaded two boot.img that have a kernel able to set SELinux to permissive.
With Magisk-v12.0 ramdisk patches:
T280XXU0AQA4-Magisk-v12.0-SPA-boot.img
With SuperSU-v2.82 ramdisk patches:
T280XXU0AQA4-SuperSU-v2.82-SPA-boot.img
The tag SPA stands for SELinux Permissive Able, this means that the kernel is able to set SELinux to permissive mode but it is not set by default.
You can set it running from terminal:
Code:
su
setenforce 0
If you want to set SELinux to permissive at boot there are few methods that you can use, you can find them here at xda.
I would like to have feedback about these boot.img as I have not tested them because I'm currently running T280XXU0AQF1 with SuperSU in system mode, and it has a different ramdisk, and I rather skip the pain to restore an old backup of AQA4 and test the images with the different root methods.
Kernel source: https://github.com/underscoremone/android_kernel_samsung_gtexswifi/tree/T280XXU0AQA4-SPA
What I have done is just remove the awful CONFIG_ALWAYS_ENFORCE, a proper custom kernel will may arrive in the near future.
Screenshots are taken from my device running T280XXU0AQF1 with the same kernel included in the boot.imgs shared in this post.
Looking forward for your feedback.. if everything is ok I'll add the link to the OP, if it is not I'll restore the old backup, make the tests for you and provide the new boot.img.
Click to expand...
Click to collapse