Related
>>> With UART access NookTab Secure BOOT Chain as been FULLY BROKEN, Custom Kernel and Custom Ramdisk have been succesfully run on NookTab, Look towards 2nd page or so for full info <<<
Hi,
Few days back I had got an idea to try and see if we can BYPASS the boot security chain by replacing the bootloader in memory, because NOOKTAB allows UART ACCESS to UBOOT.
My initial thought was to use a replacement UBOOT without Security checks. However on further thought, as UBOOT has memory access commands, I realised the simpler solution is to edit the UBOOT code directly in memory from UBOOT prompt itself.
In turn I had posted the concept and the commands to try and do the same on the below two threads, for people to try. However as no one seems to have tried it yet, I myself opened up the my NookTab and connected the UART signals and am continuing my experiments and the initial results are promising.
FINDING1: The MShield security logic doesn't mind if one modifies the UBOOT CODE. I was able to NOP the security check result logic check and the code continued to boot.
Next I have to try a modified RAMDisk and see it works fully.
My earlier posts on this can be got from these two threads
http://forum.xda-developers.com/showthread.php?t=1378886
http://forum.xda-developers.com/showthread.php?t=1418172
For someone interested in experimenting with this below are the commands to try on UART of NOOKTAB.
uboot Command summary
---------------------------------------
md.l address_in_Hex ---------- To cross check the memory content before overwriting (should match what I have mentioned as ORIG)
mw.l address_in_Hex 4ByteValueInHex -------------- To modify the given address location with new value
md.l address_in_Hex -------------- To cross check that the new value you have written has come properly.
Command sequence for Ramdisk check bypassing
-----------------------------------------------------------------------------
UBOOTPROMT> md.l 80e84808 ----- This should show 1a00000a
NOTE: I have verified that the 2nd possibility mentioned in my earlier post i.e 0x80e8.0000-0x120 is the load address to use to calculate the offsets.
next run
UBOOTPROMPT> mw.l 80e84808 e1a00000 ------------- This modify with NOP
Next run
UBOOTPROMPT> md.l 80e84808 ------ should show e1a00000
Next if you have updated the recovery.img with new ramdisk into /recovery partition RUN
UBOOTPROMPT> mmcinit 1; booti mmc1 recovery
HOWEVER instead if you have updated the flashing_boot.img file with new ramdisk in microSD then RUN
UBOOTPROMPT> mmcinit 0; fatload mmc 0:1 0x81000000 flashing_boot.img; booti 0x81000000
Now it should boot with out giving a signature error.
NOTE1: I have verified that changing the contents of UBOOT (i.e NOPing) in itself doesn't lock the ARM, next I have to try a updated ramdisk and see what happens. If you ask me It should work, fingers crossed, I will try and update.
NOTE2: In any android img file at offset 0x10 (i.e 16) the ramdisk size is stored as a 4 byte (long) value. Cross verify first that the original img and the ramdisk size at offset 0x10 in it matches the original ramdisk. Then update the 0x10 offset of new img file with new ramdisk's size.
NOTE3: kernel security check bypass address = '0x80e847a0'
[REPOSTING OLD, CONCEPT] BYPASS Kernel and Ramdisk check for People with UART ACCESS
**************************
>>> This was my original post to the other two threads on this concept, I have put this here for completeness. The load address confusion which I had is already resolved <<<
****************************
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).
UPDATE 5: I have cross verified on the target with UART access and the 2nd possibility mentioned above wrt load address is what is correct.
android img header structure for reference
from tools/mkbootimg/bootimg.h
#define BOOT_MAGIC "ANDROID!"
#define BOOT_MAGIC_SIZE 8
#define BOOT_NAME_SIZE 16
#define BOOT_ARGS_SIZE 512
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 unused[2]; /* future expansion: should be 0 */
unsigned char name[BOOT_NAME_SIZE]; /* asciiz product name */
unsigned char cmdline[BOOT_ARGS_SIZE];
unsigned id[8]; /* timestamp / checksum / sha1 / etc */
};
PARTIAL SUCCESS BYPASSING SEC CHECK using NOP
Hi
By BYPASSING both the Kernel and Ramdisk checks using NOPs, I am able to run the kernel (not modified, but repackaged, so bypassed Kernel sec check) and modified ramdisk.
However either
a) I seem to have done something wrong OR
b) Secure boot chain is doing something internally before passing control to uboot during kernel sec check, which is different between a successful call and a bad call.
Because the kernel crashes after control passes to it, almost immidiately.
NOTE: Have to try with only ramdisk change ...
The UART Dump of my run is given below.
OMAP44XX SDP # booti 0x81000000
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
kernel @ 80088000 (2689312)
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
ramdisk @ 81080000 (513429)
Initrd start : 81080000 , Initrd end : 810fd475Acclaim Board.
Starting kernel ...
undefined instruction
pc : [<800886e4>] lr : [<80e930c0>]
sp : 80e3fac4 ip : 00028f05 fp : 80eabe44
r10: 810fd475 r9 : 80eb1fb8 r8 : 80e3ffdc
r7 : 80088000 r6 : 00000000 r5 : 80e3ffb4 r4 : 80eb1fb8
r3 : 00000000 r2 : 80000100 r1 : 00000e18 r0 : 00000000
Flags: nZCv IRQs off FIQs on Mode SVC_32
Resetting CPU ...
NOTE: This requires UART access to NookTab.
UPDATE 1: I found one mistake in that the unpack tool was always using a fixed size 2048 for page size rather than 4096 in the BN recovery.img, I fixed it and repackaged the new set of files and now even thou success eludes me, I find that this time it didn't give a SEC ERROR for my modified ramdisk !?!?!? But it was slower with the checks this time.
OMAP44XX SDP # booti 0x81000000
kernel @ 80088000 (2687264)
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
ramdisk @ 81080000 (513416)
Initrd start : 81080000 , Initrd end : 810fd468Acclaim Board.
Starting kernel ...
SUCCESS SUCCESS SUCCESS with Modified Ramdisk
Hi All,
SHORT form for impatient people
-------------------------------------------------
OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.recovery.img;
OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; md.l 80e84808 1; md.l 80e847a0 1
OMAP44XX SDP # booti 0x81000000
LONG form for people who want bit more details
---------------------------------------------------------------------
I have been able to boot into a modified recovery image using my NOP based BYPASS logic for secure boot chain.
What I learnt in the process are
a) Secure boot chain logic doesn't bother if we change the UBoot / XYZ code space Key to any logic using/manipulating the memory of the NookTab from uboot.
b) The Android img images for BN NookTab contain
b.1) The standard 2K Android header (nothing special from BN in this).
However NOTE that pagesize is 4096 and a good base address (picked from recovery.img of factory.zip) is 0x80080000
b.2) The Kernel and the Ramdisk images with in the android img file in turn contain 0x120 Byte headers individually
b.3) The Secure Boot chain seems to be particular about these 0x120 byte headers
Even for my modified ramdisk, I had to use the original ramdisks' BN Header. Otherwise the security check seemed to take a hell lot of time most of the time and the end results were touchy (Have to debug this further ..., ALSO THERE IS THE OPTION OF AVOIDING THE SEC_ENTRY call in the FIRST PLACE ITSELF TO TRY AND BYPASS THIS, IF REQUIRED, I have to experiment this later).
So if one is using a tool which searchs for the GZIP MAGIC to decide where to split the img file into strictly two parts consisting of
dump_1) Android_Image_Header+Kernel_BNHeader+Kernel+Ramdisk_BNHeader and
dump_2) Ramdisk file
are fine.
However if one is using a program which uses the Android image header structure to dump the contents need to be careful to extract the BN header from the corresponding ramdisk file and then after manipulating/modifying the ramdisk file, RE PREPEND the BN header back to the ramdisk. Before clubing/joining all the files together.
Or tools which assume wrong pagesize (some I found used 2K page size instead of picking from android header) or which split the constituents into individual parts intelligently (which by the way will discard the BN Header potentially) will have to be MODIFIED before using.
I ended up writing my own c code to dump using Android header and inturn use shell script to extract the BN Header for safe keeping before merging everything back later. I will post the code and simple shell scripts in a day or two.
BELOW is the OUTPUT OF MY SUCESSFUL RUN with MODIFIED RAMDISK
--------------------------------------------------------------------------------------------------------------------
OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.hdr.img;
3207168 bytes read
OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; md.l 80e84808 1; md.l 80e847a0 1
80e84808: 1a00000a ....
80e847a0: 1a000004 ....
80e84808: e1a00000 ....
80e847a0: 1a000004 ....
OMAP44XX SDP # booti 0x81000000
kernel @ 80088000 (2682952)
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
ramdisk @ 81080000 (513707)
Initrd start : 81080000 , Initrd end : 810fd58bAcclaim Board.
Starting kernel ...
Linux version 2.6.35.7 ([email protected]) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 SMP PREEMPT Fri Nov 11 12:35:42 PST 1
CPU: ARMv7 Processor [411fc093] revision 3 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP4430 ACCLAIM
Memory policy: ECC disabled, Data cache writealloc
...........
That all looks very good and sounds extremely promising
So in the realms of being able to boot modified roms where does this put us?
Uses of this method and its merits/demerits or needs/no needs
Hi Celtic/All,
*** The only places I see a meaningful use for this is mentioned towards the end, otherwise, I am working on this mainly for the fun of exploration. In most other cases where one thinks one needs this, I can tell you It can be achieved with out this, except for some exotic things which don't affect majority of users ***
My thoughts on ROMs with different complexities
------------------------------------------------------------------------
If a modified ROM is not using (doesn't need) custom Kernel or custom Ramdisk, then my 2ndihkvc or any other working 2nd-init method is the simple and straight forward way of doing a custom rom.
If it however requires a custom Ramdisk, then this NOP based BYPASS method will allow one to achieve the same. However I don't see any need for anyone to use a custom ramdisk. If someone is using a custom ramdisk, It can be 98% modified to use the generic 2nd-init method and in case of NookTab my simple 2ndihkvc method (As documented in my other thread, the default 2nd-init logic fails on NookTab as it uses ONE too many PTRACE calls).
If it requires a custom Kernel then with bit more work on this I don't see why a Custom kernel cann't be booted.
However if you ask me, we don't gain much with a custom kernel or ramdisk, which cann't be achieved using root access and or module loading support in default kernel, and inturn REMEMBER that both of these can be done on NookTab today (i.e 1. Root access and 2. Module loading).
Also NOTE that this requires UART access.
*** ONE PLACE WHERE THIS CAN HELP *** is, with BN 1.4.1 firmware, which has blocked the current rooting method If I am not wrong (Unless someone has found a way to break it recently, which I have missed). For 1.4.1, with this, we can boot into a specific custom recovery image and modify the /system partition, such that we put su and SuperUser back into it under /system/bin (with proper chmod settings) and /system/app, so that we can gain Root access again, on rebooting into the NookTAB normally after this change.
*** Another place *** is when the device is very old and the new kernel can bring in some feature missing badly in a very old device. Again in many of these cases, if one puts sufficient effort the feature may be back portable and or injectable into a older kernel using the module route.
REMEMBER IN LINUX - KERNEL MODULE IS SAME AS KERNEL as far as PRIVILAGES are concerned, as it stands TODAY, all LIMITS IF ANY are ARTIFICIAL.
HOPE THAT HELPS
I love reading these threads even though I don't fully understand everything going on in the code parts.
I'm interested in custom kernels because as far as I know there's no way to get ICS running on the Tab without one.
Nexus S 4G 4.0.3
I honestly dont know much about creating custom ROM's but I have been wondering why every thinks that we have to have the bootloader unlocked before we can get any type of custom ROM. I have a Moto X2. The bootloader is not and never will be unlocked but I am running a really sweet custom ROM on it. I know from other android phones that a ROM is possible with a locked bootloader.
My point is...I am glad to see someone working around this and taking the next step. I was wondering if DEV's have almost given up on the NT. Thank you for your work!
Rooting 1.4.1
hkvc said:
... BN 1.4.1 firmware, which has blocked the current rooting method If I am not wrong (Unless someone has found a way to break it recently, which I have missed).
Click to expand...
Click to collapse
See my method at http://forum.xda-developers.com/showthread.php?t=1413734 (since Dec 27)
Note that my method starts with either a rooted or (preferably) unrooted copy of 1.4.0, roots it if necessary, modifies it slightly, updates to 1.4.1, and then regains root. Requires ADB/USB access.
POTENTIAL SUCCESS with CUSTOM KERNEL (INDIRECT METHOD)
Hi All,
In SHORT for impatient
---------------------------------
OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.hdr.img;
OMAP44XX SDP # md.l 80e84794 1; md.l 80e847fc 1; mw.l 80e84794 e1a00000; mw.l 80e847fc e1a00000; md.l 80e84794 1; md.l 80e847fc 1
OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; mw.l 80e847a0 e1a00000; md.l 80e84808 1; md.l 80e847a0 1
OMAP44XX SDP # booti 0x81000000
(c) HKVC, GPL ;-)
The sufficient minimal Details
-------------------------------------
I have verified that NOT CALLING SEC_ENTRY calls, with in uboot, related to kernel and ramdisk check keeps things smooth. That should mean the FLOOD GATES are POTENTIALLY OPEN for CUSTOM KERNELs with UART ACCESS.
This requires few additional NOPs compared to what I had originally specified (My original set of NOPs had some issue with Kernel booting, which I have to debug later, however this work around seems to resolve it - I don't want to delve more into this than what I have already specified here, unless Secure Bootloader people get any ideas ;-).
UART Boot Dump/log
-------------------------
OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.hdr.img;
3207168 bytes read
OMAP44XX SDP # md.l 80e84794 1; md.l 80e847fc 1; mw.l 80e84794 e1a00000; mw.l 80e847fc e1a00000; md.l 80e84794 1; md.l 80e847fc 1
80e84794: eb0030f1 .0..
80e847fc: eb0030d7 .0..
80e84794: e1a00000 ....
80e847fc: e1a00000 ....
OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; mw.l 80e847a0 e1a00000; md.l 80e84808 1; md.l 80e847a0 1
80e84808: 1a00000a ....
80e847a0: 1a000004 ....
80e84808: e1a00000 ....
80e847a0: e1a00000 ....
OMAP44XX SDP # booti 0x81000000
kernel @ 80088000 (2682952)
ramdisk @ 81080000 (513707)
Initrd start : 81080000 , Initrd end : 810fd58bAcclaim Board.
Starting kernel ...
Linux version 2.6.35.7 ([email protected]) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 SMP PREEMPT Fri Nov 11 12:35:42 PST 2011
CPU: ARMv7 Processor [411fc093] revision 3 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP4430 ACCLAIM
Memory policy: ECC disabled, Data cache writealloc
On node 0 totalpages: 245760
And if the merge bootloader of the nook color and from nook tablet, compare it and try to create one substitution?
DeanGibson said:
See my method at http://forum.xda-developers.com/showthread.php?t=1413734 (since Dec 27)
Note that my method starts with either a rooted or (preferably) unrooted copy of 1.4.0, roots it if necessary, modifies it slightly, updates to 1.4.1, and then regains root. Requires ADB/USB access.
Click to expand...
Click to collapse
Hi DeanGibson,
Thanks for your efforts on that. It should help people who get bumped into 1.41 by BN.
HOWEVER Do note that if the uSD based MLO and u-boot.bin gets loaded first before the ones in eMMC by the internal boot rom of the Omap (Should be the case based on what Pokey had mentioned sometime back, I haven't cross checked myself yet, as I have been busy with these stuff which I am looking into). Then what ever (except for one cavet - which I wont mention here) BN may do in a future update, with the UART based u-boot method which I have mentioned in this thread, one will always be able to get root access to the device.
OMG hkvc, between you, DG, and AO how can the NT win?
You guys are monsters! (in a good way)
Ok, little explaining before questioning is I'm not a tech guy. But from the all post of hkvc in this thread, the understanding that we can access more space in 16GB internal storage and custom ROM/kernel is on the way is correct?
camapghe said:
Ok, little explaining before questioning is I'm not a tech guy. But from the all post of hkvc in this thread, the understanding that we can access more space in 16GB internal storage and custom ROM/kernel is on the way is correct?
Click to expand...
Click to collapse
This requires repartitioning the drive, which we are not at this time confident, that it will not brick your nook by doing so. (This double negative actually is making a positive: Repartitioning might brick your nook.)
This hardware modification has nothing to do with accessing more of the space as that is entirely a software remedy. We're just not confident about how hard the Nook looks at the primary partition table.
SUCCESS SUCCESS SUCCESS with CUSTOM Kernel+ CUSTOM Ramdisk, UART NOP BYPASS
Hi All,
As I had mentioned yesterday/today early morning, By bypassing the SEC_ENTRY check I was able to run stock kernel with out any problem. And as I had mentioned then even thou it is a indirect way of verifying possibility of custom kernels, it should still open the flood gate for custom kernels (with UART access for NoW ;-).
Now I have actually verified by RUNNING a CUSTOM Kernel which I compiled along with a CUSTOM Ramdisk (with adb enabled - look at last few lines), which you can know from
a) the kernel version line while booting, which contains the machine used for compiling (Obviously I have redacted part of my name ;-),
b) as well as the size of the kernel and ramdisk images which is different from the stock img files, because this contains both a custom kernel as well as custom ramdisk from me.
SO IT IS SUCCESS with CUSTOM KERNELS+ CUSTOM RAMDISKS, using the uboot commands which I had mentioned in my older post.
UART DUMP including UBoot commands
--------------------------------------------------
OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.kr.img;
4157440 bytes read
OMAP44XX SDP # md.l 80e84794 1; md.l 80e847fc 1; mw.l 80e84794 e1a00000; mw.l 80e847fc e1a00000; md.l 80e84794 1; md.l 80e847fc 1
80e84794: eb0030f1 .0..
80e847fc: eb0030d7 .0..
80e84794: e1a00000 ....
80e847fc: e1a00000 ....
OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; mw.l 80e847a0 e1a00000; md.l 80e84808 1; md.l 80e847a0 1
80e84808: 1a00000a ....
80e847a0: 1a000004 ....
80e84808: e1a00000 ....
80e847a0: e1a00000 ....
OMAP44XX SDP # booti 0x81000000
kernel @ 80088000 (2693828)
ramdisk @ 81080000 (1455055)
Initrd start : 81080000 , Initrd end : 811e32afAcclaim Board.
Starting kernel ...
Linux version 2.6.35.7 ([email protected]) (gcc version 4.5.4 (Ubuntu/Linaro 4.5.3-9ubuntu1) ) #1 SMP PREEMPT Wed Jan 4 02:43:18 IST 2012
CPU: ARMv7 Processor [411fc093] revision 3 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP4430 ACCLAIM
Memory policy: ECC disabled, Data cache writealloc
On node 0 totalpages: 245760
..... Chopped ...............
omapfb omapfb: Unknown ioctl 0x40044620
init: Unable to open persistent property directory /data/property errno: 2
enabling adb
adb_open
android_usb gadget: high speed config #1: android
SO ALL OF YOU out there ITHCING to experiment with Custom Kernels and What not, Go ahead and enjoy the freedom to do so on NOOK TABLET (with UART access for NoW ;-)
My Android Img file manipulation scripts including few older ones by others.
Hi,
I am attaching the simple C program and the scripts which I use for extracting BN Android Imgs consisting of
a) Dumping the individual sections of Android img
b) Allow seperating the header from the actual Kernel or Ramdisk
c) Allow concatenating (This is kind of dummy, but required to take care of u-boot logic of loading) the old header with new Kernel or Ramdisk
d) Pass proper arguments to recreate the Android IMG file.
Also I have attached some of the other open source tools which I started with originally, but due to few things here and there and also to get maximum flexibility I moved to my own set of scripts and program.
recovery img with simple ramdisk with ADB and Root shell on Adb and console
Hi,
Attached is a recovery.img file with the standard Kernel from NookTab and a modified Ramdisk which has support for
a) ADB shell
b) Root shell access (Both ADB and Console)
c) Console is enabled in UART.
Note that the sh on the ramdisk is renamed busybox with a symbolic link called busybox pointing to this sh.
go into /system/bin and run
busybox --install /system/bin
So that you have the standard commands available on the recovery shell.
Also remember to run
export PATH=/system/bin:$PATH
I am following this thread, Congrats on your findings and thanks for your time you spent on it.
The latest update to 20f pushes the same unlock files to the phone as the (euro?) open kdz. That is the libunlock.so file. From what I see it appears that the phone checks the nv partition for the unlocked or locked "token" for the bootloader. I am trying to find out where in the nv partition this flag resides but I am not so good with this type of code. I will post some of the code (this is pertaining to the unlock checks) and im asking someone to help me figure out where this flag is so we can hex edit it and be done with this silly flashing back and forth to unlock. So here :
.text:0000098C EXPORT write_nv
.text:0000098C write_nv ; CODE XREF: bootloader_unlock_handler+F2p
.text:0000098C
.text:0000098C buf = -0x14
.text:0000098C
.text:0000098C PUSH {R0-R2,R4,R5,LR}
.text:0000098E MOV R5, R1
.text:00000990 STR R0, [SP,#0x18+buf]
.text:00000992 MOVS R1, #2 ; oflag
.text:00000994 LDR R0, =0x4E7
.text:00000996 ADD R0, PC ; "/dev/block/platform/omap/omap_hsmmc.1/b"...
.text:00000998 BLX open
.text:0000099C CMP R0, #0
.text:0000099E MOV R4, R0
.text:000009A0 BGE loc_9B0
.text:000009A2 LDR R1, =(aCanTOpenNvdata - 0x9AC)
.text:000009A4 MOVS R0, #3
.text:000009A6 MOV R2, R4
.text:000009A8 ADD R1, PC ; "Can't open NVDATA partition ret = %d \n"
.text:000009AA BL logger
.text:000009AE B loc_9CC
.text:000009B0 ; ---------------------------------------------------------------------------
.text:000009B0
.text:000009B0 loc_9B0 ; CODE XREF: write_nv+14j
.text:000009B0 MOVS R2, #0 ; whence
.text:000009B2 MOV R1, R5 ; offset
.text:000009B4 BLX lseek
.text:000009B8 CMP R0, #0
.text:000009BA BGE loc_9D0
.text:000009BC LDR R1, =(aCannotSeekToRe - 0x9C2)
.text:000009BE ADD R1, PC ; "Cannot seek to real block device footer"...
.text:000009C0
.text:000009C0 loc_9C0 ; CODE XREF: write_nv+56j
.text:000009C0 MOVS R0, #3
.text:000009C2 BL logger
.text:000009C6 MOV R0, R4 ; fd
.text:000009C8 BLX close
.text:000009CC
.text:000009CC loc_9CC ; CODE XREF: write_nv+22j
.text:000009CC MOVS R0, #0
.text:000009CE B locret_9EC
.text:000009D0 ; ---------------------------------------------------------------------------
.text:000009D0
.text:000009D0 loc_9D0 ; CODE XREF: write_nv+2Ej
.text:000009D0 MOVS R2, #4 ; n
.text:000009D2 MOV R0, R4 ; fd
.text:000009D4 ADD R1, SP, #0x18+buf ; buf
.text:000009D6 BLX write
.text:000009DA CMP R0, #0
.text:000009DC BGE loc_9E4
.text:000009DE LDR R1, =(aCanTReadUnlock - 0x9E4)
.text:000009E0 ADD R1, PC ; "Can't read unlock bit.\n"
.text:000009E2 B loc_9C0
.text:000009E4 ; ---------------------------------------------------------------------------
.text:000009E4
.text:000009E4 loc_9E4 ; CODE XREF: write_nv+50j
.text:000009E4 MOV R0, R4 ; fd
.text:000009E6 BLX close
.text:000009EA MOVS R0, #1
.text:000009EC
.text:000009EC locret_9EC ; CODE XREF: write_nv+42j
.text:000009EC POP {R1-R5,PC}
.text:000009EC ; End of function write_nv
.text:000009EC
I can go to any function or bit of code you need. I've reverse engineered this file.
omgbossis21 said:
The latest update to 20f pushes the same unlock files to the phone as the (euro?) open kdz. That is the libunlock.so file. From what I see it appears that the phone checks the nv partition for the unlocked or locked "token" for the bootloader. I am trying to find out where in the nv partition this flag resides but I am not so good with this type of code. I will post some of the code (this is pertaining to the unlock checks) and im asking someone to help me figure out where this flag is so we can hex edit it and be done with this silly flashing back and forth to unlock. So here :
.text:0000098C EXPORT write_nv
.text:0000098C write_nv ; CODE XREF: bootloader_unlock_handler+F2p
.text:0000098C
.text:0000098C buf = -0x14
.text:0000098C
.text:0000098C PUSH {R0-R2,R4,R5,LR}
.text:0000098E MOV R5, R1
.text:00000990 STR R0, [SP,#0x18+buf]
.text:00000992 MOVS R1, #2 ; oflag
.text:00000994 LDR R0, =0x4E7
.text:00000996 ADD R0, PC ; "/dev/block/platform/omap/omap_hsmmc.1/b"...
.text:00000998 BLX open
.text:0000099C CMP R0, #0
.text:0000099E MOV R4, R0
.text:000009A0 BGE loc_9B0
.text:000009A2 LDR R1, =(aCanTOpenNvdata - 0x9AC)
.text:000009A4 MOVS R0, #3
.text:000009A6 MOV R2, R4
.text:000009A8 ADD R1, PC ; "Can't open NVDATA partition ret = %d \n"
.text:000009AA BL logger
.text:000009AE B loc_9CC
.text:000009B0 ; ---------------------------------------------------------------------------
.text:000009B0
.text:000009B0 loc_9B0 ; CODE XREF: write_nv+14j
.text:000009B0 MOVS R2, #0 ; whence
.text:000009B2 MOV R1, R5 ; offset
.text:000009B4 BLX lseek
.text:000009B8 CMP R0, #0
.text:000009BA BGE loc_9D0
.text:000009BC LDR R1, =(aCannotSeekToRe - 0x9C2)
.text:000009BE ADD R1, PC ; "Cannot seek to real block device footer"...
.text:000009C0
.text:000009C0 loc_9C0 ; CODE XREF: write_nv+56j
.text:000009C0 MOVS R0, #3
.text:000009C2 BL logger
.text:000009C6 MOV R0, R4 ; fd
.text:000009C8 BLX close
.text:000009CC
.text:000009CC loc_9CC ; CODE XREF: write_nv+22j
.text:000009CC MOVS R0, #0
.text:000009CE B locret_9EC
.text:000009D0 ; ---------------------------------------------------------------------------
.text:000009D0
.text:000009D0 loc_9D0 ; CODE XREF: write_nv+2Ej
.text:000009D0 MOVS R2, #4 ; n
.text:000009D2 MOV R0, R4 ; fd
.text:000009D4 ADD R1, SP, #0x18+buf ; buf
.text:000009D6 BLX write
.text:000009DA CMP R0, #0
.text:000009DC BGE loc_9E4
.text:000009DE LDR R1, =(aCanTReadUnlock - 0x9E4)
.text:000009E0 ADD R1, PC ; "Can't read unlock bit.\n"
.text:000009E2 B loc_9C0
.text:000009E4 ; ---------------------------------------------------------------------------
.text:000009E4
.text:000009E4 loc_9E4 ; CODE XREF: write_nv+50j
.text:000009E4 MOV R0, R4 ; fd
.text:000009E6 BLX close
.text:000009EA MOVS R0, #1
.text:000009EC
.text:000009EC locret_9EC ; CODE XREF: write_nv+42j
.text:000009EC POP {R1-R5,PC}
.text:000009EC ; End of function write_nv
.text:000009EC
I can go to any function or bit of code you need. I've reverse engineered this file.
Click to expand...
Click to collapse
nv contains very little data, why not dump 10g , 20f and euro open and compare what going on
Lelus said:
nv contains very little data, why not dump 10g , 20f and euro open and compare what going on
Click to expand...
Click to collapse
Yes I've already examined the nv partition from 20f on my phone. I will flash to 10g and pull it now. Just hoping someone understood the coding a bit better than me and could tell me where abouts to look in the nv partition.
Im assuming its in this bit here :
.........LGP769A
T-01-V20d-310-26
0-MAR-16-2013+00
omgbossis21 said:
Yes I've already examined the nv partition from 20f on my phone. I will flash to 10g and pull it now. Just hoping someone understood the coding a bit better than me and could tell me where abouts to look in the nv partition.
LGP769A
T-01-V20d-310-26
0-MAR-16-2013+00
Click to expand...
Click to collapse
310-260 are t-mobile network codes
Keep in mind that non of 769 stock kernels allow passing "oem-unlock" or "bootloader" command to uboot during the reboot and that's the reason why phones just reboot.
Lelus said:
310-260 are t-mobile network codes
Keep in mind that non of 769 stock kernels allow passing oem-unlock or bootloader to uboot during the reboot and that's the reason why phones just reboot.
Click to expand...
Click to collapse
My fault the last bit was from d and this one from f :
LGP769AT-01-V20d
-310-260-MAR-16-
2013+00.........
I just flashed a unlocked u and boot. Img to my phone. It did the same thing flashing the open kdz does, inverts the image and wonky touch screen. I wonder how we can clear the NV partition to reset the flag...
Sent from my LG-P769 using xda app-developers app
omgbossis21 said:
I just flashed a unlocked u and boot. Img to my phone. It did the same thing flashing the open kdz does, inverts the image and wonky touch screen. I wonder how we can clear the NV partition to reset the flag...
Sent from my LG-P769 using xda app-developers app
Click to expand...
Click to collapse
It looks to me like something prevents that unlock bit(token) form being generated or written to the nv.
Lelus said:
It looks to me like something prevents that unlock bit(token) form being generated or written to the nv.
Click to expand...
Click to collapse
I believe the token is definitely generated as their is a value for multiple boot loader states :
.text:00000CC2 loc_CC2 ; CODE XREF: main+8Ej
.text:00000CC2 MOVW R3, #0x2774
.text:00000CC6 CMP R5, R3
.text:00000CC8 BNE loc_CDC
.text:00000CCA LDR R5, =(asc_1008 - 0xCD2)
.text:00000CCC MOVS R0, #6
.text:00000CCE ADD R5, PC ; "---------------------------------------"...
.text:00000CD0 MOV R1, R5
.text:00000CD2 BL logger
.text:00000CD6 LDR R1, =(aDeviceUnlockIs - 0xCDC)
.text:00000CD8 ADD R1, PC ; "Device Unlock is permitted. But, unlock"...
.text:00000CDA B loc_D24
.text:00000CDC ; ---------------------------------------------------------------------------
.text:00000CDC
.text:00000CDC loc_CDC ; CODE XREF: main+ECj
.text:00000CDC MOVW R0, #0x277F
.text:00000CE0 CMP R5, R0
.text:00000CE2 BNE loc_CF6
.text:00000CE4 LDR R5, =(asc_1008 - 0xCEC)
.text:00000CE6 MOVS R0, #6
.text:00000CE8 ADD R5, PC ; "---------------------------------------"...
.text:00000CEA MOV R1, R5
.text:00000CEC BL logger
.text:00000CF0 LDR R1, =(aDeviceIsAlread - 0xCF6)
.text:00000CF2 ADD R1, PC ; "Device is already unlocked\n"
.text:00000CF4 B loc_D24
.text:00000CF6 ; ---------------------------------------------------------------------------
.text:00000CF6
.text:00000CF6 loc_CF6 ; CODE XREF: main+106j
.text:00000CF6 MOVW R2, #0x2AF8
.text:00000CFA CMP R5, R2
.text:00000CFC BNE loc_D10
.text:00000CFE LDR R5, =(asc_1008 - 0xD06)
.text:00000D00 MOVS R0, #6
.text:00000D02 ADD R5, PC ; "---------------------------------------"...
.text:00000D04 MOV R1, R5
.text:00000D06 BL logger
.text:00000D0A LDR R1, =(aBootloaderUnlo - 0xD10)
.text:00000D0C ADD R1, PC ; "Bootloader Unlock is prohibited\n"
.text:00000D0E B loc_D24
.text:00000D10 ; ---------------------------------------------------------------------------
.text:00000D10
.text:00000D10 loc_D10 ; CODE XREF: main+120j
.text:00000D10 CMP R5, #0xDE
.text:00000D12 BNE loc_D32
.text:00000D14 LDR R5, =(asc_1008 - 0xD1C)
.text:00000D16 MOVS R0, #6
.text:00000D18 ADD R5, PC ; "---------------------------------------"...
.text:00000D1A MOV R1, R5
.text:00000D1C BL logger
.text:00000D20 LDR R1, =(aUnlockBitIsFul - 0xD26)
.text:00000D22 ADD R1, PC ; "Unlock bit is full!!!\n"
.text:00000D24
.text:00000D24 loc_D24 ; CODE XREF: main+FEj
.text:00000D24 ; main+118j ...
.text:00000D24 MOVS R0, #6
.text:00000D26 BL logger
.text:00000D2A MOVS R0, #6
.text:00000D2C MOV R1, R5
.text:00000D2E BL logger
.text:00000D32
.text:00000D32 loc_D32 ; CODE XREF: main+CCj
.text:00000D32 ; main+E4j ...
.text:00000D32 MOV R0, R4
.text:00000D34 ADD SP, SP, #0x14
.text:00000D36 POP {R4,R5,PC}
.text:00000D36 ; End of function main
.text:00000D36
Do you guys need my nvram before and right after UL? I currently got no time, otherwise I d probably try to help you out and compare it myself.
Sent from my LG-P760 using xda app-developers app
I think the kernel is the key, but we can't mod it. I noticed Lg is quite lazy when it comes to making changes for different kdz versions. I have found files and scripts that do not belong to that kdz version, and I think that is the case here. The u-boot for 20f recognizes our unlock status, but maybe that's it. Lol, I guess they didn't think people would root and dissect everything or, they knew what they were doing, and wanted us to find it
Sent from my LG-P769 using xda app-developers app
Might it be just about the bootargs? Cause on my old OB, it was enough to set force_bootarg=y or something like this before building. Anyone who tested it already? Oh and sorry, but my nvram partition is empty... Dunno, what went wrong on the backup.
Sent from my LG-P760 using xda app-developers app
Edit:
I made a backup of all partitions before and after I unlocked the phone.
Didnt yet have time to properly check all those files, but what I found is, that only the following partitions got changed:
nvram
persist
mlt
& divxkey
Wondering, what happend at those partitions...
nvram might be the key here. Persist seems to log a lot... Will have a closer look at that as well. Maybe it somehow stores, if BL has been unlocked or not.
mlt... Well who knows, what we'll still find there... Hello NSA
divxkey... This seems really strange to me, but I ll also have a look into this one as well, as soon, as I find some time off
Edit 2:
Uploaded a zip files of those files to my devhost account. If anyone else wants to have a look, PM me please, because I dont want to share the files in public, because of my IMEI and other private stuff.
The divx key likely changes BC wallpaper bin file checks those files and after unlocking the wallpaper bin is usually one of the first things to go. I examined persist block on my other phone, basically its a persisted log lol. As mentioned above NV contains very little data (modem version/software version and what I believe to be the CPU serial). Libunlock writes and reads there for bootloader status though just got to find out where. I will pm you
Sent from my LG-P769 using xda app-developers app
I really need the NV partition of a already unlocked phone.
Sent from my LG-P769 using xda app-developers app
omgbossis21 said:
I really need the NV partition of a already unlocked phone.
Sent from my LG-P769 using xda app-developers app
Click to expand...
Click to collapse
I ll PM you. But please dont flash it! Also contains IMEI and other information specific for each device!
Sent from my LG-P760 using xda app-developers app
I didn't see An imei anywhere in it. For that matter I switched my NV partition to the one from another version I had and it was fine. I then deleted the NV partition and rebooted, it just recreated it. I won't flash it though. I will change my software version to match yours run the libunlock.so and try to unlock.
Sent from my LG-P769 using xda app-developers app
Well for starters the NV partition on the unlocked version is called nvdata where as our jellybean its just NV. I bet 10g has nvdata and jellybean changed it to NV (though I'm not sure at the moment). Changing the name to nvdata and using unlock command on jellybean did not work even with a unlocked boot and u. Now I will dissect these files to find that one minor change so we know where the flag is stored and what variables are.
Sent from my LG-P769 using xda app-developers app
omgbossis21 said:
Well for starters the NV partition on the unlocked version is called nvdata where as our jellybean its just NV. I bet 10g has nvdata and jellybean changed it to NV (though I'm not sure at the moment). Changing the name to nvdata and using unlock command on jellybean did not work even with a unlocked boot and u. Now I will dissect these files to find that one minor change so we know where the flag is stored and what variables are.
Sent from my LG-P769 using xda app-developers app
Click to expand...
Click to collapse
Have you tried changing /system/build.prop : ro.build.target_operator to OPEN ?
Just tried that's it didn't work, thanks though. I'm now gonna try a hex edited NV partition. It appears before and after lock his NV partition did not change. I think it would have if he ran the command again.
Sent from my LG-P769 using xda app-developers app
omgbossis21 said:
Just tried that's it didn't work, thanks though. I'm now gonna try a hex edited NV partition. It appears before and after lock his NV partition did not change. I think it would have if he ran the command again.
Sent from my LG-P769 using xda app-developers app
Click to expand...
Click to collapse
Take a look at the very end of /data/dontpanic/last_kmsg.txt right after reboot oem-unlock
Interested rebooting in non supported mode. When I dissassembled libunlock it listed its dependancies. I pulled the full system/lib folder from the open version. . I may try copying over the lib unlock and its dependancies.
Sent from my LG-P769 using xda app-developers app
Last month, Chainfire posted a nice writeup on several new security changes happening upstream in AOSP. There has been much discussion of the SELinux changes and what that means for root apps, but I'd like to touch on another change that can affect even garden variety non-root apps: mandatory PIE (position-independent executables).
If you're running the Android "L" developer preview image, you may have noticed that some of your native binaries no longer execute:
Code:
$ ./curl --help
error: only position independent executables (PIE) are supported.
PIE is a useful security feature, as randomizing the address space makes it significantly more difficult for an attacker to exploit bugs in a program. However, in this case, one must trade off compatibility for security: PIE is only available in JB 4.1 and above, so most app developers targeting a wide range of Android versions have disabled PIE in their builds. The new PIE check in "L" will cause breakage for most apps that ship native executables.
As it turns out, even some of the precompiled binaries shipped with Android itself are affected, and Google has temporarily disabled PIE enforcement. It is not clear whether they will re-enable it at a later date.
Since the Android "L" preview images were built prior to Google's latest change, they still have PIE enabled. I am attaching a flashable "bypass-pie.zip" which overwrites one byte in /system/bin/linker to bypass the PIE check:
Code:
3a06: f8c6 5098 str.w r5, [r6, #152] ; 0x98
3a0a: f8c6 4100 str.w r4, [r6, #256] ; 0x100
3a0e: 8a0a ldrh r2, [r1, #16]
3a10: 2a03 cmp r2, #3
3a12: d007 beq.n 3a24 // change to e007 (b.n)
3a14: 4992 ldr r1, [pc, #584] ; (3c60)
3a16: 2002 movs r0, #2
3a18: 4479 add r1, pc
Use this at your own risk. It works for me. The same non-PIE curl binary now runs correctly with the patched linker:
Code:
$ ./curl --help
Usage: curl [options...] <url>
Options: (H) means HTTP/HTTPS only, (F) means FTP only
--anyauth Pick "any" authentication method (H)
-a, --append Append to target file when uploading (F/SFTP)
--basic Use HTTP Basic Authentication (H)
--cacert FILE CA certificate to verify peer against (SSL)
[...]
This was tested on hammerhead-lpv79-preview-ac1d8a8e.tgz. If somebody wants to test on razor-lpv79-preview-d0ddf8ce.tgz and post the result, that would be helpful.
It is not necessary to wipe any caches after flashing, although you may want to "clear data" for any apps that were crashing prior to applying the change so that they can start fresh.
Update 2014/07/21: AOSP has re-enabled the PIE check after recompiling their last non-PIE binary. I filed a ticket asking Google to revert this change in order to avoid breaking ABI compatibility.
Does this fixes the root access issue with titanium backup, helium and a bunch of other root apps?
so which one should we use to have proper root curl or the pie bypass
---------- Post added at 06:22 PM ---------- Previous post was at 06:20 PM ----------
never mind even using piebypass still gives me app optimizing process ,, ill try the curl zip
itskapil said:
Does this fixes the root access issue with titanium backup, helium and a bunch of other root apps?
Click to expand...
Click to collapse
No it doesn't. I don't think it is the problem that this aims to fix.
itskapil said:
Does this fixes the root access issue with titanium backup, helium and a bunch of other root apps?
Click to expand...
Click to collapse
Smh
Sent from my Nexus 5 using Tapatalk
It fixes the twitter issue though. Cheers!
shanyel said:
It fixes the twitter issue though. Cheers!
Click to expand...
Click to collapse
Twitter still doesn't work for me...
BTW do I have to wipe cache and dalvik cache after flashing?
CrashOverride1995 said:
Twitter still doesn't work for me...
BTW do I have to wipe cache and dalvik cache after flashing?
Click to expand...
Click to collapse
CrashOverride1995 said:
Twitter still doesn't work for me...
BTW do I have to wipe cache and dalvik cache after flashing?
Click to expand...
Click to collapse
CrashOverride1995 said:
Twitter still doesn't work for me...
BTW do I have to wipe cache and dalvik cache after flashing?
Click to expand...
Click to collapse
Yes I did
Nice thanks for the share!
Thank you. This fixed Dropbox for me.
Well it did, now fc again.
cernekee said:
Last month, Chainfire posted a nice writeup on several new security changes happening upstream in AOSP. There has been much discussion of the SELinux changes and what that means for root apps, but I'd like to touch on another change that can affect even garden variety non-root apps: mandatory PIE (position-independent executables).
If you're running the Android "L" developer preview image, you may have noticed that some of your native binaries no longer execute:
Code:
$ ./curl --help
error: only position independent executables (PIE) are supported.
PIE is a useful security feature, as randomizing the address space makes it significantly more difficult for an attacker to exploit bugs in a program. However, in this case, one must trade off compatibility for security: PIE is only available in JB 4.1 and above, so most app developers targeting a wide range of Android versions have disabled PIE in their builds. The new PIE check in "L" will cause breakage for most apps that ship native executables.
As it turns out, even some of the precompiled binaries shipped with Android itself are affected, and Google has temporarily disabled PIE enforcement. It is not clear whether they will re-enable it at a later date.
Since the Android "L" preview images were built prior to Google's latest change, they still have PIE enabled. I am attaching a flashable "bypass-pie.zip" which overwrites one byte in /system/bin/linker to bypass the PIE check:
Code:
3a06: f8c6 5098 str.w r5, [r6, #152] ; 0x98
3a0a: f8c6 4100 str.w r4, [r6, #256] ; 0x100
3a0e: 8a0a ldrh r2, [r1, #16]
3a10: 2a03 cmp r2, #3
3a12: d007 beq.n 3a24 // change to e007 (b.n)
3a14: 4992 ldr r1, [pc, #584] ; (3c60)
3a16: 2002 movs r0, #2
3a18: 4479 add r1, pc
Use this at your own risk. It works for me. The same non-PIE curl binary now runs correctly with the patched linker:
Code:
$ ./curl --help
Usage: curl [options...] <url>
Options: (H) means HTTP/HTTPS only, (F) means FTP only
--anyauth Pick "any" authentication method (H)
-a, --append Append to target file when uploading (F/SFTP)
--basic Use HTTP Basic Authentication (H)
--cacert FILE CA certificate to verify peer against (SSL)
[...]
This was tested on hammerhead-lpv79-preview-ac1d8a8e.tgz. If somebody wants to test on razor-lpv79-preview-d0ddf8ce.tgz and post the result, that would be helpful.
It is not necessary to wipe any caches after flashing, although you may want to "clear data" for any apps that were crashing prior to applying the change so that they can start fresh.
Click to expand...
Click to collapse
This runs fine on razor-lpv-79-preview!
I can use Dropbox now...
Thanks a lot!!!
Add the linker option ...
Add "-fPIE -pie" linker option..
For those still getting PIE errors in the latest L build (lpx13d), I found that the binary linked in this thread will not work as a drop-in fix for that. After checking the binaries, they are in fact different, however I managed to repatch the newer binary with the same fix. I have yet to actually test this modification, but it's the same patch in principle:
Code:
.text:000032D4 STR.W R5, [R6,#0x98]
.text:000032D8 STR.W R4, [R6,#0x100]
.text:000032DC LDRH R2, [R1,#0x10]
.text:000032DE CMP R2, #3
.text:000032E0 BEQ loc_32F2 <---- replace D007 (07 D0) with E007 (07 E0, B loc_32F2)
.text:000032E2 LDR R1, =(aErrorOnlyPosit - 0x32EA)
.text:000032E4 MOVS R0, #2
.text:000032E6 ADD R1, PC ; "error: only position independent execut"...
.text:000032E8 BL __dl___libc_format_fd
ZIP attached, again, I have no idea if this works or not. But for those who needed the patch previously, it's here again.
EDIT: Fixes several issues for me, and doesn't crash like the previous executable did. So far it fixes the actual PIE issues in SSHTunnel (although it can't do global IPTABLES support still) and it fixes SSHDroid's PIE issues.
EDIT 2: Fixes ES File Explorer as well.
^ thank you sir I just updated my N5 to the 13d build and when I re booted most of my root apps were borked, so I looked for a fix and I flashed the zip. and it actually fixed my issues,
I don't know if that was the intended results but that is what came out for me
shinyquagsire23 said:
For those still getting PIE errors in the latest L build (lpx13d), I found that the binary linked in this thread will not work as a drop-in fix for that. After checking the binaries, they are in fact different, however I managed to repatch the newer binary with the same fix. I have yet to actually test this modification, but it's the same patch in principle:
Code:
.text:000032D4 STR.W R5, [R6,#0x98]
.text:000032D8 STR.W R4, [R6,#0x100]
.text:000032DC LDRH R2, [R1,#0x10]
.text:000032DE CMP R2, #3
.text:000032E0 BEQ loc_32F2 <---- replace D007 (07 D0) with E007 (07 E0, B loc_32F2)
.text:000032E2 LDR R1, =(aErrorOnlyPosit - 0x32EA)
.text:000032E4 MOVS R0, #2
.text:000032E6 ADD R1, PC ; "error: only position independent execut"...
.text:000032E8 BL __dl___libc_format_fd
ZIP attached, again, I have no idea if this works or not. But for those who needed the patch previously, it's here again.
EDIT: Fixes several issues for me, and doesn't crash like the previous executable did. So far it fixes the actual PIE issues in SSHTunnel (although it can't do global IPTABLES support still) and it fixes SSHDroid's PIE issues.
EDIT 2: Fixes ES File Explorer as well.
Click to expand...
Click to collapse
thanks gonna test this on mako
Edit: this works great on the N6 leak mako rom, great work, this made quite a few thousand ppl happy, good work man
This has fixed the VPN issue for me, Hotspot shield is working perfectly now!
THANK YOU!
Has anyone tried the last patch on the razor?
gr4ce said:
Has anyone tried the last patch on the razor?
Click to expand...
Click to collapse
Seems to be working for me on FLO. Root is working as it should foe ES file Explorer ?
\o/
Thanks for the patch! This fixed TitaniumBackup for me. Tested with Hammerhead and Flo on LPX13D.
Sorry for asking but we also have to flash the curl file or just the pie.zip ? Thanks.
Hi,
I use ida pro for cortex m3, get code:
LDR R0, =(loc_8001D74+1)
BX R0 ; loc_8001D74
off_80000F8 DCD loc_8001D74+1 ; DATA XREF: sub_80000F4r
how to get code like this:
LDR R0, off_80000F8
BX R0 ; loc_8001D74
off_80000F8 DCD loc_8001D74+1 ; DATA XREF: sub_80000F4r
Thanks.
Do you press hotkey "O" - Make Offset?
Joker XT said:
Do you press hotkey "O" - Make Offset?
Click to expand...
Click to collapse
Press "O":
"dword_80000FC DCD 0x20000308" switch to "off_80000FC DCD 0x20000308"
"LDR.W SP, =0x20000308" cannot change to "LDR.W SP, dword_80000FC "
thanks.
I find the result:
change ida.cfg:
ARM_NO_PTR_DEREF = YES // Disable using of =label notation
then it's ok!
Hi,
I've read the porting kexec hardboot wiki: https://github.com/Tasssadar/multirom/wiki/Porting-kexec-hardboot and, in particular, the following step:
Hard-reboot in arch/arm/kernel/relocate_kernel.S
Can be found here in the patch for mako. This can often be the hardest thing to find out. Try to look for restart.c or reboot.c or something like that in your device's arch/arm/mach-xxx folder and port the restart sequence from that file to assembler. If you are using Tegra 2/3 or MSM SoC, chances are reboot methods currently (or very similar to them) in the patch will work.
Click to expand...
Click to collapse
So, the porting guide says the restart sequence should be ported from restart.c to relocate_kernel.S.
Exactly, what function I've to port from restart.c? Any ideas?
Ok, I've ported the restart sequence into relocate_kernel.S. The patch just needs the following changes:
Code:
#elif defined(CONFIG_ARCH_MSM7X27)
#include <mach/msm_iomap.h>
Code:
#elif defined(CONFIG_ARCH_MSM7X27)
/* Restart using the PMIC chip, see mach-msm/restart.c */
mov r0, #3
ldr r1, =0x00100000
str r0, [r1]
ldr r0, =0x77665501
str r0, [r1, #0x08]
mov r0, #0
str r0, [r1, #0x0C]
mov r0, #1
ldr r1, =0xc0100418
str r0, [r1]
loop: b loop
Many thanks to a msm dev guy for the help and explanations, which I've translated into assembly code shown above :good:
Now, the next part of the porting kexec hardboot wiki says:
Reserving memory for kexec-hardboot page
Can be found here in the patch for mako. You need to find a place where reserving memory is safe, typicaly somewhere around where memory for ram_console is reserved. It probably will be in the board's file. I usually register the page just before the ram_console, which is before the end of the first memory bank.
Click to expand...
Click to collapse
So, my question is: what board's file is the porting guide pointing to? Any ideas?
Ok, I've reserved memory for kexec-hardboot page. This part can be done if board-msm7x27a_v1.c board's file (located into arch/arm/mach-msm/lge/v1 directory) is changed as follows:
Code:
static void __init msm7x27a_reserve(void)
{
reserve_info = &msm7x27a_reserve_info;
msm_reserve();
#ifdef CONFIG_KEXEC_HARDBOOT
// Reserve space for hardboot page, just before the ram_console
struct membank* bank = &meminfo.bank[0];
phys_addr_t start = bank->start + bank->size - SZ_1M - SZ_1M;
int ret = memblock_remove(start, SZ_1M);
if(!ret)
pr_info("Hardboot page reserved at 0x%X\n", start);
else
pr_err("Failed to reserve space for hardboot page at 0x%X!\n", start);
#endif
}
Now, the next part of the porting kexec hardboot wiki says:
Setting KEXEC_HB_PAGE_ADDR
Can be found here in the patch for mako. This is highly device-specific. Either apply the patch without this value (-> set it to beggining of the System RAM) and grep dmesg for the value you printk in memory reservation ("Hardboot page reserved at 0x%X") or look into /proc/iomem to see where the first bank of System RAM ends, substract size of ram_console ram and size of the hardboot page from that and you should get the right address.
Click to expand...
Click to collapse
This is my /proc/iomem:
Code:
00200000-0fefffff : System RAM
00208000-0098207b : Kernel code
009b2000-00c03f87 : Kernel data
0ff3e000-0ff3efff : crash_log
20000000-2b4fffff : System RAM
98000000-9807ffff : lcd01
9c000000-9c07ffff : lcd02
a0000000-a001ffff : kgsl_3d0_reg_memory
a0000000-a001ffff : kgsl-3d0
a0200000-a0200fff : msm_serial_hs.0
a0300000-a0300fff : uartdm_resource
a0400000-a0400fff : msm_sdcc.1
a0500000-a0500fff : msm_sdcc.2
a0600000-a0600fff : msm_sdcc.3
a0800000-a08003ff : msm_hsusb_host.0
a0800000-a08003ff : msm_hsusb
a0800000-a08003ff : msm_otg
a0d00000-a0d00fff : base
a0e00000-a0e00fff : pbus_phys_addr
a0f00000-a0ffffff : csic
a0f00000-a0ffffff : msm_csic
a1000000-a10fffff : csic
a1000000-a10fffff : msm_csic
a1200000-a1200fff : gsbi_qup_i2c_addr
a1200000-a1200fff : qup_i2c
a1280000-a1280fff : qup_phys_addr
a1280000-a1280fff : qup_i2c
a1300000-a1300fff : gsbi_qup_i2c_addr
a1300000-a1300fff : qup_i2c
a1380000-a1380fff : qup_phys_addr
a1380000-a1380fff : qup_i2c
a8600000-a8600fff : clk_ctl
a9700000-a9700fff : msm_dmov
a9a00000-a9a00fff : msm_serial.0
a9a00000-a9a00fff : msm_serial
aa200000-aa2f1007 : mdp
c0400000-c0400fff : pl310_erp
In particular, line related to the first bank of System RAM says:
Code:
00200000-0fefffff : System RAM
So, should I subtract size of ram_console ram and size of the hardboot page from 0fefffff in order to get the right value for KEXEC_HB_PAGE_ADDR? And, should I use SZ_1M for the size of hardboot page? Any ideas?
Ok, I've set KEXEC_HB_PAGE_ADDR. Briefly, I've subtracted size of the hardboot page (SZ_1M) and size of ram_console (LGE_RAM_CONSOLE_SIZE) from the end address of the System RAM first bank (0ff00000 = 0fefffff + 1). This part can be done if memory.h (located into arch/arm/mach-msm/include/mach directory) is changed as follows:
Code:
#if defined(CONFIG_KEXEC_HARDBOOT)
#if defined(CONFIG_MACH_MSM7X25A_V1)
#define KEXEC_HB_PAGE_ADDR UL(0x0FDC2000)
#else
#error "Adress for kexec hardboot page not defined"
#endif
#endif
Now, the next part of the porting kexec hardboot wiki says:
Setting kexec_hardboot_hook
Can be found here in the patch for mako. This method should contain some device-specific code which needs to be executed during the reboot sequence. Again, can be found in restart.c or reboot.c or something like that in your device's arch/arm/mach-xxx. Chances are you don't need to set anything in here.
Click to expand...
Click to collapse
So, what device-specific code (which needs to be executed during the reboot sequence) should this method contain, in my particular case? Can I just use only pm8xxx_reset_pwr_off function, as in the patch for mako? Any ideas?