Related
MSM7227 S1Boot has been patched to ignore SIN header signature by the_laser.
You need phone which you either did not unlock by cable, or phone which you unlocked via SEtool2 only.
If you unlocked with Omnius, in C:\ProgramData\Omnius for SE\Backups\Xperia X8
you have file called: Xperia X8_IMEI_DATE_SIMLock.opd
Restore that TA backup, then use semc.cmd in the_laser's release to unlock bootloader - you'll restore SIM lock this way!
Currently there is no unlocked bootloader for Omnius unlocked phones.
Read all instructions here: http://forum.xda-developers.com/showthread.php?p=17338716#post17338716
What will this allow:
* custom kernels
* better/fully working Gingerbread
* no need for chroot to avoid init crash bug
* overclock/Synaptics fake DT/Cypress real DT/MDDI fix built in kernel
This will not enable:
* real DT on Synaptics digitizer
Greetings.
warning.
if you are not developer, please quit reading that post.
wait for user friendly tool with one big button.
here ( View attachment msm7227.7z ) is toolset to permanently "unlock" semcboot of msm7227 semc phones.
that means, you can use own kernel and so on.
steps,precautions, etc.
unpack archive to any directory.
if you using eset antivirus or similar ****, it will find evil virus in adb.exe.
ignore that, it is not virus in any way, it is standard android debug bridge, bundled in one file to save space and usability.
now, if your phone unlocked officially:
flash phone with standard 2.0,2.1 android firmware,because kernel mapper module compiled for "2.6.29" kernel.
of course, enable "usb debugging"
run msm7227_semc.cmd,
( if you want, examine it before run, it is pretty straightforward. )
you will get similar output
Code:
process requires standard 2.x android firmware.
Press any key to continue . . .
Getting ROOT rights.
1743 KB/s (585731 bytes in 0.328s)
error: protocol fault (no status)
Waiting ...
Removing NAND MPU restrictions via SEMC backdoor. Permanent. Require ROOT rights.
192 KB/s (3087 bytes in 0.015s)
success
Waiting ...
Getting ROOT rights.
Waiting ...
Writing patched semcboot. Two step process
First, we need get access to semcboot area
504 KB/s (8064 bytes in 0.015s)
Second, we need to write semcboot ;)
1130 KB/s (596916 bytes in 0.515s)
successfully wrote 0003ff00
Press any key to continue . . .
bingo, your phone now has unlocked bootloader.
if your phone unlocked by setool2 software, use msm7227_setool2.cmd
if your phone unlocked by 3rd-party software other than setool2, do not run anything -
it will disable radio capability of your phone and you will need to unlock phone by setool2 software.
hopefully, mizerable flea and mOxImKo will release something similar for your phone.
okay, now about other details.
1.
unlocked bootloader require unlocked loader, yep ?
loader\loader.sin is special unlocked loader, which will be accepted ONLY after your "unlock" semcboot with previous steps.
to distinguish unlocked semcboot and original semcboot, first letter in version tag of semcboot output will be lower case, i. e. "r8A029"
( same applies for loader version tag )
so, all that stuff with signatures are not for us, so i removed them - loader will ignore signature part of SIN file.
2.
we should make SIN file somehow, right ?
for that i prepared "dumb" bin2sin utility.
Syntax : bin2sin [input] [partition info, 32 digits] [type] [block size]
Click to expand...
Click to collapse
[input] - is input binary file.
[partition info]
android implementation on s1 semc qualcomm phones based on partitions,so we MUST define it for our file.
you can get required partition info from standard semc sin files, it is first 0x10 bytes of DATA, right after header, i.e.
e10 kernel partition info
03000000010000402001000040000000
Click to expand...
Click to collapse
[type] - partition type, 9 - partition without spare, 0xA - partition with spare.
kernel partition is partition without spare.
if that parameter omitted, type = 9
[block size] - nand block size, if omitted, it is standard size 0x20000
there is example in sinTools\example_build.cmd
3.
kernel should be prepared specially to be accepted by semcboot.
for that there is tool bin2elf.
Syntax : bin2Elf.exe [nbrOfSegments] [EntryPoint] [Segment1] [LoadAddress1] [Attributes1] ...
Click to expand...
Click to collapse
we need 2 segments:
segment 1 is unpacked linux kernel image, i.e.
( e10/kernel/arch/arm/boot/Image )
it looks like entrypoint and load address for segment 1 is always same for all msm7227-based semc phone, it is 0x00208000
attributes for image 0x0
segment 2 is ramdisk.
it looks like entrypoint and load address for segment 1 is always same for all msm7227-based semc phone, it is 0x01000000
set attributes for ramdisk 0x80000000, that is extremly important.
there is simple kernel example in sinTools\example_build.cmd
ps.
@blagus:
NAND MPU disabler has only one relation to rFoNe - he took it from setool2, together with entire idea for msm7227 bypass.
your 6-wings friend with many nicks done exactly same.
NAND MPU has nothing to do with memory firewall, so it will not help with kexec things, however, who will care now.
Thread closed because i'm boring of all this OFF TOPICS.
@ Blagus: you can open it when you have something to post.
@ Others: Use topic in general forum from NOW.
EDIT: After 3 hours i'm going to open again this thread, WARNING every off topic here will gain an infraction as " Failed to cooperate with a moderator", so, don't blame on me when you will see the infraction point.
So who will help to x8 devs to make custom kernel now!
the_laser said:
Greetings.
warning.
if you are not developer, please quit reading that post.
wait for user friendly tool with one big button.
here ( View attachment 712577 ) is toolset to permanently "unlock" semcboot of msm7227 semc phones.
that means, you can use own kernel and so on.
steps,precautions, etc.
unpack archive to any directory.
if you using eset antivirus or similar ****, it will find evil virus in adb.exe.
ignore that, it is not virus in any way, it is standard android debug bridge, bundled in one file to save space and usability.
now, if your phone unlocked officially:
flash phone with standard 2.0,2.1 android firmware,because kernel mapper module compiled for "2.6.29" kernel.
of course, enable "usb debugging"
run msm7227_semc.cmd,
( if you want, examine it before run, it is pretty straightforward. )
you will get similar output
Code:
process requires standard 2.x android firmware.
Press any key to continue . . .
Getting ROOT rights.
1743 KB/s (585731 bytes in 0.328s)
error: protocol fault (no status)
Waiting ...
Removing NAND MPU restrictions via SEMC backdoor. Permanent. Require ROOT rights.
192 KB/s (3087 bytes in 0.015s)
success
Waiting ...
Getting ROOT rights.
Waiting ...
Writing patched semcboot. Two step process
First, we need get access to semcboot area
504 KB/s (8064 bytes in 0.015s)
Second, we need to write semcboot ;)
1130 KB/s (596916 bytes in 0.515s)
successfully wrote 0003ff00
Press any key to continue . . .
bingo, your phone now has unlocked bootloader.
if your phone unlocked by setool2 software, use msm7227_setool2.cmd
if your phone unlocked by 3rd-party software other than setool2, do not run anything -
it will disable radio capability of your phone and you will need to unlock phone by setool2 software.
hopefully, mizerable flea and mOxImKo will release something similar for your phone.
okay, now about other details.
1.
unlocked bootloader require unlocked loader, yep ?
loader\loader.sin is special unlocked loader, which will be accepted ONLY after your "unlock" semcboot with previous steps.
to distinguish unlocked semcboot and original semcboot, first letter in version tag of semcboot output will be lower case, i. e. "r8A029"
( same applies for loader version tag )
so, all that stuff with signatures are not for us, so i removed them - loader will ignore signature part of SIN file.
2.
we should make SIN file somehow, right ?
for that i prepared "dumb" bin2sin utility.
[input] - is input binary file.
[partition info]
android implementation on s1 semc qualcomm phones based on partitions,so we MUST define it for our file.
you can get required partition info from standard semc sin files, it is first 0x10 bytes of DATA, right after header, i.e.
[type] - partition type, 9 - partition without spare, 0xA - partition with spare.
kernel partition is partition without spare.
if that parameter omitted, type = 9
[block size] - nand block size, if omitted, it is standard size 0x20000
there is example in sinTools\example_build.cmd
3.
kernel should be prepared specially to be accepted by semcboot.
for that there is tool bin2elf.
we need 2 segments:
segment 1 is unpacked linux kernel image, i.e.
( e10/kernel/arch/arm/boot/Image )
it looks like entrypoint and load address for segment 1 is always same for all msm7227-based semc phone, it is 0x00208000
attributes for image 0x0
segment 2 is ramdisk.
it looks like entrypoint and load address for segment 1 is always same for all msm7227-based semc phone, it is 0x01000000
set attributes for ramdisk 0x80000000, that is extremly important.
there is simple kernel example in sinTools\example_build.cmd
ps.
@blagus:
NAND MPU disabler has only one relation to rFoNe - he took it from setool2, together with entire idea for msm7227 bypass.
your 6-wings friend with many nicks done exactly same.
NAND MPU has nothing to do with memory firewall, so it will not help with kexec things, however, who will care now.
Click to expand...
Click to collapse
Here the link for original thread, so for who is interessed can keep reading next steps...
http://forum.xda-developers.com/showpost.php?p=17338716&postcount=300
I had known about it. and broke up his phone thus burned it.
This is just for everyone who doesnt chek the x8 section everyday:
Originally Posted by the_laser
http://forum.xda-developers.com/showthread.php?p=17338716#post17338716
Greetings.
warning.
if you are not developer, please quit reading that post.
wait for user friendly tool with one big button.
here ( msm7227.7z ) is toolset to permanently "unlock" semcboot of msm7227 semc phones.
that means, you can use own kernel and so on.
steps,precautions, etc.
unpack archive to any directory.
if you using eset antivirus or similar ****, it will find evil virus in adb.exe.
ignore that, it is not virus in any way, it is standard android debug bridge, bundled in one file to save space and usability.
now, if your phone unlocked officially:
flash phone with standard 2.0,2.1 android firmware,because kernel mapper module compiled for "2.6.29" kernel.
of course, enable "usb debugging"
run msm7227_semc.cmd,
( if you want, examine it before run, it is pretty straightforward. )
you will get similar output
Code:
process requires standard 2.x android firmware.
Press any key to continue . . .
Getting ROOT rights.
1743 KB/s (585731 bytes in 0.328s)
error: protocol fault (no status)
Waiting ...
Removing NAND MPU restrictions via SEMC backdoor. Permanent. Require ROOT rights.
192 KB/s (3087 bytes in 0.015s)
success
Waiting ...
Getting ROOT rights.
Waiting ...
Writing patched semcboot. Two step process
First, we need get access to semcboot area
504 KB/s (8064 bytes in 0.015s)
Second, we need to write semcboot
1130 KB/s (596916 bytes in 0.515s)
successfully wrote 0003ff00
Press any key to continue . . .bingo, your phone now has unlocked bootloader.
if your phone unlocked by setool2 software, use msm7227_setool2.cmd
if your phone unlocked by 3rd-party software other than setool2, do not run anything -
it will disable radio capability of your phone and you will need to unlock phone by setool2 software.
hopefully, mizerable flea and mOxImKo will release something similar for your phone.
okay, now about other details.
1.
unlocked bootloader require unlocked loader, yep ?
loader\loader.sin is special unlocked loader, which will be accepted ONLY after your "unlock" semcboot with previous steps.
to distinguish unlocked semcboot and original semcboot, first letter in version tag of semcboot output will be lower case, i. e. "r8A029"
( same applies for loader version tag )
so, all that stuff with signatures are not for us, so i removed them - loader will ignore signature part of SIN file.
2.
we should make SIN file somehow, right ?
for that i prepared "dumb" bin2sin utility.
Syntax : bin2sin [input] [partition info, 32 digits] [type] [block size]
[input] - is input binary file.
[partition info]
android implementation on s1 semc qualcomm phones based on partitions,so we MUST define it for our file.
you can get required partition info from standard semc sin files, it is first 0x10 bytes of DATA, right after header, i.e.
e10 kernel partition info
03000000010000402001000040000000
[type] - partition type, 9 - partition without spare, 0xA - partition with spare.
kernel partition is partition without spare.
if that parameter omitted, type = 9
[block size] - nand block size, if omitted, it is standard size 0x20000
there is example in sinTools\example_build.cmd
3.
kernel should be prepared specially to be accepted by semcboot.
for that there is tool bin2elf.
Syntax : bin2Elf.exe [nbrOfSegments] [EntryPoint] [Segment1] [LoadAddress1] [Attributes1] ...
we need 2 segments:
segment 1 is unpacked linux kernel image, i.e.
( e10/kernel/arch/arm/boot/Image )
it looks like entrypoint and load address for segment 1 is always same for all msm7227-based semc phone, it is 0x00208000
attributes for image 0x0
segment 2 is ramdisk.
it looks like entrypoint and load address for segment 1 is always same for all msm7227-based semc phone, it is 0x01000000
set attributes for ramdisk 0x80000000, that is extremly important.
there is simple kernel example in sinTools\example_build.cmd
ps.
@blagus:
NAND MPU disabler has only one relation to rFoNe - he took it from setool2, together with entire idea for msm7227 bypass.
your 6-wings friend with many nicks done exactly same.
NAND MPU has nothing to do with memory firewall, so it will not help with kexec things, however, who will care now.
And yes its for the mini pro also:
Originally Posted by Blagus:
MSM7227 phones:
Xperia X8
Xperia X10 Mini
Xperia X10 Mini Pro
Xperia W8
They all have same S1Boot and same loader.sin
So this method works on all 7227 phones.
Also, if you unlocked with Omnius and would like to have unlocked BL instead, first take TA backup, then restore old one (simlock...opd) and then use this method.
At last I want to thank everybody who helped with this and specialy: The_laser and Blagus.
Noob-friendly guide for how to unlock your bootloader here: http://forum.xda-developers.com/showthread.php?t=1254225
Cheers
>>>> In a post further down, I have released a updated zip file which contains the 2ndihkvc program as well as its source as well as few support scripts to allow experimentation with this mechanism of multiple user spaces <<<<
Hi All
I have been following the below thread, as well as working on my own on some of the concepts. You can get the details till now from my posts in the below thread.
http://forum.xda-developers.com/showthread.php?t=1378886
I was not able to get the SETREGS to succeed in setting PC required for the current/existing 2nd-init logic, nor wait was waiting to lock the process, SO I tried a new and simpler alternate method for triggering/execve the init process a 2nd time using only POKE and it seems to have succeeded. I am guessing this based on my nooktablet having got messed up and it keeps rebooting again and again when it reaches my logic potentially. I have to restore back to factory settings and try afresh in the morning (Well it is almost morning ;-) now here) with few more debug messages to pin point it fully.
The code I am injecting directly into init process is in the attached txt file which is actually a .s (assembly file). (NOTE: Currently I am not handling environment variables, not sure if that is causing my boot to keep looping).
In turn the logic to hijack the init process and inject the code is as simple as
Step1) PTRACE_ATTACH
Step2) PTRACE_GETREGS
Step3) PTRACE_POKETEXT (Regs.ARM_pc, code to inject)
Step4) PTRACE_CONT
Step5) PTRACE_DETACH
I will upload the code in a day or two - however the jist of the logic is above, if anyone wants to experiment on their own.
NOTE: The code is very simple and experimental and expects the pc address to be known before hand to massage the .s file appropriately.
NOTE: The above algo with the corresponding .s file is still EXPERIMENTAL and also requires additional shell scripts to get access to the boot flow to trigger the hijack. And the current code will break the nooktab booting, so don't experiment this logic and the .s file unless you know what you are doing.
NOTE: I am not that much into Custom Roms etc, so don't expect anything much shortly wrt Custom Roms etc, this is just a experimentation for myself and to feel happy inspite of BN removing some useful features like sideloading as well as forcing a signed bootloader on everyone.
can you make a 2-init zip like on the milestone
http://forum.xda-developers.com/showthread.php?t=998425
because then the devs can go on and make a recovery
Bit more exploration with init hijacking - 2ndihkvc src package for EXPERIMENTATION
Hi,
NOTE: Source code package is attached with this message. However this is WIP and provided for anyone wanting to EXPERIMENT on their own parallel to me. Because I think the basic logic is done now. It is more of cleaning up the init rc files and or killing some additional tasks before restarting init or some such things HOPEFULLY (NO harm in hoping and being positive . HOWEVER NOTE that the current version will loop your boot and fail. I have put a timed triggering logic to try and reduce the risk, check out the documents in the package, but it can factory reset or worst case wipe your partitions and render the nooktab dead.
After yesterdays initial init hijacking, I have cleaned up the .s file so that it passes the Args properly as well as added the environment variables set by Android by default. Also the ptrace code I have updated to do relocation (using a simple custom table) of injected code. Also rather than a minimal ptrace code, I have put a bit more full fledged one with my logic as well as skrilax's logic as well as reg dumping and few other stuff to help experimenters.
In turn I have cross verified, that init is actually getting restarted and it is running thro the scripts and setting up the properties as specified by my modified default.prop as well as in the process rerunning all the commands/services/prgs.
However some where beyond rild/vold sequence it seems to be blocking and looping the boot. Also I had modified the init a bit, have to check that also once later.
Enjoy and experiment
NOTE: Not sure how to avoid having to put the same message in two threads. I created this thread only becasue the original thread was in the wrong category (i.e non development), when it should have been in development also.
This is interesting. I have minimal experience with assembly, none of it ARM. I would like to help, if possible. I appreciate the work you have put into this. I'm really hoping to be able to have CM7 on this tablet eventually.
Sent from my BNTV250 using xda premium
Potentially working Alternate Userspace in uSD using 2ndihkvc
Hi All,
I have updated my 2ndihkvc package a bit more and now you can boot into a ALTERNATE Android user space in uSD (NOTE: Userspace only and not kernel - locked bootloader doesn't allow alternate kernel).
For this you require to copy your required android /system and /data partitions into a MicroSD card in its 2nd and 3rd partitions which should be ext4 (specified in the init.omap4430.rc file in 2ndihkvc directory).
NOTE: Best way of getting a working /system and /data partitions is to ==> After rooting your Nook and removing all unwanted Apps/Junk, make a copy of the /system partition from eMMC to uSD. Same for /data/partition. Then you can copy what ever additional applications you want in this uSD based Android /system/app or /data/app partition. Thus you can have different sets of Android user space in different uSD cards.
Follow the instructions in INSTALL file for experimenting this on your rooted NookTab. BUT REMEMBER IT IS STILL EXPERIMENTAL. ALSO as a SAFETY FEATURE, as of now it will boot into this ALTERNATE MODE (in uSD) only when the current HOUR is specified in the start2ndihkvc.sh file appropriately. Otherwise it tries to boot into the your normal Andorid system in eMMC. This should hopefull CATCH any mistake, BUT THIS IS NOT GUARENTEED AND THIS IS A DANGEROUS THING TO EXPERIMENT, UNLESS YOU KNOW WHAT YOU ARE DOING.
NOTE: One time it did reboot from my alternate android system, I haven't debugged this yet, as it has not occured after it (Well I have tried only once more) so cann't say one way or the other yet. But definitely, there are some corner cases.
NOTE: If something gets messed up or if something is different or even if there is some corner case in my code, which I haven't handled yet, it may MESS UP your NOOK TAB so EXPERIMENT WITH THIS only if you know how to recover on your own, provided the NOOKTAB is recoverable (90% should be, but NO GAURENTEE).
Now the BRAVE HEARTS can experiment and Enjoy a alternate Andorid system in uSD card.
NOTE: With this one should be able to boot into any Custom ROM after suitable updation of the scripts in my zip file, as well as by copying their /system and /data/ partitions into uSD 2nd and 3rd partitions. AS long AS that Custome ROM doesn't have any specific kernel requirements.
BYPASS Kernel and Ramdisk check for People with UART ACCESS
Hi,
NOTE: THis is based on a initial look at the source code and then the objdump of u-boot.bin. I haven't cross checked this yet, because for now I haven't opened up the nooktab for uart access yet. Also this assumes by default booti command is used for booting in BN uboot. If some one wants to use bootm, then a different location requires to be patched wrt the image loading security check.
If you are a lucky ;-) person working with opened up NookTab with UART access, then basically replacing the memory contents of these two offsets with NOP will 90% BYPASS the security check successfully and allow you to boot a MODIFIED KERNEL or RAMDISK as required.
All offsets specified Assuming u-boot is loaded at 0 (adjust for the actual address where u-boot.bin is loaded, haven't looked into that yet).
Check for Security check of Kernel image is at
[ORIG] 0x48c0 => bne 0x48d8 (0x1a00.0004)
Make this a NOP by overwriting using uboot memory write command to
[MODI] 0x48c0 => mov r0, r0 (0xe1a0.0000)
Check for Security check of RAMDisk image is at
[ORIG] 0x4928 => bne 0x4958 (1a00.000a)
Make this a NOP by overwriting with
[MODI] 0x4928 => mov r0, r0 (0xe1a0.0000)
Someone (Hi Adamoutler, maybe you) with opened up NookTab can try this and tell me if it worked or not.
NOTE: you have to add up the actual u-boot load address to the offsets specified.
UPDATE1: It appears the load address is either
Possibility 1) 0x80e8.0000 OR
Possibility 2) 0x80e8.0000-0x120 (More likely).
Have to dig thro bit more, but one of these two will potentially work.
So that means to NOP RAMDisk security check the offset is
Possibility 1 ==> 0x80e8.0000+0x4928
Possibility 2 ==> 0x80e8.0000-0x120+0x4928 (More likely)
Best is to cross check if the resultant address contains the BNE instruction bytes specified above.
Same concept applies for the Kernel security check Nopping offset.
NOTE: It appears there is a 0x120 size header before the actual u-boot.bin code starts and in turn, when I did the objdump, it included the 0x120 bytes of header also assumed as code. And inturn the full (including the header) u-boot.bin or for that matter the u-boot from emmc seems to load into 0x80e8.0000-0x120.
UPDATE 2:
Code around the locations to be noped to help identify the same in memory, in case my offset calculations are wrong
48b4: eb0030f1 bl 0x10c80
48b8: e59d3010 ldr r3, [sp, #16]
48bc: e3530000 cmp r3, #0
48c0: 1a000004 bne 0x48d8
48c4: e59f0104 ldr r0, [pc, #260] ; 0x49d0
48c8: e594100c ldr r1, [r4, #12]
48cc: e5942008 ldr r2, [r4, #8]
48d0: eb0015db bl 0xa044
............
491c: eb0030d7 bl 0x10c80
4920: e59d3010 ldr r3, [sp, #16]
4924: e3530000 cmp r3, #0
4928: 1a00000a bne 0x4958
492c: e59f00a4 ldr r0, [pc, #164] ; 0x49d8
4930: e5941014 ldr r1, [r4, #20]
4934: e5942010 ldr r2, [r4, #16]
4938: eb0015c1 bl 0xa044
UPDATE 3: ... for a rainy day in future ;-)
UPDATE 4: For maximum success, first try a changed RAMDisk rather than Changed Kernel. If Changed Ramdisk works then try Changed Kernel (THere is one more thing in Code, which I am not sure if it will impact a modified kernel or not yet, only way is to experiment).
How can I run 2ndihkvc just to load a new default.prop using the existing userspace? What I did so far was to remount / in rw, updated default.prop, pushed 2ndihkvc to /data/local/, changed permissions to 755 and executed. Here is the output
Code:
# ./2ndihkvc -p 1 -w 0 -c 0 -m 2
INFO:2ndihkvc:v30Dec_2020:
INFO:2ndihkvc: Tracing process with pid = 1
INFO:2ndihkvc: NewPrg = /init
WARN: RESPECT_WAIT disabled
WARN: Mode = MODE_INJECT_HKVC2
INFO: ContType = CONTINUE
INFO:2ndihkvc:PTRACE: Attached to (1)
INFO:2ndihkvc: Giving 2 secs to the likely traced process
ERROR:2ndihkvc:WAIT:Failed (No child processes)
INFO:2ndihkvc:hkvc2: InjectAddr (Regs->ARM_pc) = 0xffff0520
INFO:2ndihkvc:hkvc2: /init found at offset 0x100
INFO:2ndihkvc:hkvc2:ProgramToExecute: /init replaced with /init
INFO:2ndihkvc:hkvc2: At offset 0x208 relocating from 0x100 to 0xffff0620
INFO:2ndihkvc:hkvc2: At offset 0x200 relocating from 0x208 to 0xffff0728
INFO:2ndihkvc:hkvc2: At offset 0x280 relocating from 0x288 to 0xffff07a8
INFO:2ndihkvc:hkvc2: At offset 0x288 relocating from 0x300 to 0xffff0820
INFO:2ndihkvc:hkvc2: At offset 0x28c relocating from 0x307 to 0xffff0827
INFO:2ndihkvc:hkvc2: At offset 0x290 relocating from 0x312 to 0xffff0832
ERROR:PTRACE:POKE failed at location ffff0520
INFO:2ndihkvc:PTRACE: Continue/SingleStep ...
INFO:2ndihkvc: Detaching...
ERROR:2ndihkvc:PTRACE: Failed DETACH (No such process)
#
Do I need to push your init to /system/2ndihkvc/init? I am just trying to play around with it and Adam's BHT just to see what I can do them. Thanks.
Hi Brianf21,
As specified in the INSTALL file with in my zip
Copy my 2ndihkvc.zip file to /data/local/tmp
Then mount /system in rw mode.
Next unzip 2ndihkvc.zip into /system. It should create 2ndihkvc folder.
Next run ./install.sh from with in 2ndihkvc folder.
This will setup the boot process to start into 2ndihkvc. And it inturn will restart init with new set of init.*.rc as well as default.prop files.
Have a look at the 2ndihkvc folder, it already contains a default.prop file. If you want to change anything in default.prop then do the changes in this default.prop in /system/2ndihkvc folder.
Also remember to change the time check in start2ndihkvc.sh file in /system/2ndihkvc folder to the current hour, when you will be experimenting. Otherwise, it will not run 2ndihkvc, but continue with the normal Android init flow.
Cross check my INSTALL file once again for the details/steps to setup 2ndihkvc.
Once you have done the above. When you restart your system, it will trigger 2ndihkvc as required and the default.prop will be the new one which you would have edited/updated in /system/2ndihkvc/ folder.
NOTE: Looking at the address, it seems like you had tried 2ndihkvc once before in the same session. Try following the install step specified above/In the 2ndihkvc zip file and see. There is a minimally modified version of init.omap4430.rc and default.prop already in the 2ndihkvc folder, modify those if you want to modify them. This is because start2ndihkvc.sh will copy these files from /system/2ndihkvc/ folder when it is run to restart init.
I will have to read more, to avoid setting up system and data up on an sdcard. Once the setup is done, will it always hijack init for every following boot until it is removed or only one reboot? i am just to get a clearer picture of what's going on, I wanted to just see the hijack of init work independently of the other processes.. I kind of like to break things down into parts so I can get a better understanding of the entire process. Thanks for the work you've out in so far.
hkvc said:
Hi Brian21,
As specified in the INSTALL file with in my zip
Copy my 2ndihkvc.zip file to /data/local/tmp
Then mount /system in rw mode.
Next unzip 2ndihkvc.zip into /system. It should create 2ndihkvc folder.
Next run ./install.sh from with in 2ndihkvc folder.
This will setup the boot process to start into 2ndihkvc. And it inturn will restart init with new set of init.*.rc as well as default.prop files.
Have a look at the 2ndihkvc folder, it already contains a default.prop file. If you want to change anything in default.prop then do the changes in this default.prop in /system/2ndihkvc folder.
Also remember to change the time check in start2ndihkvc.sh file in /system/2ndihkvc folder to the current hour, when you will be experimenting. Otherwise, it will not run 2ndihkvc, but continue with the normal Android init flow.
Cross check my INSTALL file once again for the details/steps to setup 2ndihkvc.
Once you have done the above. When you restart your system, it will trigger 2ndihkvc as required and the default.prop will be the new one which you would have edited/updated in /system/2ndihkvc/ folder.
NOTE: Looking at the address, it seems like you had tried 2ndihkvc once before in the same session. Try following the install step specified above/In the 2ndihkvc zip file and see. There is a minimally modified version of init.omap4430.rc and default.prop already in the 2ndihkvc folder, modify those if you want to modify them. This is because start2ndihkvc.sh will copy these files from /system/2ndihkvc/ folder when it is run to restart init.
Click to expand...
Click to collapse
brianf21 said:
I will have to read more, to avoid setting up system and data up on an sdcard. Once the setup is done, will it always hijack init for every following boot until it is removed or only one reboot? i am just to get a clearer picture of what's going on, I wanted to just see the hijack of init work independently of the other processes.. I kind of like to break things down into parts so I can get a better understanding of the entire process. Thanks for the work you've out in so far.
Click to expand...
Click to collapse
If all you are interested is run 2ndihkvc with a modified default.prop but no other modification (i.e no uSD /system and /data partitions), then
a) overwrite the init.omap4430.rc in /system/2ndihkvc with the one in / . However if you have already booted into a system with 2ndihkvc then in /data/local/tmp.
Or if required you can directly edit the init.omap4430.rc in /system/2ndihkvc and update the mount commands in there to mount from emmc instead of uSD.
b) Remove the 2 lines in restart-userspace.sh corresponding to mount -o move ....
This will allow you to boot into a system with a modified default.prop but no other change from a runtime perspective (unless I have forgotten something).
Also 2ndihkvc will be applied each time boot into NookTab provided the current hour matches the hour set in start2ndihkvc.sh. Once the current hour no longer matches the hour set in the sh file, it will boot into the normal BN Nooktab environment.
NOTE: I purposefully modified the init.omap4430.rc file to replace the /system and /data from emmc to uSD, so that if someone is experimenting something, he doesn't corrupt the emmc easily as long as he doesn't become root user. HOWEVER with root access emmc can still get corrupted if one is not careful, because eMMC is still available and mounted.
tried but rebooted few times until factory reset kicked in
Hi,
ok. maybe a bit too optimistic, but I compiled ICS for pandaboard and put the system to sd card (partition 1 ext4 empty, partion 2 ext4 system with panda stuff, partion 3 data, partition 4 empty).
I hit adb reboot and the device booted a few times until it restored factory. Uff.
Is there a way without serial console to see what happens?
There's also small glitch in install.sh. It doesn't find init.rc in /system/2ndihkvc.
Rgds,
Chris
chrmhoffmann said:
Hi,
The device booted a few times until it restored factory. Uff.
Click to expand...
Click to collapse
If it's counting boots like the Nook Color you can stop it by running this (if the rom partition is mounted at /rom-- it's p2 on nc and I guess p5 on nt).
chrmhoffmann said:
Hi,
ok. maybe a bit too optimistic, but I compiled ICS for pandaboard and put the system to sd card (partition 1 ext4 empty, partion 2 ext4 system with panda stuff, partion 3 data, partition 4 empty).
I hit adb reboot and the device booted a few times until it restored factory. Uff.
Is there a way without serial console to see what happens?
There's also small glitch in install.sh. It doesn't find init.rc in /system/2ndihkvc.
Rgds,
Chris
Click to expand...
Click to collapse
Hi,
The missing init.rc is not a glitch, I purposefully left it out while packaging, so that one doesn't modify it drastically and botch up the boot. init.4430.rc is the only thing required to change the mount partitions.
Also if you are using my default start2ndihkvc.sh script, then it has a time check, so while xperimenting if you have goofed up. Just let the time you have set in this script pass by (i.e don't power on), then it will automatically go back to the stock NT boot, thus avoiding the factory reset.
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.