Recently I have reverse engineered aboot (emmc_appsboot.mbn) from ROM riva_images_V8.5.7.0.NCKCNED_20171025.0000.00_7.1_cn ( en.miui.com/thread-1026306-1-1.html )(because this is my first post and I don't have permission to post outside link, you have to add http in those url), and discovered a way to bypass bootloader lock by using several bugs in Xiaomi customized aboot.
Xiaomi's aboot is based on Qualcomm's little kernel which is open sourced and can be download at source.codeaurora.org/quic/le/kernel/lk/ , so I will use function name inside those source file in discussion below even though some of those function have been modified by Xiaomi.
Relevant function to verify and boot linux is boot_linux_from_mmc, so I'll start from here:
boot_linux_from_mmc: call boot_verifier_init()
boot_verifier_init: set device state to GREEN boot_linux_from_mmc: call verify_signed_bootimg()
verify_signed_bootimg: call boot_verify_image()
boot_verify_image: call read_der_message_length() to get length of signature
boot_verify_image: if length of signature is too large, then boot_verify_image will return false to indicate verification failure
boot_verify_image: otherwise call and return verification result of verify_image_with_sig(inlined)
verify_image_with_sig: set device state to RED if image is not signed by Xiaomi. verify_signed_bootimg: call splash_screen_mmc() to show "The system has been destroyed" if verification failed
verify_signed_bootimg: shoudown device if splash_screen_mmc() succeed, otherwise continue boot boot_linux_from_mmc: call send_rot_command()
send_rot_command: check device state, if it's YELLOW or RED, than boot will failed because it try to read embedded cert which is not initialized by Xiaomi
To successfully bypass bootloader lock we need:
1. make sure device state is GREEN so that send_rot_command won't failed, this can be achieved by making read_der_message_length return a large value to avoid calling verify_image_with_sig.
one way to do this is to append[NOTE1] image with a large length encoded in der (eg. 0x30, 0x83, 0x19, 0x89, 0x64)
2. make sure splash_screen_mmc() failed so that booting process can be continued.
this can be achieved by change the magic number in the header of splash partition from "SPLASH!!" to any other value (eg. "19890604")
Steps to bypass:
0 note that all those steps can be done offline, so no information will send to Xiaomi or anyone
0 in this tutorial I'll demonstrate how to use twrp recovery with locked bootloader
1 using test point to enter EDL mode(will void your warranty!!!)
2 unzip MiFlash, you should see QSaharaServer.exe and fh_loader.exe
3 create a sub folder called "tmp"
4 extract prog_emmc_firehose_8917_ddr.mbn & rawprogram0.xml & splash.img from riva_images_V8.5.7.0.NCKCNED_20171025.0000.00_7.1_cn and put them into "tmp"
5 append a 4k block which begins with 0x30, 0x83, 0x19, 0x89, 0x64 to twrp-3.2.1-0-riva.img then put the resulting file to "tmp" and rename it to "recovery.img"
6 change the first 8 byte in splash.img to "19890604"
7 create "hack_splash.xml" inside "tmp", then copy&paste relevant section from rawprogram0.xml to "hack_splash.xml", the resulting file should look like this:
Code:
<?xml version="1.0" ?>
<data>
<program SECTOR_SIZE_IN_BYTES="512" file_sector_offset="0" filename="splash.img" label="splash" num_partition_sectors="40960" physical_partition_number="0" size_in_KB="20480.0" sparse="false" start_byte_hex="0x14000000" start_sector="655360" />
</data>
8 create "twrp.xml" inside "tmp", then copy&paste relevant recovery section from rawprogram0.xml to "twrp.xml", the resulting file should look like this:
Code:
<?xml version="1.0" ?>
<data>
<program SECTOR_SIZE_IN_BYTES="512" file_sector_offset="0" filename="recovery.img" label="recovery" num_partition_sectors="131072" physical_partition_number="0" size_in_KB="65536.0" sparse="false" start_byte_hex="0x1c200000" start_sector="921600" />
</data>
9 run "QSaharaServer.exe -p \\.\COM10 -s 13rog_emmc_firehose_8917_ddr.mbn -b tmp" to initialize firehose. (replace COM10 with the COM port of you phone, the same as below)
10 run "fh_loader.exe --search_path=tmp --port=\\.\COM10 --sendxml=hack_splash.xml" to flash modified splash
11 run "fh_loader.exe --search_path=tmp --port=\\.\COM10 --sendxml=twrp.xml" to flash twrp recovery
12 done
If you want flash custom ROM, you just need to append[NOTE1] boot.img
NOTE1: append should work in most case, but not always. the corrected place to write 0x30, 0x83, 0x19, 0x89, 0x64 is calculate from image header, it's defined as:
Code:
struct boot_img_hdr
{
unsigned char magic[BOOT_MAGIC_SIZE];
unsigned kernel_size; /* size in bytes */
unsigned kernel_addr; /* physical load addr */
unsigned ramdisk_size; /* size in bytes */
unsigned ramdisk_addr; /* physical load addr */
unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned dt_size; /* device_tree in bytes */
unsigned unused; /* future expansion: should be 0 */
....
};
and then calculate:
Code:
if (hdr->page_size && (hdr->page_size != page_size)) {
page_size = hdr->page_size;
page_mask = page_size - 1;
}
kernel_actual = ROUND_TO_PAGE(hdr->kernel_size, page_mask);
ramdisk_actual = ROUND_TO_PAGE(hdr->ramdisk_size, page_mask);
second_actual = ROUND_TO_PAGE(hdr->second_size, page_mask);
dt_size = hdr->dt_size;
dt_actual = ROUND_TO_PAGE(dt_size, page_mask);
imagesize_actual = (page_size + kernel_actual + ramdisk_actual + second_actual + dt_actual);
imagesize_actual is the place to write
NOTE2: There may be a easier way to enter EDL considering there are so many bug(eg. uninitialized stack variable, buffer overrun, missing bound check) in Xiaomi's modification, but I haven't bothered to check since my goal is achieved.
NOTE3: I suspect other model from Xiaomi may have similar bugs that bootloader lock can be bypassed using this method, but I don't have other phones to confirm my belief.
xaacnz said:
Xiaomi's aboot is based on Qualcomm's little kernel which is open sourced and can be download at source.codeaurora.org/kernel/lk/
Click to expand...
Click to collapse
Did you meant: source.codeaurora.org/quic/le/kernel/lk
abdihaikal said:
Did you meant: source.codeaurora.org/quic/le/kernel/lk
Click to expand...
Click to collapse
Yes, they must have removed the original url.
Code:
[email protected]:~/lk$ git remote show origin | head
* remote origin
Fetch URL: https://source.codeaurora.org/kernel/lk/
Push URL: https://source.codeaurora.org/kernel/lk/
HEAD branch (remote HEAD is ambiguous, may be one of the following):
aosp/master
github-kernel_lk/aosp/master
Remote branches:
APSS.FSM.3.0 tracked
APSS.FSM.3.0.r5.1.1 tracked
APSS.FSM.3.0.r6 tracked
Thank you for the method.
I tried ot and flashed TWRP only, but when I use it to flash custom ROMS, the device wont boot. It will show for a millisecond a picture of penguin and then goes off.
Any ideas??
Thanks
xaacnz said:
Recently I have reverse engineered aboot....
If you want flash custom ROM, you just need to append[NOTE1] boot.img
NOTE1: append should work in most case, but not always. the corrected place to write 0x30, 0x83, 0x19, 0x89, 0x64 is calculate from image header, it's defined as:.
Click to expand...
Click to collapse
You need to patch boot.img inside those ROMS by appending 4k block which begins with 0x30, 0x83, 0x19, 0x89, 0x64
utumno00 said:
Thank you for the method.
I tried ot and flashed TWRP only, but when I use it to flash custom ROMS, the device wont boot. It will show for a millisecond a picture of penguin and then goes off.
Any ideas??
Thanks
Click to expand...
Click to collapse
I am amazed and I dont know how to tell that I thank you. Can you help me? I patch and i flash what?
xaacnz said:
You need to patch boot.img inside those ROMS by appending 4k block which begins with 0x30, 0x83, 0x19, 0x89, 0x64
Click to expand...
Click to collapse
Let's say you want flash https://forum.xda-developers.com/android/development/rom-crdroid-v3-8-5-redmi-5a-t3752066
1 download crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
2 extract boot.img from crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
3 patch the extracted boot.img just like what you did with twrp-3.2.1-0-riva.img
4 put the patched boot.img back in crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
5 flash the modified crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
utumno00 said:
I am amazed and I dont know how to tell that I thank you. Can you help me? I patch and i flash what?
Click to expand...
Click to collapse
Success!!
I tried with Viper ROM though, as it was the one I had already downloaded.
Is the crDroid the one that you suggest?
Have you tried the Oreo one?
I want to thank you one more time for the help.
Greetings from Greece and Colombia.
xaacnz said:
Let's say you want flash https://forum.xda-developers.com/android/development/rom-crdroid-v3-8-5-redmi-5a-t3752066
1 download crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
2 extract boot.img from crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
3 patch the extracted boot.img just like what you did with twrp-3.2.1-0-riva.img
4 put the patched boot.img back in crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
5 flash the modified crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
Click to expand...
Click to collapse
I'm glad I was able to help.
I have used neither of them, so I can't speak for them.
Currently, I'm using a custom build ROM based on LineageOS 15.1
utumno00 said:
Success!!
I tried with Viper ROM though, as it was the one I had already downloaded.
Is the crDroid the one that you suggest?
Have you tried the Oreo one?
I want to thank you one more time for the help.
Greetings from Greece and Colombia.
Click to expand...
Click to collapse
Can you share your own rom base on LOS 15.1? Please
xaacnz said:
I'm glad I was able to help.
I have used neither of them, so I can't speak for them.
Currently, I'm using a custom build ROM based on LineageOS 15.1
Click to expand...
Click to collapse
It's has some custom modifications like swapping back & recent app buttons as I'm left handed, I will try to build a more generic one once I get some free time.
boyrobbie said:
Can you share your own rom base on LOS 15.1? Please
Click to expand...
Click to collapse
@xaacnz
That's a very informative post :good:
Perhaps you can dump the firmware related partitions before and after unlocking the bootloader 'officially', so that it can be easier for us to find (possible) ways to unlock (not bypass) devices based on Xiaomi's implementation of Qualcomm LK.
I'm tagging @osm0sis to take part in the discussion.
xaacnz said:
It's has some custom modifications like swapping back & recent app buttons as I'm left handed, I will try to build a more generic one once I get some free time.
Click to expand...
Click to collapse
Thanks for your kindness, i'm waiting for that
Titokhan said:
@xaacnz
That's a very informative post :good:
Perhaps you can dump the firmware related partitions before and after unlocking the bootloader 'officially', so that it can be easier for us to find (possible) ways to unlock (not bypass) devices based on Xiaomi's implementation of Qualcomm LK.
I'm tagging @osm0sis to take part in the discussion.
Click to expand...
Click to collapse
All stages of bootloader except PBL can be found in fastboot ROM, and PBL can be obtained by using testpoint: https://alephsecurity.com/2018/01/22/qualcomm-edl-1/
The 'official' unlocking process is:
1 submit cpuid which is eFused in soc to Xiaomi.
2 Xiaomi sign the cpuid with it's private RSA key.
3 write the signature to 'devinfo' partition at offset 0xE4.
The verification process is:
1 read the signature from 'devinfo' partition.
2 verify it using public key embedded in aboot.
3 decode the verification result as base64.
4 compare the decoded value with cpuid read from soc, bootloader is unlocked if it's the same.
There are some bugs in verification process:
1 signature is padded using PKCS #1 v1.5, but verification process didn't check plaintext size, thus any plaintext starts with desired prefix will unlock bootloader, effectively reducing the complexity of brute force.
2 any value outside of base64's 64 characters table is treated as 'A', this reduce brute force complexity further.
3 base64 decode will not terminate until '=' is encountered, this create opportunity for buffer overrun, though input(RSA verification result) is hard to control.
4 base64 decode is skipped if first byte of PKCS #1 v1.5 payload is zero, this resulting in comparison of uninitialized stack value to cpuid and maybe exploitable to unlock phone.
I'm shocked that one can write so many bugs in such short function.
xaacnz said:
I'm glad I was able to help.
I have used neither of them, so I can't speak for them.
Currently, I'm using a custom build ROM based on LineageOS 15.1
Click to expand...
Click to collapse
Bro! we have been using the build you uploaded on android file host on may 16 2018. The build you uploaded has all bugs fixed in lineage OS 15.1. Some developers of Redmi 5a(RIVA) has been trying to contact you. They need the source of your ROM and kernel you uploaded on 16 may. Please reply.
xaacnz said:
I'm glad I was able to help.
I have used neither of them, so I can't speak for them.
Currently, I'm using a custom build ROM based on LineageOS 15.1
Click to expand...
Click to collapse
Would you mind sharing your device and kernel sources which you are using? We all have issues with audio which are related to kernel.
It would be great for development on Redmi 5A in general if you could share your sources with the community.
If you don't want to share them for any reason, you could maybe help us fixing the speaker bug on our sources: https://github.com/redmidevs/android_kernel_xiaomi_msm8917
boyrobbie said:
Can you share your own rom base on LOS 15.1? Please
Click to expand...
Click to collapse
LordShenron said:
Bro! we have been using the build you uploaded on android file host on may 16 2018. The build you uploaded has all bugs fixed in lineage OS 15.1. Some developers of Redmi 5a(RIVA) has been trying to contact you. They need the source of your ROM and kernel you uploaded on 16 may. Please reply.
Click to expand...
Click to collapse
33bca said:
Would you mind sharing your device and kernel sources which you are using? We all have issues with audio which are related to kernel.
It would be great for development on Redmi 5A in general if you could share your sources with the community.
If you don't want to share them for any reason, you could maybe help us fixing the speaker bug on our sources: https://github.com/redmidevs/android_kernel_xiaomi_msm8917
Click to expand...
Click to collapse
Here it is: lineage-15.1-20180515-UNOFFICIAL-riva.zip
Kernel source: https://github.com/xaacnz/android_kernel_xiaomi_msm8917
I tried to post this ROM on https://forum.xda-developers.com/xiaomi-redmi-5a/development , but my account don't have permission to do that, so I have to post it here in case anyone is interested.
xaacnz said:
Here it is: lineage-15.1-20180515-UNOFFICIAL-riva.zip
Kernel source: https://github.com/xaacnz/android_kernel_xiaomi_msm8917
I tried to post this ROM on https://forum.xda-developers.com/xiaomi-redmi-5a/development , but my account don't have permission to do that, so I have to post it here in case anyone is interested.
Click to expand...
Click to collapse
We have been trying to get around a bug in our builds. Your sources will be a great help for whole riva community Thank you so much.
Thanks
xaacnz said:
Here it is: lineage-15.1-20180515-UNOFFICIAL-riva.zip
Kernel source: https://github.com/xaacnz/android_kernel_xiaomi_msm8917
I tried to post this ROM on https://forum.xda-developers.com/xiaomi-redmi-5a/development , but my account don't have permission to do that, so I have to post it here in case anyone is interested.
Click to expand...
Click to collapse
Thanks again.
xaacnz said:
5 append a 4k block which begins with 0x30, 0x83, 0x19, 0x89, 0x64 to twrp-3.2.1-0-riva.img then put the resulting file to "tmp" and rename it to "recovery.img"
If you want flash custom ROM, you just need to append[NOTE1] boot.img
NOTE1: append should work in most case, but not always. the corrected place to write 0x30, 0x83, 0x19, 0x89, 0x64 is calculate from image header, it's defined as:
Code:
struct boot_img_hdr
{
unsigned char magic[BOOT_MAGIC_SIZE];
unsigned kernel_size; /* size in bytes */
unsigned kernel_addr; /* physical load addr */
unsigned ramdisk_size; /* size in bytes */
unsigned ramdisk_addr; /* physical load addr */
unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned dt_size; /* device_tree in bytes */
unsigned unused; /* future expansion: should be 0 */
....
};
and then calculate:
Code:
if (hdr->page_size && (hdr->page_size != page_size)) {
page_size = hdr->page_size;
page_mask = page_size - 1;
}
kernel_actual = ROUND_TO_PAGE(hdr->kernel_size, page_mask);
ramdisk_actual = ROUND_TO_PAGE(hdr->ramdisk_size, page_mask);
second_actual = ROUND_TO_PAGE(hdr->second_size, page_mask);
dt_size = hdr->dt_size;
dt_actual = ROUND_TO_PAGE(dt_size, page_mask);
imagesize_actual = (page_size + kernel_actual + ramdisk_actual + second_actual + dt_actual);
imagesize_actual is the place to write
NOTE2: There may be a easier way to enter EDL considering there are so many bug(eg. uninitialized stack variable, buffer overrun, missing bound check) in Xiaomi's modification, but I haven't bothered to check since my goal is achieved.
NOTE3: I suspect other model from Xiaomi may have similar bugs that bootloader lock can be bypassed using this method, but I don't have other phones to confirm my belief.
Click to expand...
Click to collapse
Hello!
I am not very familliar with programming or ROM development.
Could you please explain a bit more specific about NOTE1, how to append 4K block?
I don't quite understand where should I add it. At the beginning of the image, at the end or at the specific place in that file?
And 4k block means 4 kilobytes? Like 4096 bytes?
And if I need to flash custom room should I change something in xml files to? Or just append will be sufficient?
Please help, I need to flash that Riva finally!
Related
Found this on Huawei's webpage: http://www.huaweidevice.com/worldwi...=toDownloadFile&flay=software&softid=NDcwODE=
open source_wlan.tar_S7_Android2.2
Would be nice if someone has the time to look at this.
The binary file that shipped with my Huawei firmware has version 4.218.248.17
Edit:
Tested and working. Forgot to update text here.
Mirrored the file for convenience for everyone who wants this. The first link actually was wrong, so I changed it.
Put this in an Android tree (such as /hardware/broadcom), do breakfast/lunch after envsetup, and perform 'make dhdko' with the kernel files present at /kernel. This is for Froyo. To build for Gingerbread, LOCAL_MODULE_TAGS cannot be equal to 'user', so you need to change Android.mk to say 'optional' instead. That's if you want to use Android.mk to build. If you are not building the whole tree, remember to make a folder /lib/modules/, or dhd.ko will not copy from the product obj folder properly.
Not sure how this will build for ICS/Jellybean, but at least now we have the source code that actually builds a proper module.
Kernel objects need to be in the right place. I did something to the effect of:
make -C kernel O=/sources/aosp/out/target/product/s7/obj/KERNEL_OBJ ARCH=arm CROSS_COMPILE=arm-eabi-
Built module works fine and is the same version shipped with Android 2.2 (4.218.248.17).
The driver is actually eerily similar to the bcm4329 kernel 3.4 bcm4329 driver. So much so i figured out what caused the sdio timeout.
Offending code causing emulate domain manager error om 2.6.35 when removed, sdio timeout when added:
dhd_linux.c:
Code:
static int
dhd_watchdog_thread(void *data)
{
dhd_info_t *dhd = (dhd_info_t *)data;
/* This thread doesn't need any user-level access,
* so get rid of all our resources
*/
#ifdef DHD_SCHED
if (dhd_watchdog_prio > 0) {
struct sched_param param;
param.sched_priority = (dhd_watchdog_prio < MAX_RT_PRIO)?
dhd_watchdog_prio:(MAX_RT_PRIO-1);
setScheduler(current, SCHED_FIFO, ¶m);
}
#endif /* DHD_SCHED */
DAEMONIZE("dhd_watchdog");
/* Run until signal received */
while (1) {
if (down_interruptible (&dhd->watchdog_sem) == 0) {
offender---------> dhd_os_sdlock(&dhd->pub);
if (dhd->pub.dongle_reset == FALSE) {
For kernels : http://threader.zapto.org/experimental/s7/wifi/bcm4329-30-09-13.tar.bz2
http://theteamk.x10.mx/index.php?topic=153.0
The Team K Developers have started the work on fota to end the prolonged wait of android on wave 525.developers r requested to please post some codings so that the project can be completed soon.please keep dis thread development focussed and clean.
After a lot of research the forum users have found the brcm2133.elf and wave 525 fota which can be decoded using IDA PRO DISASSEMBLER.
Anyone who can help can come forward and help
Thanks
I HAVE FOUND BCM21331.elf IN SAMSUNG CORBY s3653w FIRMWARE FILE. THERE IS ALSO WEBKIT.elf. DOWNLOAD IT FROM HERE(it is contained in firmware):
Click to expand...
Click to collapse
Please.
Need BCM21331.elf for study...
Where to download?
You can write PM. :angel:
Thanx in advance.
Best Regards
adfree said:
Please.
Need BCM21331.elf for study...
Where to download?
You can write PM. :angel:
Thanx in advance.
Best Regards
Click to expand...
Click to collapse
http://mediafire.com/?uxhiu82ffwcrvue
u can download brcm21331 from the above link.it is present in the SAMSUNG CORBY s3653w FIRMWARE FILE
Thanks
It seems BCM21331.elf of S3653WDXJG2 is apps_compressed.bin... not Bootfiles...
http://forum.xda-developers.com/showthread.php?t=1325713
Code:
ELF_MAP
BCM21331.csi 9 MB
BCM21331.elf 327 MB
BCM21331.map 125 MB
BCM21331.sym 41 KB
WEBKIT.elf 167 MB
Seen from S3850... but no valid Downloadlink...
Best Regards
reply
adfree said:
It seems BCM21331.elf of S3653WDXJG2 is apps_compressed.bin... not Bootfiles...
http://forum.xda-developers.com/showthread.php?t=1325713
Code:
ELF_MAP
BCM21331.csi 9 MB
BCM21331.elf 327 MB
BCM21331.map 125 MB
BCM21331.sym 41 KB
WEBKIT.elf 167 MB
Seen from S3850... but no valid Downloadlink...
Best Regards
Click to expand...
Click to collapse
i didnt understand
did mediafire say that the download link was not valid
anyway i will upload the elf file today( i have downloaded it )
i dont think that the elf file is apps compressed.bin
u can check it out yourself after i upload the file
Thanks
request
i also request the moderators and administrators to make this thread sticky
Thanks
anyway i will upload the elf file today( i have downloaded it )
Click to expand...
Click to collapse
NO. Thank you.
I have this file. :angel:
But this is apps_compressed.bin... NOT Bootloader and it is only 1 file of 3 or 4 files...
Missing, because maybe helpfull...
Code:
BCM21331.csi
BCM21331.map
BCM21331.sym
So it is maybe less helpfull to find correct ""FOTA values"" to make such output + more...
http://forum.xda-developers.com/showthread.php?t=1496729
Best Regards
i am not really well versed with the coding
do u need BCM21331.csi
BCM21331.map
BCM21331.sym files ?
Thanks
anyway here is the brcm21331.elf for all other devs
http://d-h.st/VMs
Thanks
devs please help and contribute to this thread
i am using ida pro to decode the brcm21331.elf but need help on how to use this software
Thanks
Again...
Check this Thread...
http://forum.xda-developers.com/showthread.php?t=1496729
From S8500...
Code:
#include "BL3.h"
unsigned long c_[B]MemMMUCacheEnable[/B][] = { [COLOR="Red"]0xaab9f874,[/COLOR] 0 };
unsigned long c_[B]disp_FOTA_Init[/B][] = { [COLOR="Red"]0xbfab9174[/COLOR], 0 };
unsigned long c_[B]disp_FOTA_Printf[/B][] = { [COLOR="Red"]0xb69c410b[/COLOR], 0 };
unsigned long c_[B]OemSysGetSystemInfo[/B][] = { [COLOR="Red"]0xc3ac31a5[/COLOR], 0 };
unsigned long *fun_crc[i_endMarker] = {c_MemMMUCacheEnable,
c_disp_FOTA_Init,
c_disp_FOTA_Printf,
c_OemSysGetSystemInfo
};
This is what you need to find... MINIMUM.
This what we can find in BL3_univ.elf + BL3_univ.map
These files are from BOOTLOADER...
BCM21331.elf is ELF file of apps_compressed.bin...
You can NOT find this text in BCM21331.elf
Code:
MemMMUCacheEnable
disp_FOTA_Init
disp_FOTA_Printf
OemSysGetSystemInfo
So I am pretty sure... 51 % that BCM21331.elf is WRONG file to find correct values...
Anyway. With study of BCM21331.elf maybe someone can better understand how SHP/MOCHA Security etc. work...
Good luck.
Best Regards
adfree said:
Again...
Check this Thread...
http://forum.xda-developers.com/showthread.php?t=1496729
From S8500...
Code:
#include "BL3.h"
unsigned long c_[B]MemMMUCacheEnable[/B][] = { [COLOR="Red"]0xaab9f874,[/COLOR] 0 };
unsigned long c_[B]disp_FOTA_Init[/B][] = { [COLOR="Red"]0xbfab9174[/COLOR], 0 };
unsigned long c_[B]disp_FOTA_Printf[/B][] = { [COLOR="Red"]0xb69c410b[/COLOR], 0 };
unsigned long c_[B]OemSysGetSystemInfo[/B][] = { [COLOR="Red"]0xc3ac31a5[/COLOR], 0 };
unsigned long *fun_crc[i_endMarker] = {c_MemMMUCacheEnable,
c_disp_FOTA_Init,
c_disp_FOTA_Printf,
c_OemSysGetSystemInfo
};
This is what you need to find... MINIMUM.
This what we can find in BL3_univ.elf + BL3_univ.map
These files are from BOOTLOADER...
BCM21331.elf is ELF file of apps_compressed.bin...
You can NOT find this text in BCM21331.elf
Code:
MemMMUCacheEnable
disp_FOTA_Init
disp_FOTA_Printf
OemSysGetSystemInfo
So I am pretty sure... 51 % that BCM21331.elf is WRONG file to find correct values...
Anyway. With study of BCM21331.elf maybe someone can better understand how SHP/MOCHA Security etc. work...
Good luck.
Best Regards
Click to expand...
Click to collapse
Thanks for the clarification.
In the FOTA editing,are you guys using asm coding language ?
What minimum do i need to find?
Thanks
This whole thread and idea is wrong at this moment. FOTA exploit has been confirmed to work only for bootloaders of S8500 and S8530. There is no clue if there's such security flaw present in 525 - ergo, you should start with looking for security hole, and then writing exploit to utilise it instead of writing exploit without even knowing if there's anything to exploit literally.
FOTA exploit has been confirmed to work only for bootloaders of S8500 and S8530. There is no clue if there's such security flaw present in 525 - ergo, you should start with looking for security hole...
Click to expand...
Click to collapse
We all know it was looooooong way between first text output and later magic things with FOTA for S8500 and S8530... like zImage start for Android and so on...
http://forum.xda-developers.com/showthread.php?t=1020444
Short look into GT-S5250_Training_Manual_SW.ppt
1.
FOTA file used...
Code:
bplib_S5250OpenEuropeSlav.fota
Chance "high" to generate text ouput. :angel:
1.1
Broadcom Mobile Trace Terminal
Click to expand...
Click to collapse
Not found yet... maybe same like WinComm...
2.
Btw...
_uart_bootloader
Code:
boot1a.img
boot1b.img
boot2.img
onenandboot_4k.img
What is this? Found in
Code:
S5250XEJI4.rar
S5250XEJI6.rar
I have NO Broadcom devices for tests... also NOT in future...
Find your own solution, with your own way...
Best Regards
P.S.:
If way found for zImage start... you need your own/new Broadcom team...
Sorry.
Thank you everyone for any input you are giving
Rebellos thank u very much that fact was an eye opner
I will be really grateful to u guys if you can tell me on how u guys came to know the security loophole.Any kind of help is greatly acknowleged.Again I would like to thank adsfree and rebellos for their contributions to this thread and the facts
I've made a 20 minutes exercise - I downloaded bootfiles from S5250 (S5250XXJK2) and disassembled boot2.img using a guess that the bootloader is loaded at 83E00000. Easily found FOTA code similar to S8500. The binary is loaded from flash address 07E00000 to RAM 85200000 and executed there if the BPDZ marker is available (apps and fota file is checked as well), just as in S8500. The difference is switch arm32 and thumb mode.
In the attachment I've provide a sample fota file along with asm sources. That's all I can help. There's so much more things to be handled since this moment, but it's your job if you are to be capable of continuing any porting project. Please be aware that this is a hopeless task and you do it for fun and exploring. A finished port is not likely to be ever achieved unless you have a device with exactly same board (not only microcontroller, but display, radio, camera, wifi, sensors, etc) as another android device.
canu guys tell me how u decoded boot2.img
i mean using which software and how did u get the code
please help
Thanks
Maybe you could try what mijoma attached...
S5250_src.zip
Especially this file:
S5250_fota_base.fota
Feedback help if it work or not...
Best Regards
u did not understand what i said
i asked how u decoded boot2.img and using which software and how did you get the code
u did not understand what i said
Click to expand...
Click to collapse
Few answers are given...
Now mijoma offered FIRST solution for testing...
S5250_fota_base.fota
Now waiting for someones test feedback...
mijoma has NO broadcom device for testing...
Me too...
So you or other S5250 users...
I have also asked in German Thread...
http://www.handy-faq.de/forum/samsu...sion_download_freigegeben-11.html#post2541317
I can also not seen here in your Thread test result...
http://androbada525.hj.cx/index.php/topic,153.15.html
Best Regards
I came across this site of a guy named Dan Rosenburg stating that he exploited the At&t and Verizon variants. Maybe this is helpful for exploiters I don't know but thought I'd post. :good:variants.http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html?m=1
Azimuth Security
Azimuth Security
Thursday, May 23, 2013
Exploiting Samsung Galaxy S4 Secure Boot
Launched in April 2013, the Samsung Galaxy S4 is expected to be one of the top-selling smartphones of the year, having sold 10 million units in its first month of sales. While the majority of released models include an unlocked bootloader, which allows users to flash custom kernels and make other modifications to the software on their own devices, AT&T and Verizon branded devices ship with a locked bootloader that prevents these types of modifications. In this post, I'll provide details on how Samsung implement this locking mechanism, and publish a vulnerability in the implementation that allows bypassing the signature checks to run custom unsigned kernels and recovery images.
Both the AT&T (SGH-I337) and Verizon (SCH-I545) models utilize the Qualcomm APQ8064T chipset. As described in my previous blog post on Motorola's bootloader, Qualcomm leverages software-programmable fuses known as QFuses to implement a trusted boot sequence. In summary, each stage of the boot process cryptographically verifies the integrity of the subsequent stage, with the trust root originating in QFuse values. After the early boot stages bootstrap various hardware components, Samsung's APPSBL ("Application Secondary Bootloader") is loaded and run. This bootloader differs between "locked" and "unlocked" variants of the Galaxy S4 in its enforcement of signature checks on the boot and recovery partitions.
A quick glance at aboot (adopting the name of the partition on which this bootloader resides) revealed that it is nearly identical to the open source lk ("Little Kernel") project, which undoubtedly saved me many hours of tedious reverse engineering. By locating cross-references to strings found in both lk and aboot, I was able to quickly identify the functions that implement signature verification and booting of the Linux kernel.
The central logic to load, verify, and boot the Linux kernel and ramdisk contained in either the boot or recovery partitions is implemented in the boot_linux_from_mmc() function. First, the function determines whether it is booting the main boot partition, containing the Linux kernel and ramdisk used by the Android OS, or the recovery partition, which contains the kernel and ramdisk used by the Android recovery subsystem. Then, the first page of the appropriate partition is read into physical memory from the eMMC flash storage:
if (!boot_into_recovery) {
index = partition_get_index("boot");
ptn = partition_get_offset(index);
if (ptn == 0) {
dprintf(CRITICAL, "ERROR: No boot partition found\n");
return -1;
}
}
else {
index = partition_get_index("recovery");
ptn = partition_get_offset(index);
if (ptn == 0) {
dprintf(CRITICAL, "ERROR: No recovery partition found\n");
return -1;
}
}
if (mmc_read(ptn + offset, (unsigned int *) buf, page_size)) {
dprintf(CRITICAL, "ERROR: Cannot read boot image header\n");
return -1;
}
This code is straight out of lk's implementation. Next, after performing some sanity-checking of the boot image, which contains a custom header format, the function loads the kernel and ramdisk into memory at the addresses requested in the boot image header:
hdr = (struct boot_img_hdr *)buf;
image_addr = target_get_scratch_address();
kernel_actual = ROUND_TO_PAGE(hdr->kernel_size, page_mask);
ramdisk_actual = ROUND_TO_PAGE(hdr->ramdisk_size, page_mask) + 0x200;
imagesize_actual = (page_size + kernel_actual + ramdisk_actual);
memcpy(image_addr, hdr, page_size);
offset = page_size;
/* Load kernel */
if (mmc_read(ptn + offset, (void *)hdr->kernel_addr, kernel_actual)) {
dprintf(CRITICAL, "ERROR: Cannot read kernel image\n");
return -1;
}
memcpy(image_addr + offset, hdr->kernel_addr, kernel_actual);
offset += kernel_actual;
/* Load ramdisk */
if (mmc_read(ptn + offset, (void *)hdr->ramdisk_addr, ramdisk_actual)) {
dprintf(CRITICAL, "ERROR: Cannot read ramdisk image\n");
return -1;
}
memcpy(image_addr + offset, hdr->ramdisk_addr, ramdisk_actual);
offset += ramdisk_actual;
This is still essentially identical to lk's implementation, with the addition of code to copy the individual pieces of the boot image to the image_addr location. Finally, the function performs signature verification of the entire image. If signature verification succeeds, the kernel is booted; otherwise, a tampering warning is displayed and the device fails to boot:
if (check_sig(boot_into_recovery))
{
if (!is_engineering_device())
{
dprintf("kernel secure check fail.\n");
print_console("SECURE FAIL: KERNEL");
while (1)
{
/* Display tampered screen and halt */
...
}
}
}
/* Boot the Linux kernel */
...
The is_engineering_device() function simply returns the value of a global variable that is set at an earlier stage in the boot process based on whether or not the chipset ID (an unchangeable hardware value) of the device indicates it is an engineering or production device.
Examining the check_sig() function in more detail revealed that aboot uses the open-source mincrypt implementation of RSA for signature validation. The bootloader uses an RSA-2048 public key contained in aboot to decrypt a signature contained in the boot image itself, and compares the resulting plaintext against the SHA1 hash of the boot image. Since any modifications to the boot image would result in a different SHA1 hash, it is not possible to generate a valid signed boot image without breaking RSA-2048, generating a specific SHA1 collision, or obtaining Samsung's private signing key.
The astute reader will have already noticed the design flaw present in the above program logic. Notice the order in which the steps are performed: first, aboot loads the kernel and ramdisk into memory at the addresses requested by the boot image header, and then signature validation is performed after this loading is complete. Because the boot image header is read straight from eMMC flash prior to any signature validation, it contains essentially untrusted data. As a result, it's possible to flash a maliciously crafted boot image whose header values cause aboot to read the kernel or ramdisk into physical memory directly on top of aboot itself!
Exploitation of this flaw proved to be fairly straightforward. I prepare a specially crafted boot image that specifies a ramdisk load address equal to the address of the check_sig() function in aboot physical memory. In my malicious boot image, I place shellcode where the ramdisk is expected to reside. I flash this image by leveraging root access in the Android operating system to write to the boot block device. When aboot reads the supposed ramdisk from eMMC flash, it actually overwrites the check_sig() function with my shellcode, and then invokes it. The shellcode simply patches up the boot image header to contain sane values, copies the actual kernel and ramdisk into appropriate locations in memory, and returns zero, indicating the signature verification succeeded. At this point, aboot continues the boot process and finally boots my unsigned kernel and ramdisk. Victory!
Check the date. I do believe that is the loki exploit.
It is Loki.... Doesn't work past MDK...
However if you check the other bootloader thread, Dan just released some stuff today that may lead to an exploit for us on builds later than that!
Jraider44 said:
It is Loki.... Doesn't work past MDK...
However if you check the other bootloader thread, Dan just released some stuff today that may lead to an exploit for us on builds later than that!
Click to expand...
Click to collapse
Oh ok thank for the reply mind sending me a link if his other thread? And hopefully we get the bootloader unlocked before 2015
instarichisdope said:
Oh ok thank for the reply mind sending me a link if his other thread? And hopefully we get the bootloader unlocked before 2015
Click to expand...
Click to collapse
The thread can be found here: http://forum.xda-developers.com/showthread.php?t=2500826
Yeah all hopes! Surge and the other guys working out of that thread are all great devs, and if anybody can do anything with the information released today, they can.
Closing this thread as the info is already out there.
Hi there,
right now I'm trying to get some knowledge about the little kernel bootloader and how it's working. I just read an article about exploiting the S4 bootloader: http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
Basically the author describes a method, how to modify the function, which verifies the signature during runtime. As far as i understand it, he modifies a boot image in such a way, that a certain shell script is overwriting the check-function and in the end returns a check passed value.
Then i had a quick look into the little kernel source code to the corresponding position (at least i think, that's the right position:
Code:
else
{
dprintf(INFO, "Authenticating boot image (%d): start\n", imagesize_actual);
auth_kernel_img = image_verify((unsigned char *)image_addr,
(unsigned char *)(image_addr + imagesize_actual),
imagesize_actual,
CRYPTO_AUTH_ALG_SHA256);
dprintf(INFO, "Authenticating boot image (%d): done\n", imagesize_actual);
if(auth_kernel_img)
{
/* Authorized kernel */
device.is_tampered = 0;
}
}
I'm just wondering if it wouldn't be possible, to overwrite the image_verify function in the same way the author did it in his article?
regards,
scotch
Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.
Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.
chairshot215 said:
Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.
Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.
Click to expand...
Click to collapse
https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b
Done in kernel
Sent from my Nexus 6 using Tapatalk
buckmarble said:
https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b
Done in kernel
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
Thanks had worked out in one of the three I was testing using SuperSu 5.1. Why I am trying to school myself on new changes it seems I am now encrypted by default using the same files (fstab.shamu) that I used in 5.1.1. Are you aware of any changes now required for 6.0? admittedly am using the same Anykernel set up as I had with Lollipop and am new to using the Anykernel method for flashing kernels as in the past would just compile the boot.img. Honestly had been used to releasing my own Roms and not just Kernels so some of these things are new.
Sorry I am not ashamed to admit when something simple is throwing me for a loop and ask even if makes me look like a dumb ars.
chairshot215 said:
Thanks had worked out in one of the three I was testing using SuperSu 5.1. Why I am trying to school myself on new changes it seems I am now encrypted by default using the same files (fstab.shamu) that I used in 5.1.1. Are you aware of any changes now required for 6.0? admittedly am using the same Anykernel set up as I had with Lollipop and am new to using the Anykernel method for flashing kernels as in the past would just compile the boot.img. Honestly had been used to releasing my own Roms and not just Kernels so some of these things are new.
Sorry I am not ashamed to admit when something simple is throwing me for a loop and ask even if makes me look like a dumb ars.
Click to expand...
Click to collapse
to remove force encryption you need to change "forceencrypt" to "encryptable" in the fstab for userdata. This will not automagically decrypt you, so if you flashed factory images, you will be encrypted again. You will need to format data in TWRP to decrypt again.
I just pushed my anykernel to Github so could post but is pretty much what I had done. what I had done was working after either format data or performing a factory reset with 5.1.1. Starting to think maybe my factory image flash had gone wrong. Could just be a change I am not aware of but did not see the optimizing apps screen after wiping. What I had essentially done is after flashing factory image rebooted bootloader and before booting the first time flashed TWRP installed my Kernel, flashed SuperSu 5.1 and then did a full cache and data wipe.
Admittedly with anykernel I had started by downloading another Kernel, forget which one and then removed or adding what I believed should for my Kernel. So far besides the little encryption issue seems to be working out OK. Trying to keep the Kernel as effective as possible with the fewest possible trade off’s. Not much original work in the sense a lot has already been done but have done lots of testing for efficiency.
Anykernel
https://github.com/Starship-Android/anykernel
chairshot215 said:
Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.
Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.
Click to expand...
Click to collapse
buckmarble said:
https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b
Done in kernel
Click to expand...
Click to collapse
That is actually a *really bad hack*, since it disables selinux rather than manipulating the policy in an appropriate manner to make root usage possible.
The correct changes are actually *outside* of the kernel itself, in the sepolicy file in the ramdisk.
That sepolicy file is generated based primarily on what is in these repositories;
https://android.googlesource.com/platform/external/sepolicy/
https://android.googlesource.com/device/moto/shamu/+/master/sepolicy/
You see, there are some interesting commits, like this; https://android.googlesource.com/pl...243e5cf4f8898b7acedc24efd58fdcd163e3048^!/#F0
What that one does, is it tells selinux to never allow the sepolicy to be reloaded from the system_server context.
Or this one here, which does the same for the init context;
https://android.googlesource.com/pl...cy/+/6d0e9c8f4ee4f326b2c2851fa2851193fec33a4e
But note: partially reverted here;
https://android.googlesource.com/pl...abd409af0e7d7fb908e5f04fa1ed946e2996dce^!/#F0
That partial reversion actually provides a very useful HINT about it;
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
# which can be configured on a device-by-device basis if needed.
In other words, add that line to this file;
https://android.googlesource.com/device/moto/shamu/+/master/sepolicy/init.te
Then *init* will re-gain the ability to change and reload selinux policies.
HOWEVER, instead of doing that, you might consider going a little further, by enabling THIS in a sortof-user-build;
https://android.googlesource.com/platform/external/sepolicy/+/master/su.te
... and adding domain_auto_trans from untrusted_app to su, and various other adjustments/tweaks.
I think that there is a neverallow rule in there somewhere that will complain if you make that change, so you'll have to kill the neverallow rule... yep, app domain:
https://android.googlesource.com/platform/external/sepolicy/+/master/app.te#286
**note: a neverallow rule is NOT a runtime enforcement directive. selinux defaults to block until a positive allow rule is created. The neverallow rules are used to annoy you when you try to build an sepolicy from source that violates something.
What *I* would do first, is fix that neverallow rule in app, add the auto-transition to su, and run a make bootimg for *USERDEBUG*. You probably should also edit the fstab a bit while you are at it to kill the "verify" parameter from /system, and swap the "forceencrypt" to "encryptable" for /data.
ALL of the changes (besides removing the neverallow rule) can be made in the shamu device tree.
This should produce a boot.img that relaxes selinux a bit to allow su. And from there, the su binary can be root.root/6755, WITH the file context set to su_exec, and you should have root back.... note: su daemon should *NOT* be required with these changes. In fact, you could even proof of concept using "cp /system/bin/sh /system/bin/su; chown root.root /system/bin/su; chmod 6755 /system/bin/su; chcon su_exec /system/bin/su" <-- you will have to look more at the chcon first parameter though, I haven't actually had to use it though, so I'm not entirely sure of what it expects as input. Note the boldness of "proof of concept"... it would be very... unsafe... to actually keep it like that on any device that you actually need to trust.
phhusson's new fork of superuser *should* be able to handle the job, with only minor adjustments to su.c's su_main() function where it is deciding to run connect_daemon() or su_main_nodaemon(). It would need to run su_main_nodaemon() with these changes.
So I've actually been working on this myself, since it is impossible to trust chainfire or his new employer (who is systematically buying up ALL of the root provisioning software for Android), and I have come up with this as an interim step;
Code:
diff --git a/app.te b/app.te
index 40de074..98bb663 100644
--- a/app.te
+++ b/app.te
@@ -283,7 +283,7 @@ neverallow appdomain { domain -appdomain }:process
# Transition to a non-app domain.
# Exception for the shell domain and the su domain, can transition to runas,
# etc.
-neverallow { appdomain -shell userdebug_or_eng(`-su') } { domain -appdomain }:process
+neverallow { appdomain -untrusted_app -shell userdebug_or_eng(`-su') } { domain -appdomain }:process
{ transition dyntransition };
# Write to rootfs.
diff --git a/domain.te b/domain.te
index 0f6c6da..b1d7c41 100644
--- a/domain.te
+++ b/domain.te
@@ -396,7 +396,7 @@ neverallow domain { file_type fs_type dev_type }:{ lnk_file fifo_file sock_file
# Nobody should be able to execute su on user builds.
# On userdebug/eng builds, only dumpstate, shell, and
# su itself execute su.
-neverallow { domain userdebug_or_eng(`-dumpstate -shell -su') } su_exec:file no_x_file_perms;
+neverallow { domain -init -untrusted_app userdebug_or_eng(`-dumpstate -shell -su') } su_exec:file no_x_file_perms;
# Do not allow the introduction of new execmod rules. Text relocations
# and modification of executable pages are unsafe.
diff --git a/init.te b/init.te
index 41eafe2..e7dd87a 100644
--- a/init.te
+++ b/init.te
@@ -123,7 +123,7 @@ allow init security_file:dir { create setattr };
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
-# allow init kernel:security load_policy;
+allow init kernel:security load_policy;
# which can be configured on a device-by-device basis if needed.
r_dir_file(init, security_file)
@@ -283,4 +283,5 @@ neverallow init shell_data_file:lnk_file read;
neverallow init app_data_file:lnk_file read;
# init should never execute a program without changing to another domain.
-neverallow init { file_type fs_type }:file execute_no_trans;
+allow init { file_type fs_type }:file execute_no_trans;
+allow init kernel:security read_policy;
diff --git a/keystore.te b/keystore.te
index 83a0e85..d742d30 100644
--- a/keystore.te
+++ b/keystore.te
@@ -24,7 +24,7 @@ selinux_check_access(keystore)
###
neverallow { domain -keystore } keystore_data_file:dir ~{ open create read getattr setattr search relabelto ioctl };
-neverallow { domain -keystore } keystore_data_file:notdevfile_class_set ~{ relabelto getattr };
+neverallow { domain -keystore -init } keystore_data_file:notdevfile_class_set ~{ relabelto getattr };
neverallow { domain -keystore -init } keystore_data_file:dir *;
neverallow { domain -keystore -init } keystore_data_file:notdevfile_class_set *;
diff --git a/su.te b/su.te
index d4a488b..1d1f6da 100644
--- a/su.te
+++ b/su.te
@@ -7,6 +7,7 @@ userdebug_or_eng(`
# wrapped to ensure that it does not exist at all on -user builds.
type su, domain, mlstrustedsubject;
domain_auto_trans(shell, su_exec, su)
+ domain_auto_trans(untrusted_app, su_exec, su)
# Allow dumpstate to call su on userdebug / eng builds to collect
# additional information.
diff --git a/vold.te b/vold.te
index b22436f..fa1a879 100644
--- a/vold.te
+++ b/vold.te
@@ -164,7 +164,7 @@ allow vold self:capability sys_chroot;
allow vold storage_file:dir mounton;
neverallow { domain -vold } vold_data_file:dir ~{ open create read getattr setattr search relabelto ioctl };
-neverallow { domain -vold } vold_data_file:notdevfile_class_set ~{ relabelto getattr };
+neverallow { domain -vold -init } vold_data_file:notdevfile_class_set ~{ relabelto getattr };
neverallow { domain -vold -init } vold_data_file:dir *;
neverallow { domain -vold -init } vold_data_file:notdevfile_class_set *;
neverallow { domain -vold -init } restorecon_prop:property_service set;
Some of those are what reverse engineering I've managed to accomplish on the policy changes required for supersu, and some of them are working towards a better root control infrastructure.
In any case, if you patch platform/external/sepolicy with that, then run a "make bootimage", it *WILL* actually work with supersu.
** note: make sure that you repo init against the android-6.0.0_r1 release branch if you want it to actually be compatible with factory builds. Master has a LOT of MAJOR changes since then and it does not work.
Also note: don't forget to patch platform/device/moto/shamu/fstab.shamu to kill the verify and optionally forceencrypt parameters.
I'm just going to leave these two links right here....
https://github.com/lbdroid/AOSP-SU-PATCH
https://github.com/phhusson/Superuser
That will yield an ENFORCING, and NON-RELOADABLE selinux policy, allowing root, and all bundled into the boot.img in order to maintain the integrity (dm-verity) of the system image!
Take THAT Coding Code Mobile Technology LLC!!!!!
And for people who want to know the true history of things (rather than worshiping people who distribute binaries....), please read this; http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html and then look at the github label (that says "forked from") on the Superuser repository I linked above.
doitright said:
I'm just going to leave these two links right here....
https://github.com/lbdroid/AOSP-SU-PATCH
https://github.com/phhusson/Superuser
That will yield an ENFORCING, and NON-RELOADABLE selinux policy, allowing root, and all bundled into the boot.img in order to maintain the integrity (dm-verity) of the system image!
Take THAT Coding Code Mobile Technology LLC!!!!!
And for people who want to know the true history of things (rather than worshiping people who distribute binaries....), please read this; http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html and then look at the github label (that says "forked from") on the Superuser repository I linked above.
Click to expand...
Click to collapse
Thanks I have been bed ridden for a bit but will look over all these things. In short my last build I first flashed chainfires boot.img and rooted before flashing my Kernel. Was able to do this without putting my Kernel into permissive mode. Had also unpacked the chainfire boot.img and used a few things in my boot image and used Meld and made a few other edits based on chainfires boot.img. Still having an issue with encryption being forced that just has me baffled. Was otherwise a temporary quick fix for not having to put the Kernel into permissive mode.
Definitely appreciate all the feedback and am learning allot so thanks for that everyone.
Otherwise the Encryption is driving me mentally insane. Like straitjacket throwing myself around a small room with rubber walls and a door with a slot that keeps opening with a tray of drugs and food sliding in insane. It has become so frustrating.
this is the fstab I am using and see know issue. Have also tried Despair, Vortex and the fed_patcher patch not to mention Chainfires Kernel for Root and no matter how many times I wipe data or factory reset it is always encrypted. If it was not knowing the encryption is done via software would swear something is wrong with the phone. Have also changed up TWRP 3 times as noticed I no loner see updating apps but that is also the same in that encription is still forced
https://github.com/Chairshot215/anykernel/blob/master/ramdisk/fstab.shamu
The problem you are running into, is that recovery doesn't actually *format* the userdata partition, which means that a factory reset from recovery won't *remove* the encryption. The reason it doesn't format is to prevent the deletion of /data/media directory, which gets mapped to /sdcard.
What you need to do, is reboot to bootloader, and run "fastboot format userdata".
If you aren't permissive, then the big thing you must have taken from chainfire's boot.img, is the sepolicy file. He only actually changed two files; sepolicy and fstab.shamu.
The thing to be aware of, though, is that his supersu, despite running selinux enforcing, is actually putting a lot of domains into permissive. When you go through your kernel audit log, you should pay attention to the end of the audit log where it says "permissive=1" or "permissive=0". You will find a lot of "permissive=1". Using *my* sepolicy, which is NOT compatible with his supersu, you will find that ALL domains remain enforcing, yet we aren't increasing the authority of any domain besides the "su" domain, AND, there will actually be far fewer denials against root/su. On top of that, I actually block the su domain from messing with kernel security. In other words, we do NOT allow the su domain to change selinux to permissive, OR to reload the policy. Both of those ARE permitted in chainfire supersu, which is incredibly dangerous, given how root is typically used on Android.
To put that into perspective, the ability to change the enforcement status or reload the policy, makes it possible for a malicious application to modify the boot.img to disable dmverity on the system partition, and compromise the system partition. My approach makes it possible to maintain the integrity of the boot partition and therefore maintain dmverity on the system partition, while providing root access. This makes unauthorized changes to the system partition immediately obvious and ineffective, since dmverity will refuse to read changed data, instead returning an i/o error.
The verity keys are actually stored on the boot.img, which means that it is still possible to make *intentional* changes to the system partition (through regenerating the key), and prevent unauthorized changes.
I've been considering adding a new domain to the effect of "su_sensitive" that will enforce strong password input for every authorization request in order to grant kernel security permission, but it remains to be seen if this would even be helpful to anyone.
How do you even edit a kernel? If you could explain, please do so.