Related
Edit: bootloop, partitions are not mounting.
nagato.fm said:
I'm trying to port an X5PRO rom to regular X5 and facing an issue of unworking wi-fi and USB mass-storage. All data I have: it's all right with IMEI, wi-fi and bluetoth MAC's are missing, serial number is missing, wi-fi toggle in settings is inactive (I mean it can't be turned on and if I try to turn it on directly from wi-fi settings it says "an error occured" and goes inactive again), when I'm connecting my phone to computer and trying to turn on storage I get message of dismounting SD card and the storage stays turned off.
I've already tried to change the kernel (this ROM is running 3.0.8 PRO kernel and I've used Dzo's v5.0u17 kernel) and it haven't fixed my problems. Changing of /system/libs/hw/ to the Aurora's resulted in non-bootable rom.
Have you any ideas of how to solve it? Or is there any threads about x5pro to non-pro porting I could miss? (I've tried to google anything about problems with my port and about porting from U8800PRO and found... nothing)
Click to expand...
Click to collapse
I have no ideal to give you because i'm not a DEV, but in the whole 4rum, you can easy find out the solution to help you.
http://forum.xda-developers.com/showthread.php?t=1941239
Those so called tutorials are pretty much useless, they will help you get the base on, but no more.
So, since U8800+ has a different Wi-Fi, you should first replace /system/lib/libhardware_legacy.so, /system/bin/wpa_supplicant with the dzo ones. Then copy over the /system/lib/modules directory, it contains Wi-Fi modules needed.
If it does not work out, try to modify the init.huawei.rc or init.rc and replace service wpa_supplicant and related configs with dzo ones. Note that you will have to modify boot.img, because it contains the init files. So use a boot.img unpacker, modify it, then repack it again.
Try to get me the logs too .
Blefish said:
Those so called tutorials are pretty much useless, they will help you get the base on, but no more.
So, since U8800+ has a different Wi-Fi, you should first replace /system/lib/libhardware_legacy.so, /system/bin/wpa_supplicant with the dzo ones. Then copy over the /system/lib/modules directory, it contains Wi-Fi modules needed.
If it does not work out, try to modify the init.huawei.rc or init.rc and replace service wpa_supplicant and related configs with dzo ones. Note that you will have to modify boot.img, because it contains the init files. So use a boot.img unpacker, modify it, then repack it again.
Try to get me the logs too .
Click to expand...
Click to collapse
The problem is that I've changed the kernel using abootimg package in Ubuntu because none of the scripts for unpacking/repacking boot.img found on this forum worked for me, also I couldn't unpack ramdisk so I think I can't modify init.rc at this moment. I'll try to get some logs and do all that you've mentioned.
Also there is another problem: no mobile network at all. When I turn on the phone the indicator goes gray and nothing seems working (can't phone someone and etc.). When trying to change mobile operator via settings I get a VERY strange menu asking me for PIN code (I actually don't have one - I've disabled it years ago).
Also I need to ask for some tutorials or knowledge bases about how android works and how core parts of android work (I mean EVERYTHING I can get) because I actually don't know ANYTHING about android and there's no noob-friendly tutorials or FAQ's over the internet. I've checked xda-university and it didn't helped either.
Anyway thanks for your help, Blefish!
After following your instructions system hangs on boot. When first flashed it started to "updating android:setting applications..." and then it rebooted. Then it said "updating... 1 of 1" and another reboot. Seems like framework-res isn't starting because it hangs on bootanimation and hardware buttons lights are constantly flashing. Installing SDK now, will try to get some logs.
Try to do it step-by-step so first replace one thing, reboot, then try another. That will help us understand what makes the phone hang.
For modifying kernel or init.rc I attatched boot.img unpacker-repacker with README, check it out. I am not sure if you need a Linux box for it, but I use that tool and it works well.
MIUI-XJ (my ROM) is a ported u800pro ROM. But it is a gingerbread ROM.
First of all,you need change all init files in /system. You can found this files in system/etc (example;init.qcom.wifi.sh).And I think the mass stroage problem causing by init.qcom.usb.rc (It can found in boot.img) but I'm not sure.
You should change gralloc files for a better GPU performance. It can found in systen/lib/hw. I think You don't need change other hw files.
u8800 needs system/bin/netd - system/lib/modules/*(anything in this folder) - system/bin/wpa_supplicant - system/lib/liboem_rapi.so - system/lib/libreference-ril.so - system/lib/libhardware_legacy.so - system/etc/init.qcom.wifi.sh - system/etc/firmware/wlan/*(anything in this folder) for turn on WiFi
and also u8800 needs system/etc/init.qcom.bt.sh - system/bin/hci_qcomm_init - system/bin/qmuxd (I'm not sure about this file) - system/bin/sdptool - system/bin/hciattach for turn on BT
And also,you need change init.rc and init.huawei.rc files in boot.img for turn on WiFi and BT.
forumber2 said:
MIUI-XJ (my ROM) is a ported u800pro ROM. But it is a gingerbread ROM.
First of all,you need change all init files in /system. You can found this files in system/etc (example;init.qcom.wifi.sh).And I think the mass stroage problem causing by init.qcom.usb.rc (It can found in boot.img) but I'm not sure.
You should change gralloc files for a better GPU performance. It can found in systen/lib/hw. I think You don't need change other hw files.
u8800 needs system/bin/netd - system/lib/modules/*(anything in this folder) - system/bin/wpa_supplicant - system/lib/liboem_rapi.so - system/lib/libreference-ril.so - system/lib/libhardware_legacy.so - system/etc/init.qcom.wifi.sh - system/etc/firmware/wlan/*(anything in this folder) for turn on WiFi
and also u8800 needs system/etc/init.qcom.bt.sh - system/bin/hci_qcomm_init - system/bin/qmuxd (I'm not sure about this file) - system/bin/sdptool - system/bin/hciattach for turn on BT
And also,you need change init.rc and init.huawei.rc files in boot.img for turn on WiFi and BT.
Click to expand...
Click to collapse
Thanks a lot! Will try it all now!
Okey, now it's a bootloop on splash screen.
Edit: a bootloop was caused by some error in boot.img repack. Will try to repack it again now.
How to enable ADB when booting? On Aurora I could get kernel messages via ADB using adb shell cat /proc/kmsg. And now I really miss this feature.
Okey, great news! Wi-fi turned on, but the phone will fastreboot if I turn it off (framework crash I think) and wont turn on again until a full reboot. Also it isn't really working: no networks found.
No changes at all except Aurora kernel + setprop persist.sys.wifimac mac_param in terminal. After that wi-fi turned on, but even with that prop I have no wi-fi mac.
From that I understand all my problems are from some RIL or hardware libs that don't load or load with mistakes. So I need to know what exactly it can be and what libs are for what. Also I think it can be because of unedited init.rc's in ramdisk so I need to know what to edit in them. I've tried to look through them but I don't understand anything in it.
nagato.fm said:
Okey, great news! Wi-fi turned on, but the phone will fastreboot if I turn it off (framework crash I think) and wont turn on again until a full reboot. Also it isn't really working: no networks found.
No changes at all except Aurora kernel + setprop persist.sys.wifimac mac_param in terminal. After that wi-fi turned on, but even with that prop I have no wi-fi mac.
From that I understand all my problems are from some RIL or hardware libs that don't load or load with mistakes. So I need to know what exactly it can be and what libs are for what. Also I think it can be because of unedited init.rc's in ramdisk so I need to know what to edit in them. I've tried to look through them but I don't understand anything in it.
Click to expand...
Click to collapse
Which ROM are you fixing? Isn't CM10?
Nope, it's some desire z jb rom.
Code:
[email protected]:~# adb shell dmesg
- exec '/system/bin/sh' failed: No such file or directory (2) -
That's what I'm getting now. Already tried to fix this issue with some methods from google, no results. Even tried to adb-push bash from 4pda to system/bin and make symlinks, no results. Phone is in bootloop. Any ideas?
P.S.: sh is actually in both xbin and bin, so the problem is somewhere in the boot.img, right?
Have tried all kind of sorcery, still bootloops and exec '/system/bin/sh' failed: No such file or directory (2). Don't know why this is happening. Either /system mounts on boot in some wrong poing or init.rc is completely messed up. But I've checked everything connected to mounting partitions in all init files (except binaries) and gained nothing. I really need some explanation of what are these files for and what they do and what they MUST do.
If someone can give me answers or advices, please, do it now. Because all my ideas are over and I simply don't know now what to do.
EDIT: with aurora boot.img (no changes at all) results are the same except the message in terminal is now "/system/bin/sh: no such tool"
The system/bin/sh error is caused by not mounting /system properly. Check the init.rc files, it could also be in init.emmc.rc if it's a CM rom.
Find out where the on emmc-fs trigger is; if you can't find it, add it into one of the init.rc files.
Code:
on emmc-fs
# mount mmc partitions
wait /dev/block/mmcblk0p12
mount ext4 /dev/block/mmcblk0p12 /system rw barrier=1
wait /dev/block/mmcblk0p13
exec /system/bin/e2fsck -p /dev/block/mmcblk0p13
mount ext4 /dev/block/mmcblk0p13 /data nosuid nodev barrier=1 noauto_da_alloc
mount ext4 /dev/block/mmcblk0p6 /cache nosuid nodev barrier=1
Not sure that I am following this thread properly. I am just starting out with android devel in Fedora. Have you recompiled the WLAN module?
eyeconic said:
Not sure that I am following this thread properly. I am just starting out with android devel in Fedora. Have you recompiled the WLAN module?
Click to expand...
Click to collapse
Nope, I have no proper skills for that, sorry.
I still need some information
Mostly completely rewrote init. files and still no results.
According to this: (http://forum.xda-developers.com/showpost.php?p=30458679&postcount=1)
The Android Boot Process
Bootloader – In HD2’s case, Magldr or cLK – loads the kernel based on how you have configured the phone.
Kernel – The kernel (zImage) is loaded into RAM along with an initial ramdisk (initrd.gz), which initializes various devices (IO, memory, GPU, etc.), interrupts, and mounts the root file system (/). After this, the first user-space process called init is started.
Init – this is a binary file that is contained within the initrd.gz. The init binary processes init.rc and init..rc , along with other .rc files that are called by these two .rc files. Some of the key functions (from this thread’s perspective) in the order of their initialization/ execution are:
The init process follows the instructions in the init.rc and init.xyz.rc files and creates empty directories including /data. It then mounts the storage devices (partitions in the internal NAND (MTD)) to these empty directories. The NAND partition for system is mounted to /system, followed by the partitions specified for data, cache, etc. The directories for dalvik-cache (/data/dalvik-cache) are also created by the init process after mounting the specified device to /data.
The init process then starts various services including adb, service manager, Volume Daemon (vold) for media like SD Card (FAT partition). Most importantly, the zygote service which initiates the Dalivk-Cache is loaded in this sequence.
As we all know, Android is based on Linux. The boot sequence described above is common for all Linux machines – until the zygote stage. Core Android file like core, framework, services, IME, policy, etc. are executed from the Dalvik-Cache and hence Initialization of the Dalvik Cache is pretty much where Android comes into the picture
The sysinit/ run-parts part, which runs scripts from the /system/etc/init.d later the Zygote stage. No matter how this is done, Android has already started loading by the time the boot process comes to executing scripts in /system/etc/init.d
Click to expand...
Click to collapse
Click to expand...
Click to collapse
the error is in mounting nand partitions, but how can it past to starting adb when it fails on mounting system partitions? I don't understand this.
I've been tinkering with building aosp framework and kernel from source. I've got it loaded and running on my N7. I've made some changes to an xml file, and the subsequent build resulted in only a new system.img file being generated. Is there any way to "install" the system.img file without wiping the system area first? Or is "fastboot flash system system.img" the only way to update the system area of the ROM? I don't want to have to use Recovery to install gapps and supersu again if I can avoid it.
Try mounting the .IMG file into a folder you created with
sudo(or su) mount -o loop ~/system.img /path/to/created/folder
It may mount it and you should be able to get what you want out of the file and then just replace the individual files and reboot or flash them by themselves in a .zip.
di11igaf said:
Try mounting the .IMG file into a folder you created with
sudo(or su) mount -o loop ~/system.img /path/to/created/folder
It may mount it and you should be able to get what you want out of the file and then just replace the individual files and reboot or flash them by themselves in a .zip.
Click to expand...
Click to collapse
I tried everything I could think of including specifying all different types of filesystems including iso9660 and nothing recognizes the image. I tried it on my Ubuntu 12.04 machine as well as the tablet, no success, I guess I'll just have to flash it with fastboot.
There is ways to do it. Aosp used to include the necessary tools to do it, but I haven't really cloned aosp source since gingerbread so I can t remember exactly where or if they're still there(if I do some digging I can figure it out but you may already have flashed. I'll still look into it cause it may be of use to others).
Maybe try this in the future
Here's a binary that should work, make it executable first--
http://db.tt/OZnlRJ4L
./simg2img system.img output.img
Then
mkdir systest(make this folder anything you want)
mount -o loop output.img systest(or whatever you made the folder above)
I haven't tested this but I may when I get a chance.
Way cool man, it works. I was able to mount the output IMG without issue. . :good: :good: :good:
Sent from my aosp N7 JSS15Q w/A029 TouchScreen firmware
As anyone who has tinkered around with android and linux will know there are tons of different security mechanism in place or even general lacks of features that dissallow the ability to start linux on boot instead of android. One of the features that will make booting our own OS easier is the use of RAM-Disk.
First we must consider the way that Android boots when we turn on our devices currently, The system powers on and depending on button combination or system state the bootloader decides where to start booting. In the case of my Samsung SM-T520 this means that I have 2 partitions that I can access in order to interrupt the Android boot sequence and boot instead into an OS of my choosing. Those two partitions are Labelled as Boot and Recovery and reside at /dev/block/mmcblk0p9 and /dev/block/mmcblk0p10, but it is not as simple as simply mounting the partition and modifying the contents, we have to Modify the stock Kernel as well a little bit to be able to achieve better performance in the Linux side of things.
In the case of the SM-T520 I have compiled a preconfigured Kernel for this and will upload it below, But for those of you who do Not have the SM-T520 I will upload a sample Kernel config that you can base your own off of.
That settles the Kernel side of things but there is still 1 other part missing, If we just modify the Kernel then we are really not making any difference so we must edit...
The Initial RAMDISK
The Initramfs as many know it is glued to the back end of our kernel zImage that we get from compiling our own kernel, and includes a few small files to set up the initial environment for Android, or our Guest OS to finish booting from. This means that we have a pretty good base to start out with booting Linux. We simply have to grab this base and modify to our will.
So to start I took an image of /dev/block/mmcblk0p9 using dd from recovery like so ‘dd if=/dev/block/mmcblk0p9 of=sdcard/mmcblk0p9.img’ and copied the file onto my linux development machine. I then used umkbootimg passing the file to it as input in order to deconstruct that file into the zImage and the Ramdisk. i then copied the Ramdisk which will be in a file called initramfs.cpio.gz into a new folder on my computer and ran unpack_ramdisk on it to get to the nitty gritty inside which is what we need. and i promptly threw out the old initramfs.cpio.gz and kept only the ramdisk folder. This allowed me to modify the “scripts” inside of it so that it would boot Linux by mounting the linux install location as / then telling if to boot using the init function that linux already has. while I was testing i decided to leave the android install mounted essentially, what that means is that the android install hides away in the filesystem inside the linux install if we ever want to boot Android into a chroot Jail of its own.
That is possible because Android’s file system and the linux filesystem being used are the same structure, but at different locations /system being empty for the Android system to occupy. This is all fine, but where do we put linux? The short answer, Wherever the heck ya want to!
My answer was to put the linux install onto my MicroSD card at /dev/block/mmcblk1p1 so that i could write an addition to the logic inside the Ramdisk to start linux or android based on whether the SD card was inserted at boot.
More yet to follow
Interesting read. It will be great to see where this leads.
Very interesting. If this develops in would love to test.
Hei @DJHenjin1 , any update on this? I would love to see ubuntu running native on my SM-T520, especially now that it is sure we are not going to get any firmware update. Anyway, nice job! Thanks
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