Related
Just throwing an idea out there, and since it's for developers (specifically people who make their own recovery images) I assume this is the right section.
Since we have 'control' over the recovery image on our phones, would it not be possible to add a little script to an update.zip that a suitably modified recovery image could extract and run to interactively prompt the user for various Rom options? I'm thinking specifically of kernel choices, but it could be extended to almost anything that needs to be done prior to booting the installed image.
Imagine installing a rom, and during the install you got a little menu like this:
1: RamHack, BFS Kernel
2: RamHack, CFS Kernel
3: No-RamHack, BFS....
etc...
inefficient, it adds extra baggage to rom, and more things can go wrong. what would you rather downlaod a 90mb file or a 110 mb file.
Which would you rather download, one 110MB ROM or 2 90MB ROMS?
I'm pretty sure there's more than a few people who'll download different variations of the same ROM so they can see which is faster, how much easier would it be to just download one thing and then choose which options you want in there without downloading anything else.
I believe it is entirely possible. As a matter of fact, I was working on a ROM project that would have an interactive installer from the update.zip that would selectively install different features, apps, customization, themes, etc., based on the recovery menu application. It would use a lot of the /cache for temp space, though, as the installer application and its resources and configuration file, and later, the necessary parts of the ROM itself, would need to be unzipped before the install can run, if I recall correctly.
Does anyone have a good link to a reference for the command syntax for the /META-INF/com/google/android/update-script file? I'll go search for it in a few moments myself. I could probably make a simple ROM installer that chooses between ROM X and ROM Y based on a key input, as a proof of concept. I'll test it myself, I don't really mind half-bricking my device for science. (As long as I don't need to touch the SPL/Radio, that is.)
Update: Some creative searching finds me this:
JesusFreke said:
Assuming you mean update-script in an update.zip update, you will need to either look at existing update-script files for an example of the syntax, or look at the source of the recovery program in the android source
Click to expand...
Click to collapse
There's also a "make-update-script.c" file I'm seeing here and there, I'm trying to find the file in the Android source.
Update 2: From install.c at donut from cyanogen's android_bootable_recovery:
Code:
#define ASSUMED_UPDATE_SCRIPT_NAME "META-INF/com/google/android/update-script"
#define ASSUMED_UPDATE_BINARY_NAME "META-INF/com/google/android/update-binary"
and in commands.c, toward the bottom at register_update_commands is all the commands defined, and above that are all the functions they carry out.
sorry about that deicist i was sleepy when i wrote that so i must have been cranky yea i guess that is a fine idea, with just 30 more mb you have like 300mb worth of stuff. and you can pick which 90 mb you want.
markolo25 said:
sorry about that deicist i was sleepy when i wrote that so i must have been cranky yea i guess that is a fine idea, with just 30 more mb you have like 300mb worth of stuff. and you can pick which 90 mb you want.
Click to expand...
Click to collapse
Well, on the 32B platform with the Death SPL (my phone) we have the following partitions of the internal NAND memory (mtdblock*) from the df and mount command:
NAND 3: /system 92160kb - OS partition, static and read-only
NAND 5: /data 91904kb - User, system config, app config, and apps (without a2sd)
NAND 4: /cache 30720kb - OTA cache, Recovery/update config and temp
And I'd assume NAND 1 and 2 are the kernel, ramdisk, and bootloader config.
So the ROM wouldn't exceed 92MB installed (most leave some room in /system for hacks and updates). And the update process doesn't ever really "flash", per se; it just formats, copies files, and sets permissions and initialization configs, like Windows or Mac.
So the files that are common to the different ROMs being packaged don't need to be duplicated, only the ones that are changed (like a boot.img, or 32A/B compatibility, or different apps). The update script and chooser menu will decide which files to copy. Meaning the ROM package in and of itself shouldn't really need to exceed 128MB, even if choosing from a wide variety of platforms. And upon installation, the system might take less than 32 MB.
yeah, what he said ^
The scenario I was thinking about specifically was SuperD. If you look here:
http://forum.xda-developers.com/showthread.php?t=613809
There's 8 different downloads there. How many files are actually different between those 8? I guess the themes mean a lot of application files are different (due to having different resources in them) but the underlying framework files will be pretty much the same I think.
Deicist said:
yeah, what he said ^
The scenario I was thinking about specifically was SuperD. If you look here:
http://forum.xda-developers.com/showthread.php?t=613809
There's 8 different downloads there. How many files are actually different between those 8? I guess the themes mean a lot of application files are different (due to having different resources in them) but the underlying framework files will be pretty much the same I think.
Click to expand...
Click to collapse
I could download them all, and find the differences of each. It would be cool if a ROM like this were available in a single download, from which you would choose the content from the device before flashing.
Also, inspired by talking about this, I wrote up a guide on the update-script in the package file. It's still not finished, but it'll be the only guide available for that syntax yet (trust me, I couldn't find one myself ). Link's in my sig.
I'm surprised that nobody's mentioned the Droid... the sholes.info rom (now called droidmod) have used a .tgz archive instead of a .zip, the .tgz installs have always allowed this customization, droidmod makes one of the most common recovery's AND rom's. (SPRecovery/Droidmod).
It give you the option to choose what launcher to install, what theme, what apps to remove.
page here: http://droidmod.org/news/droidmod-v1-0-is-out/
how big of a ROM are you thinking about?
There are roms (WG etc...) that offer more than one kernel as update.zip you can flash over an existing installation of your rom instead of adding all the stuff to one big file. also you can download themes for several roms/for metamorph.
so why would you want some big install script instead of just downloading the files you like and flash it?
jmhalder said:
I'm surprised that nobody's mentioned the Droid... the sholes.info rom (now called droidmod) have used a .tgz archive instead of a .zip, the .tgz installs have always allowed this customization, droidmod makes one of the most common recovery's AND rom's. (SPRecovery/Droidmod).
It give you the option to choose what launcher to install, what theme, what apps to remove.
page here: http://droidmod.org/news/droidmod-v1-0-is-out/
Click to expand...
Click to collapse
Is the Droid's recovery image capable of running on the G1, and/or is it open-source enough to be cross-built to the G1? If so, we could port it here. Only problem there though, is that all the roms are in update.zip format for the G1 already, we'd need to make it dual-compatible if we don't want to split the community and annoy generally everyone ("My rom only supports TGZ recovery!" "ROMs are in ZIP format, and I will not make a TGZ one for those unfortunate enough to use the other Recovery!")
domenukk said:
There are roms (WG etc...) that offer more than one kernel as update.zip you can flash over an existing installation of your rom instead of adding all the stuff to one big file. also you can download themes for several roms/for metamorph.
so why would you want some big install script instead of just downloading the files you like and flash it?
Click to expand...
Click to collapse
Well, for one, devs need to host one file only, and users need to download one file only. The file won't be much bigger or more complex at all, really. And the way things look on the recovery side, we could probably put a selection of themes in with the updater and patch them in post-install with a Metamorph script straight from recovery. That way, the rom is as you want it out-of-the-box, no multiple reboots, etc.
Also, those scripts that usually run on first-boot, like zipalign, dexopt, apps2sd etc. should run from the recovery environment, instead of before the Android bootanimation (I do get tired of hearing "This ROM will take a LONG time on the first boot. If it's stuck at the G1 screen, just wait 10-30 minutes.")
So what would you rather have, one single ROM (G1_Android_ROM_v1.17.zip) for each version released,
or six different ZIPs to flash (G1_Android_ROM_10MB_CFS.zip, G1_Android_ROM_Greentheme.zip, G1_Android_ROM_Bluetheme.zip, G1_Android_Nowipe_GApps.zip)?
Would you rather select what you want to include at flash (and be able to change things like themes or features after flashing), or have 20 different files to choose from, wiping and flashing on each?
I am aware of the no-wipe upgrades for many ROMs, but they can get confusing (I once flashed a CFS_10MB.zip that was for a Hero ROM, stupidly thinking that it might have been for the Eclair that I just downloaded.) Needless to say, I had to wipe and reflash. Again.
TylTru said:
Is the Droid's recovery image capable of running on the G1, and/or is it open-source enough to be cross-built to the G1? If so, we could port it here. Only problem there though, is that all the roms are in update.zip format for the G1 already, we'd need to make it dual-compatible if we don't want to split the community and annoy generally everyone ("My rom only supports TGZ recovery!" "ROMs are in ZIP format, and I will not make a TGZ one for those unfortunate enough to use the other Recovery!")
Well, for one, devs need to host one file only, and users need to download one file only. The file won't be much bigger or more complex at all, really. And the way things look on the recovery side, we could probably put a selection of themes in with the updater and patch them in post-install with a Metamorph script straight from recovery. That way, the rom is as you want it out-of-the-box, no multiple reboots, etc.
Also, those scripts that usually run on first-boot, like zipalign, dexopt, apps2sd etc. should run from the recovery environment, instead of before the Android bootanimation (I do get tired of hearing "This ROM will take a LONG time on the first boot. If it's stuck at the G1 screen, just wait 10-30 minutes.")
So what would you rather have, one single ROM (G1_Android_ROM_v1.17.zip) for each version released,
or six different ZIPs to flash (G1_Android_ROM_10MB_CFS.zip, G1_Android_ROM_Greentheme.zip, G1_Android_ROM_Bluetheme.zip, G1_Android_Nowipe_GApps.zip)?
Would you rather select what you want to include at flash (and be able to change things like themes or features after flashing), or have 20 different files to choose from, wiping and flashing on each?
I am aware of the no-wipe upgrades for many ROMs, but they can get confusing (I once flashed a CFS_10MB.zip that was for a Hero ROM, stupidly thinking that it might have been for the Eclair that I just downloaded.) Needless to say, I had to wipe and reflash. Again.
Click to expand...
Click to collapse
You could just have flashed the original rom without wipe.
Would be a step forward if you could simply put roms and additional files in folders... maybe even whole zip files containing some updates and an xml like file to describe them. This would guarantee compatibility with earlier boot images (just unpack the updates in the zip). Tar might work better than zip as it is not compressed thus faster afaik.
http://droidninja.com/?p=26334
We got ninja'd. Apparently the Droid Does exactly this.
So let's get to work on porting it! Like this comment says, I'm working on finding the source code to a good Droid recovery image (sadly Droid hasn't its own forum here), and if it's closed source, I'll get on reverse-engineering a .tgz rom to see exactly how it works.
TylTru said:
http://droidninja.com/?p=26334
We got ninja'd. Apparently the Droid Does exactly this.
So let's get to work on porting it! Like this comment says, I'm working on finding the source code to a good Droid recovery image (sadly Droid hasn't its own forum here), and if it's closed source, I'll get on reverse-engineering a .tgz rom to see exactly how it works.
Click to expand...
Click to collapse
This is pretty awesome. I was going to say, we could easily run bash scripts but this is so much better.
This needs to be merged with both Amon_ra's recovery and the new 2.x based recovery...
Warning/disclaimer: This thread is intended for those who already know how to compile a kernel and have a working knowledge of Linux and its derivatives. There shouldn't be a great deal of risk involved, but you are responsible for what happens if you decide to follow these instructions.
Polite request: Please don't post replies to this thread that aren't of a technical nature directly related to compiling, modifying, or testing the kernel.
Introduction:
It appears as if Lenovo have released a buildable and bootable kernel source. I've done some preliminary testing with it. However, it would be better if we could get lots of people building and running the kernel, so that we can spot any remaining problems. This is also an opportunity to start hacking it to add/fix features such as USB OTG, etc.
Kernel source:
Get it from the Github repository at: https://github.com/gmarkall/lenovo_a1_07_kernel
Toolchain:
The Makefile seems to suggest that Codesourcery 2010q1 has been used by Lenovo to compile the kernel. Get it from https://sourcery.mentor.com/sgpp/lite/arm/portal/release1293, and make sure that the arm-none-linux-gnueabi-* binaries are on your path.
Building the source:
You may wish to edit the Makefile around line 192 to set CROSS_COMPILE=arm-none-linux-gnueabi- instead of the hardcoded path that is the default.
Then, to build the kernel:
Code:
make distclean
make a1_07_defconfig
make uImage
Booting the kernel
Normally, Android devices have two boot images that consist of a kernel and a ramdisk. One boot image is for the recovery, and the other is for the Android system. This makes it safe to flash a new boot image containing an untested kernel for the Android system, since the recovery can always boot up using the other boot image. However, the A1, by some bad design decision, only has one kernel - the bootloader always loads the same kernel, and just loads a different ramdisk depending whether it is to boot into recovery or system. As a result, it is not safe to flash a kernel to your A1 unless it's already been tested, since a bad kernel will make it impossible to boot from the internal memory, and you'll need a bootable SD card.
The solution to this problem is to make a bootable SD card for loading the kernel and ramdisk from. A bootable SD card consists of two partitions:
* A small bootable VFAT partition, that holds the X-Loader (MLO), U-Boot (u-boot.bin) and the kernel (uImage).
* An ext2 partition that holds the root filesystem.
In order to create a bootable SD card, use the omap3-mkcard.sh script that is attached below. To invoke it for making /dev/mmcblk0 a bootable SD card:
Code:
sudo omap3-mkcard.sh /dev/mmcblk0
You may need to hack the script if your SD card device isn't a /dev/mmcblk* one, since the script searches for partitions denoted "p1" and "p2" - this may need changing to just "1" and "2" respectively (thanks Xbdesign and Brancaleone for this).
This will create the necessary partitions, set the bootable flag, and format them. You will then need to mount the first partition (e.g. /dev/mmcblk0p1), and copy MLO and u-boot.bin to it (also linked below). Then, copy the uImage that you built from your kernel tree, which will be located in /arch/arm/boot. You can now unmount this partition.
Next, mount the second partition (e.g. /dev/mmcblk0p2). This will need to contain the same set of files that the initial ramdisk contains. There are two different ramdisks that you might want to use - one is from the Cyanogenmod 7 build, and the other one is from the stock system. Download links for these are also below. To extract the ramdisk, copy it onto the SD card second partition, then run the following commands (assuming the ramdisk is called ramdisk.ub):
Code:
dd if=ramdisk.ub of=ramdisk.img.gz bs=64 skip=1 # Strip off the U-Boot header
gunzip ramdisk.img.gz # Unzip
sudo cpio -idmv < ramdisk.img # Extract the cpio archive
Then, unmount the second partition of the SD card.
You should now be able to remove the SD card and insert it into your A1. Power down the A1 and power up again, and it should hopefully boot from the SD card and load your kernel. If it's booted from the SD card and loaded your kernel, you should be able to see that it was compiled on your host by looking in Settings -> About Phone -> Kernel Version.
Troubleshooting:
This is not a comprehensive guide, just a few pointers to where a problem might be - please post replies to the thread to get troubleshooting suggestions.
System boots up, but is not running my kernel - it didn't boot from the SD card. If the A1 is plugged into the charger/USB, you sometimes need to reboot multiple times before it boots off the SD card (I think it doesn't always turn off fully when the charger is plugged in).
The static Lenovo logo flashes up over and over again - it's booted from the SD card, but didn't manage to load your kernel
The static Lenovo logo comes up and stays there/goes to a black screen - it's probably loaded your kernel and mounted the root file system, but failed to mount /system. Try running adb shell to see what happens. If you get something like
Code:
/system/bin/sh: no such file or directory
then your kernel is running but /system isn't mounted.
IRC Channel
Join #ideapad-a1 on irc.freenode.net to discuss the kernel and other A1 development-related topics!
Download Links:
MLO
u-boot.bin
omap3-mkcard.sh
Ramdisk for Cyanogenmod 7
Ramdisk for ROW 2643 stock release
I've added the two ramdisks that I suspect will be most common - if you need another ramdisk, you'll have to extract it from an OTA.
Also, I compiled a tun.ko - www.doc.ic.ac.uk/~grm08/ideapad/tun.ko
Here's a cifs.ko - http://www.doc.ic.ac.uk/~grm08/ideapad/cifs.ko
EDIT: AutobahnA1 and infraredevans have confirmed that tun.ko works on ROW_2643.
EDIT 2/3: Please test out cifs.ko! (It doesn't work - it needs slow-work.ko. Will get that done when I can. Thanks to Ilikecokethree on the Lenovo forums for pointing that one out).
你懂中文吗，大神！
我是中国人 关注你的帖子很久了，我不懂英文，用翻译软件看的大概，我们这里很多人支持你，都在用你的rom 很棒！比联想官方的好多了，谢谢！
I think I did exactly the steps as you told, but it still boots the original kernel, may something be wrong? Thank you very much.
PS: I'm a chinese too, and my English is not good either
gmarkall said:
This is also an opportunity to start hacking it to add/fix features such as USB OTG, etc.
Click to expand...
Click to collapse
Please do not forget to try the WiFi-based geolocation, which is also missing!
I wish I had the knowledge to work on it myself but I am far from taking over such tasks...do not have the slightest idea about how these things work.
Good luck and please keep us informed!
geoponer said:
Please do not forget to try the WiFi-based geolocation, which is also missing!
Click to expand...
Click to collapse
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
betabox said:
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
Click to expand...
Click to collapse
Also, it's working in CM7.
hohoxu_hao115 said:
I think I did exactly the steps as you told, but it still boots the original kernel, may something be wrong?
Click to expand...
Click to collapse
Sounds like it's booting from eMMC instead.
Can you post the partition table of the SD card as listed by fdisk, and also a directory listing of each of the two partitions? I ask this to confirm what's happened - seems like you're the first person to follow these instructions, and it's quite possible I made a mistake somewhere.
betabox said:
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
Click to expand...
Click to collapse
Apologies for the off-topic, but I think that we are discussing two different things here: I am referring to the Geolocation bug, which prevents me from e.g. checking in with Foursquare by using only WiFi location information (active GPS signal is needed) while you have solved the Geocoding bug, which has nothing to do with the Geolocation one...
Please correct me if I am wrong.
@Graham: I plan to install the CM7 that you have been working on (with the feedback from other users - I keep an eye on that thread!) but since I use my A1 for professional purposes as well, I would like to make sure that everything is working fine before moving to CM7. Apologies for not being able to contribute to the beta testing of CM7 but I am really looking forward to seeing a version based on the source code provided by Lenovo, which I think will lead to a more stable version of your CM7. I cannot thank you enough for taking the time to work on this, really!
geoponer said:
Apologies for the off-topic, but I think that we are discussing two different things here: I am referring to the Geolocation bug, which prevents me from e.g. checking in with Foursquare by using only WiFi location information (active GPS signal is needed) while you have solved the Geocoding bug, which has nothing to do with the Geolocation one...
Please correct me if I am wrong.
Click to expand...
Click to collapse
I think that whether it works in CM7 or not, it almost certainly isn't a kernel issue. I'll test it by signing up for Foursquare and give it a try out on CM7 to see if it works later on. Will post my findings in the CM7 thread.
Hi Graham,
just gonna pile up several questions/thinkings and feel free to comment them the or answer on your liking
We do have few hickups on CM7 but I am more excited about idea of having proper recovery then ironing current CM rom that works more than satisfactory right now. Do we have enough code (I assume that target here is u-boot) on our hands that someone can implement necessary changes to internal partitions and boot procedures?
what is your opinion on replacement of u-boot with something else? for example LK loader or to be more precise with its current HD2 implementation known as cLK. it allready has some neat features like HBOOT like GUI, ability to change partition sizes on device itself (without computer), ability to boot from different partitions (would be nice to have android and ubuntu side by side loaded on our devices) and last but not least it has fastboot support enabled...or is it better way fill up u-boot with desired features if possible?
so...just my wishful thinking...not enough knowledge on my side to do anything regarding all this just hoping that some of you, more capable guys gets interested in this
dusko_m said:
Hi Graham,
just gonna pile up several questions/thinkings and feel free to comment them the or answer on your liking
We do have few hickups on CM7 but I am more excited about idea of having proper recovery then ironing current CM rom that works more than satisfactory right now. Do we have enough code (I assume that target here is u-boot) on our hands that someone can implement necessary changes to internal partitions and boot procedures?
what is your opinion on replacement of u-boot with something else? for example LK loader or to be more precise with its current HD2 implementation known as cLK. it allready has some neat features like HBOOT like GUI, ability to change partition sizes on device itself (without computer), ability to boot from different partitions (would be nice to have android and ubuntu side by side loaded on our devices) and last but not least it has fastboot support enabled...or is it better way fill up u-boot with desired features if possible?
so...just my wishful thinking...not enough knowledge on my side to do anything regarding all this just hoping that some of you, more capable guys gets interested in this
Click to expand...
Click to collapse
I do want to implement something that's pretty much as you describe. My biggest motivation is that it's currently not safe to flash a kernel since you can break both system and recovery that way in one go - I really want to make the boot process more robust.
gmarkall said:
Also, I compiled a tun.ko - tun.ko
I haven't tested it yet - is anyone able to try it please?
Click to expand...
Click to collapse
The module loaded without a problem on my 2643_ROW Kernel. Installed "Rooted AnyConnect" from the "Play Place". Now I can connect to my company VPN.
gmarkall: YOU ROCK! THANK YOU!!!
tun.ko
Graham
The tun.ko module works perfectly with openvpn on 2643_ROW.
I can now access my Amahi home server,awsome.
Thanks a lot you are doing a great job.
Dont want to sound presumptuous but any chance of a cifs.ko to go with it .
Cheers
Infraredevans said:
Dont want to sound presumptuous but any chance of a cifs.ko to go with it .
Click to expand...
Click to collapse
I'll give it a whirl... give me a few minutes.
gmarkall said:
I'll give it a whirl... give me a few minutes.
Click to expand...
Click to collapse
Here it is: http://www.doc.ic.ac.uk/~grm08/ideapad/cifs.ko
To compile it I had to copy md5.h from another kernel source to fs/cifs in the kernel tree. I also had to edit init/Kconfig so that CONFIG_SLOW_WORK defaulted to yes. I configured the module with the options:
Support Legacy LANMAN servers which use weaker security
CIFS Extended attributes
CIFS POSIX attributes
and without statistics, debugging, or experimental features. Let me know if this is a suitable config - I could always tweak it and build another one.
arm-2010q1-202-arm-none-linux-gnueabi.bin
Did someone manage to install arm-2010q1-202-arm-none-linux-gnueabi.bin on 64bit system?
xbdesign said:
Did someone manage to install arm-2010q1-202-arm-none-linux-gnueabi.bin on 64bit system?
Click to expand...
Click to collapse
I did - I didn't have any problems, but my random guess about how to solve it could be to install ia32-libs. If installing that doesn't solve it, can you post a bit more detail about the problem?
I am using ubuntu 10.04 LTS and just cant install / find Getlibs to install a 32-bit version of xulrunner :-(
xbdesign said:
I am using ubuntu 10.04 LTS and just cant install / find Getlibs to install a 32-bit version of xulrunner :-(
Click to expand...
Click to collapse
Do you need that to run the installer? I just downloaded the tar version instead and extracted it. I saw there was an installer as well, but I thought it would be more hassle than using the tarball so I just ignored it.
Hey guys. As the title states, we need to destroy SBOOT to leave the device in an otherwise "hard-bricked" state. This would open the door to loading an insecure bootloader. Currently our option is to perform a hardware hack to brick the device which is obviously not optimal...
So, the question is, how can I write some garbage like a Justin Beiber MP3 over the SBOOT?
If you've come up with a way to hard-brick this device, it would be very helpful if you share.
Has anyone researched K-Exec on the VZW Galaxy Note2?
This change (Pointed out by XDA Recognized Developer Ralekdev) to Cyanogenmod by XDA Elite Recognized Developer Entropy512, implemented in a kernel, booted into a kexec, could expose the /dev/block/mmcblk0boot0. https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0 We need access to this partition to be able to destroy it. I'm not a kernel developer though. I need some help with this.
AdamOutler said:
Has anyone researched K-Exec on the VZW Galaxy Note2?
This change (Pointed out by XDA Recognized Developer Ralekdev) to Cyanogenmod by XDA Elite Recognized Developer Entropy512, implemented in a kernel, booted into a kexec, could expose the /dev/block/mmcblk0boot0. https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0 We need access to this partition to be able to destroy it. I'm not a kernel developer though. I need some help with this.
Click to expand...
Click to collapse
i can link u to a kernel but from what i know no one has looked into kexec yet.. also did u mean to put this in international forum or verizon one cause were in international now not verizon
AdamOutler said:
Has anyone researched K-Exec on the VZW Galaxy Note2?
This change (Pointed out by XDA Recognized Developer Ralekdev) to Cyanogenmod by XDA Elite Recognized Developer Entropy512, implemented in a kernel, booted into a kexec, could expose the /dev/block/mmcblk0boot0. https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0 We need access to this partition to be able to destroy it. I'm not a kernel developer though. I need some help with this.
Click to expand...
Click to collapse
Add me on gtalk I have a guy on my team that's a kernel guru I'm sure he can get done anything you need, I'll reply with his gtalk info
Sent from my SCH-I605 using xda app-developers app
beanstown106 said:
cause were in international now not verizon
Click to expand...
Click to collapse
There's currently only one dev discussion section shared among all the Note2 devices.
Adam, I haven't messed with kexec, and my schedule is a bit nightmarish until the new year... If no one has come up with something by then, I'll (try to remember to) work on it then.
take care
Gary
bbedward is building a kernel right now. Adam i will PM you his gtalk
http://goo.im/devs/bbedward/vzwnote2_image.zip
There's a stock note 2 kernel build, it includes this and is stock otherwise except for some gcc 4.7 fixes https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0
Maybe it'll help somebody if they get kexec working :good:
/dev/block/mmcblk0boot0 <---- this is the sboot block?
You can't flash a custom boot.img (ytod)
You can't flash a custom recovery.img (ytod)
Without either of those, I don't know that you can get kexec working.
If I remember correctly, you needed a kexec-enabled recovery in order to hardboot a different kernel (of which did NOT need to be kexec-enabled).
So you would already have to have a kexec-enabled kernel running in order to do this, and if we could do this we could just include that patch anyway.
Might be able to do some some crafty stuff with 2nd init, beyond me, I've never messed with this. Hashcode might be of some help here.
But will this allow booting a different kernel? That's your main obstacle here.
Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)
iamsamiam said:
/dev/block/mmcblk0boot0 <---- this is the sboot block?
Click to expand...
Click to collapse
yes
invisiblek said:
You can't flash a custom boot.img (ytod)
You can't flash a custom recovery.img (ytod)
Without either of those, I don't know that you can get kexec working.
If I remember correctly, you needed a kexec-enabled recovery in order to hardboot a different kernel (of which did NOT need to be kexec-enabled).
So you would already have to have a kexec-enabled kernel running in order to do this, and if we could do this we could just include that patch anyway.
Might be able to do some some crafty stuff with 2nd init, beyond me, I've never messed with this. Hashcode might be of some help here.
But will this allow booting a different kernel? That's your main obstacle here.
Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)
yes
Click to expand...
Click to collapse
this was my thinking aswell...kexec will only work if we can flash a custom recovery.img, but since sboot checks the recovery partition, nothing custom can be flashed to it. aboot on the vzw s3 didnt check the recovery partition which left a hole to get in and use kexec.
droidstyle said:
this was my thinking aswell...kexec will only work if we can flash a custom recovery.img, but since sboot checks the recovery partition, nothing custom can be flashed to it. aboot on the vzw s3 didnt check the recovery partition which left a hole to get in and use kexec.
Click to expand...
Click to collapse
probably out of my scope but..... sboot checks the recovery partition at STARTUP (i would guess its the first thing checked, since when i soft bricked mine it wouldnt do ANYTHING but tell me the software is not genuine, any way we could inject(probably not the right word) it after the check?
invisiblek said:
Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)
Click to expand...
Click to collapse
FYI guys this didn't work
Error was something about "exports duplicate symbol....(owned by kernel)"
Found it funny I got "owned by the kernel", but w/e...
Here's the module in case anyone wants to mess around with it, dmesg is where the error appears
http://invisiblek.chickenkiller.com/mmc_block.ko
Pretty sure there is no way to get this loaded, but the steps to do so would be:
- throw it in /lib/modules (this is non-persistent)
- chmod it to at least 644
- busybox modprobe -f mmc_block
While this is mostly specific to the Verizon variant, being able to kill SBOOT to force SD-card boot is a technique that would be usable on multiple devices in the future.
Pretty much it's that the VZW Note2 NEEDS the ability to kill SBOOT starting from a stock kernel without anything beyond root, but it may be useful on other devices too.
And if people are wondering why we're TRYING to hardbrick a device - if you hardbrick by killing SBOOT, the device falls back to booting from the SD. Samsung's "official" hardbrick recovery technique does this by shorting a resistor to disable the eMMC.
The key is whether there is some way to access mmcblk0boot0 from a stock kernel... So far, no one has ever done it without hacking the kernel itself to my knowledge.
Entropy512 said:
...The key is whether there is some way to access mmcblk0boot0 from a stock kernel... So far, no one has ever done it without hacking the kernel itself to my knowledge.
Click to expand...
Click to collapse
I don't understand what prevents access to mmcblk0boot0 (and like) partitions, in the first place. (?) Any insight you care to share? Only thing I could suggest is to have a look at these mmc tools, in various repositories, although very similar, if not identical.
http://patches.linaro.org/project/linux-mmc/
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=summary
https://kernel.googlesource.com/pub/scm/linux/kernel/git/cjb/mmc-utils/
In fact, the problem of being able to fully access eMMC devices, is understated. It would have great benefits for the developer community to things ranging from removing partition write protections to unbricking TV sets...
Found in:
[linux/kernel/git/cjb/mmc.git] / Documentation / mmc / mmc-dev-parts.txt
from first link:
Code:
SD and MMC Device Partitions
============================
Device partitions are additional logical block devices present on the
SD/MMC device.
As of this writing, MMC boot partitions as supported and exposed as
/dev/mmcblkXboot0 and /dev/mmcblkXboot1, where X is the index of the
parent /dev/mmcblkX.
MMC Boot Partitions
===================
Read and write access is provided to the two MMC boot partitions. Due to
the sensitive nature of the boot partition contents, which often store
a bootloader or bootloader configuration tables crucial to booting the
platform, write access is disabled by default to reduce the chance of
accidental bricking.
To enable write access to /dev/mmcblkXbootY, disable the forced read-only
access with:
[B]echo 0 > /sys/block/mmcblkXbootY/force_ro[/B]
To re-enable read-only access:
[B]echo 1 > /sys/block/mmcblkXbootY/force_ro[/B]
The boot partitions can also be locked read only until the next power on,
with:
[B]echo 1 > /sys/block/mmcblkXbootY/ro_lock_until_next_power_on
[/B]
This is a feature of the card and not of the kernel. If the card does
not support boot partition locking, the file will not exist. If the
feature has been disabled on the card, the file will be read-only.
The boot partitions can also be locked permanently, but this feature is
not accessible through sysfs in order to avoid accidental or malicious
bricking.
The code we need to modify is probably that of the 3rd link (above), in mmc_cmds.c (and related). But I'm not sure it's possible to use this to disable write protect, although it seem like here:
Code:
[SIZE=2]...
/*
* EXT_CSD field definitions
*/
#define EXT_CSD_HPI_SUPP (1<<0)
#define EXT_CSD_HPI_IMPL (1<<1)
#define EXT_CSD_CMD_SET_NORMAL (1<<0)
[COLOR=Red][B]#define EXT_CSD_BOOT_WP_B_PWR_WP_DIS (0x40)
#define EXT_CSD_BOOT_WP_B_PERM_WP_DIS (0x10)[/B][/COLOR]
#define EXT_CSD_BOOT_WP_B_PERM_WP_EN (0x04)
#define EXT_CSD_BOOT_WP_B_PWR_WP_EN (0x01)
#define EXT_CSD_BOOT_INFO_HS_MODE (1<<2)
#define EXT_CSD_BOOT_INFO_DDR_DDR (1<<1)
#define EXT_CSD_BOOT_INFO_ALT (1<<0)
#define EXT_CSD_BOOT_CFG_ACK (1<<6)
#define EXT_CSD_BOOT_CFG_EN (0x38)
#define EXT_CSD_BOOT_CFG_ACC (0x03)
#define EXT_CSD_RST_N_EN_MASK (0x03)
#define EXT_CSD_HW_RESET_EN (0x01)
#define EXT_CSD_HW_RESET_DIS (0x02)
#define EXT_CSD_PART_CONFIG_ACC_MASK (0x7)
#define EXT_CSD_PART_CONFIG_ACC_BOOT0 (0x1)
#define EXT_CSD_PART_CONFIG_ACC_BOOT1 (0x2)
#define EXT_CSD_PART_CONFIG_ACC_USER_AREA (0x7)
#define EXT_CSD_PART_CONFIG_ACC_ACK (0x40)
[SIZE=2]...[/SIZE]
[/SIZE]
[mmc.h]
_Dennis_ said:
I have a t-mobile Note 2 and I was messing around with the *#197328649# menu and found these in UMTS, Version Information, secure boot status.
Secure VAL: 4369
SEC_BOOT:1
OEM_PK_HASH:1
SEC_HW_KEY:1
OEM_CONFIG:1
Like I said may or may not help but seeing secure boot made me think of you guys.
Sent from my handheld Android 'PC', NOTE II
Click to expand...
Click to collapse
guy posted this in the rom thread, posting it here to.. i also have no idea what it is but cant hurt right? lol
invisiblek said:
You can't flash a custom boot.img (ytod)
You can't flash a custom recovery.img (ytod)
Without either of those, I don't know that you can get kexec working.
If I remember correctly, you needed a kexec-enabled recovery in order to hardboot a different kernel (of which did NOT need to be kexec-enabled).
So you would already have to have a kexec-enabled kernel running in order to do this, and if we could do this we could just include that patch anyway.
Might be able to do some some crafty stuff with 2nd init, beyond me, I've never messed with this. Hashcode might be of some help here.
But will this allow booting a different kernel? That's your main obstacle here.
Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)
yes
Click to expand...
Click to collapse
So I think people have a misconception of what kexec is.
kexec is a system call that enables you to load and boot into another kernel from the currently running kernel.
Click to expand...
Click to collapse
Here
Yes there was orignally a kexec for the SGSIII that was issued in the recovery partition but this is not what kexec does. IT LOAD A KERNEL DIRECTLY ONTOP OF THE CURRENT. It does not access memory. It does not change any of the partitions, and it does not make it so that phone will not be "secure" for booting. It does not require any access to the recovery partition and does not need kexec-enabled in the kernel necessarily. When you enable kexec in the kernel, all you do is provide a handle for the actual binary so it knows where in the stack to replace the kernel. Without this you must write in your own kexec injection vectors, and this can be difficult, but has been done for devices before (see nook tablet). There's no doubt in my mind that this would be an incredibly daunting task, however if someone did it, it might prove usefull for every device in existence that has a locked bootloader.
As for the topic at hand. To what I have scene and read here it sounds like the default kernel does not allow you to access the mmcblk0, which is kinda a pain. Though it might only not allow you to do this by name. I wonder if you overloaded partition table if it would start to bleed into the first block. Or if we can write a program that references the memory by location instead of by pointer, aka 0x81000000 instead of mmcblk0. Also you might want to dump the system kernel in the recovery or any other bootable mode. It is possible that its only on the system image kernel that it blocks this. IE boot into recover mode and or download mode and see if that subspace can be accessed. As a last resort adam you might be able to boot it into panic mode with the boot pins. I havent been able to find a diagram, but it is always possable to brick the device with pins, which ones are beyond me though i found this. Unfortunately no mention of boot conditions anywhere there.
I wonder if something like bootstrap or safe strap could be implemented to try and boot a kexec kernel with a custom recovery so that mmcblk0boot0 gets exposed.
Sent from my Amazon Kindle Fire using xda app-developers app
times_infinity said:
I wonder if something like bootstrap or safe strap could be implemented to try and boot a kexec kernel with a custom recovery so that mmcblk0boot0 gets exposed.
Sent from my Amazon Kindle Fire using xda app-developers app
Click to expand...
Click to collapse
I have recommended to Adam to talk to Hashcode as he did some creative things with the Droid 3 and kexec and custom recovery.
chayes627 said:
I have recommended to Adam to talk to Hashcode as he did some creative things with the Droid 3 and kexec and custom recovery.
Click to expand...
Click to collapse
Exactly who i was thinking of when i wrote that post.
Sent from my Galaxy Nexus using xda app-developers app
I hit up hash on gtalk today and pointed him to this thread.. Seems at least we should be able to get a hacked recovery working like safe-strap. Then again I am no recovery nor kernel dev
Alright, noob here. Since I cannot post in the PACMAN development thread (http://forum.xda-developers.com/showthread.php?t=2164406) I will put this here.
- Problems installing PACMAN ROM
- After receiving "Errors Flashing", failures, downgraded recovery to TWRP 2.3.3.0
- 2.3.3.0 displayed "Error 7"
- Searching on error 7 led me down the path of the assert checks
- updater-script assert command in PACMAN ROM package is checking for model "ville".
- My HTC One S Special edition returns "villeplus" from "adb shell getprop ro.product.device"
My understanding is that the North American S4 and the Special Edition share identical hardware, only differing in drive size (16 vs. 64GB), so I am assuming any ROM designed for the ville will work on my phone.
Assuming it will I should be able to edit the "updater-script" file, but when I extract it windows is telling me that 23 files are duplicates. I'm not sure if this is because its windows vs. Linux that I'm extracting it on?? In any case, I don't seem to be able to modify the file without adversely affecting the integrity of the archive. Also would assume replacing the file will affect the MD5 hash which I believe TWRP checks when loading the ROM?
So first off, can someone confirm that this ROM will be compatible with my phone and 2, any suggestions on modifying the updater-script file within the archive?
Update
I was able to modify the updater-script file tonight using file X-Plore and text edit, so now the script is looking for "villeplus" rather than ville. My phone is S-OFF which I read means that it does not do signature checks... however, I'm not sure if that also means it bypasses MD5 checksums - I suspect not since I'm pretty sure I saw it verifying MD5 previously. So, since I tampered with the ZIP it still may not work.
My real question now that remains is even if it will work, do I want to flash a ROM built for the ville to my villeplus. The more I read about custom ROMs the more it appears that they are extremely specific to models.
I am still extremely curious to try it... rumor has it that curiosity didn't work out so well for the cat though. :-/
merovingian_a51 said:
I was able to modify the updater-script file tonight using file X-Plore and text edit, so now the script is looking for "villeplus" rather than ville. My phone is S-OFF which I read means that it does not do signature checks... however, I'm not sure if that also means it bypasses MD5 checksums - I suspect not since I'm pretty sure I saw it verifying MD5 previously. So, since I tampered with the ZIP it still may not work.
My real question now that remains is even if it will work, do I want to flash a ROM built for the ville to my villeplus. The more I read about custom ROMs the more it appears that they are extremely specific to models.
I am still extremely curious to try it... rumor has it that curiosity didn't work out so well for the cat though. :-/
Click to expand...
Click to collapse
Unfortunately, i have to fully disappoint you.
The villeplus is having the exact same hardware as the ville. Theoretically ideal. Unfortunately, HTC decided to make it a "/data/media" device unlike its brother, the ville.
Explained: the Ville has a partition for the SDCard and its mounted with its own mountpoint, /sdcard.
The Villeplus has a partition for the SDCard too, but its mounted inside the /Data partition as /data/media. This means a lot of problems from every imaginable aspect.
I spend a week together with Torxx from ViperOneS to get Viper to run on it and we found out that a.) the Kernel needs to be adjusted and b.) some libs and etc. which is real dev work and which no dev in the OneS section has time for.
Later i spent another two weeks with Philz and mdmower trying to at least get recovery to mount the sh.it thing as USB, which turned out to be impossible at this time as it is only possible through the MTP protocoll, which no recovery supports as of yet.
Since i am a n00b myself i did not entirely understand the nature of the problem, but it seems to be very complex.
At some point i suggested to actually rewrite the partitions on the phones so they would work the same way as on the ville. I even tried myself and flashed a Ville RUU to my Villeplus (it works, doesnt break anything) but with the same effect as custom roms: my SD was then in Data/media and the internal apps memory and RAM were shifted to somewhere else with not enough space so the phone kept running out of space and crashed often. Also all system components trying to access stuff on the SD failed to find their stuff and crashed.
Since we don't actually have means to change the chip controller programming so it offers the partitions differently to the ROM we cannot go that way either (Zarboz tried to explain it to me but i failed understanding it, somehow the device pathes are put into the actual chip and not part of any RUU, so to change them one would need to have some special software tool like we could have done on the HD2 back then).
The only viable way would be to adjust ROM modules and Kernel to this structure, which won't happen as no dev has this device and there are like maybe 5 active users here.
You are out of luck my friend. Sorry. I too was full of hope and gave it up when all devs i contacted signalled that there is no benefit for them and they wouldn't waste their time basically.
Sneakyghost said:
Unfortunately, i have to fully disappoint you.
The villeplus is having the exact same hardware as the ville. Theoretically ideal. Unfortunately, HTC decided to make it a "/data/media" device unlike its brother, the ville.
Explained: the Ville has a partition for the SDCard and its mounted with its own mountpoint, /sdcard.
The Villeplus has a partition for the SDCard too, but its mounted inside the /Data partition as /data/media. This means a lot of problems from every imaginable aspect.
I spend a week together with Torxx from ViperOneS to get Viper to run on it and we found out that a.) the Kernel needs to be adjusted and b.) some libs and etc. which is real dev work and which no dev in the OneS section has time for.
Later i spent another two weeks with Philz and mdmower trying to at least get recovery to mount the sh.it thing as USB, which turned out to be impossible at this time as it is only possible through the MTP protocoll, which no recovery supports as of yet.
Since i am a n00b myself i did not entirely understand the nature of the problem, but it seems to be very complex.
At some point i suggested to actually rewrite the partitions on the phones so they would work the same way as on the ville. I even tried myself and flashed a Ville RUU to my Villeplus (it works, doesnt break anything) but with the same effect as custom roms: my SD was then in Data/media and the internal apps memory and RAM were shifted to somewhere else with not enough space so the phone kept running out of space and crashed often. Also all system components trying to access stuff on the SD failed to find their stuff and crashed.
Since we don't actually have means to change the chip controller programming so it offers the partitions differently to the ROM we cannot go that way either (Zarboz tried to explain it to me but i failed understanding it, somehow the device pathes are put into the actual chip and not part of any RUU, so to change them one would need to have some special software tool like we could have done on the HD2 back then).
The only viable way would be to adjust ROM modules and Kernel to this structure, which won't happen as no dev has this device and there are like maybe 5 active users here.
You are out of luck my friend. Sorry. I too was full of hope and gave it up when all devs i contacted signalled that there is no benefit for them and they wouldn't waste their time basically.
Click to expand...
Click to collapse
Wow, Sneakyghost, I can't thank you enough for your prompt (I just PM'd him last night folks) and very thorough response.
I'm wondering why HTC did this - thinking maybe to prevent/protect users from tampering with the device - perhaps other ROMs wouldn't run on it in a stable fashion.. or they just don't want people messing with custom ROMs. Perhaps this was a new architecture for them (wondering if the One and One X followed this same design?).
In any case, looks like I'll be sticking to looking at launchers and custom widgets. I'm actually quite happy with 4.1.1 and Sense (maybe because I'm new to Android, not sure), I mainly wanted to try experiment with custom ROMs, and learn about how all this stuff works. At least till the M4 comes out anyways..
Thanks again so much for your response, it is much appreciated and well explained.
Sneakyghost said:
... Unfortunately, HTC decided to make it a "/data/media" device unlike its brother, the ville.
Click to expand...
Click to collapse
Oh the irony, the (unreleased) 4.2 update for ville actually reformats partitions for data media. I don't think the update will ever be officially available to US users, but it is funny nonetheless.
This, my friend, is indeed ironic, if not even sad.
Considering what it means, I come to understand that porting ROM's from Ville to Villeplus would have gotten much easier then. Only that it is too late.
Torxx and I gave up due to the amount of work attached to the previous system structures, but if the Ville turns into a datamedia device with that update, many ROM devs and chefs would have to deal with it plus HTC would have done the most difficult part already anyway...
What a shame that this comes so late now and doesn't even get released probably...
mobile post
Hello @rbox,
I have implemented a bootloader signature bypass and was wondering if you could help me verify my method.
Because we know this works for the firetv, my plan is:
1. You could send me one of your unsigned custom recoveries for firetv.
2. I would then sign it and send it back to you to check it works.
Hope you don't mind me contacting you this way.
ggow
Woah! Props! I still don't plan on picking up an HDX, but at least it'll get some development now! Now just to get root on KitKat for you guys.
@rbox,
I should add some information which I forgot to include earlier:
I tried the recovery image on the device but failed to boot which is why I need some help to verify my method to find out whether our bootloader is susceptible to this approach, mathematically it looks good (I think). See what you think. I have PM'ed you a link to the modified recovery image as we discussed.
Conclusions
@rbox
In short I found our bootloader is NOT susceptible to the signature bypass method.
I tried first on stock 13.3.2.4 and then on stock 13.3.1.0.
Thanks for your help rbox. I really appreciate you taking the time.
I had some implementation issues in my work which led to to the differences between our output files.
I believe I have fixed those now.
Bootloader question
How much has been done with anyone looking into the unlock code functionality for the bootloader? I have spent a ton of time (mostly wasted time it has turned out), trying to make any kind of sense of the bootloader using IDA Pro with hex-rays decompilation. It seems easy enough to write an unlock code for the device using idme, but not knowing what the code is, and not knowing where in the bootloader decompilation the unlock checking is done has just lead to dead ends. I assume from some posts in much older development threads that some very smart people already spent some time attempting to decompile the bootloader and didn't have much luck. Does anyone think anything can be gained from further muddling around with the decompilation?
gbgadgets said:
How much has been done with anyone looking into the unlock code functionality for the bootloader? I have spent a ton of time (mostly wasted time it has turned out), trying to make any kind of sense of the bootloader using IDA Pro with hex-rays decompilation. It seems easy enough to write an unlock code for the device using idme, but not knowing what the code is, and not knowing where in the bootloader decompilation the unlock checking is done has just lead to dead ends. I assume from some posts in much older development threads that some very smart people already spent some time attempting to decompile the bootloader and didn't have much luck. Does anyone think anything can be gained from further muddling around with the decompilation?
Click to expand...
Click to collapse
I did the same as you and found "unlock_code" can be read from idme, but not without unlocking the bootloader. I can't seem to find it in any partition either.
ggow said:
@rbox
In short I found our bootloader is NOT susceptible to the signature bypass method.
I tried first on stock 13.3.2.4 and then on stock 13.3.1.0.
Thanks for your help rbox. I really appreciate you taking the time.
I had some implementation issues in my work which led to to the differences between our output files.
I believe I have fixed those now.
Click to expand...
Click to collapse
Have you taken a look at the 2nd_init hack? Safestrap uses it to load a recovery, but it can also be used to load new kernels.
r3pwn said:
I did the same as you and found "unlock_code" can be read from idme, but not without unlocking the bootloader. I can't seem to find it in any partition either.
Have you taken a look at the 2nd_init hack? Safestrap uses it to load a recovery, but it can also be used to load new kernels.
Click to expand...
Click to collapse
Hi r3pwn, I looked at 2nd init. I can use it to load a new ramdisk which is great. But I don't think you can load a different kernel. Also correct me I'm wrong, I don't think we can boot kitkat on the jelly bean kernel with a modified ramdisk.
Sent from my Nexus HDX 7 using Tapatalk
ggow said:
Hi r3pwn, I looked at 2nd init. I can use it to load a new ramdisk which is great. But I don't think you can load a different kernel. Also correct me I'm wrong, I don't think we can boot kitkat on the jelly bean kernel with a modified ramdisk.
Sent from my Nexus HDX 7 using Tapatalk
Click to expand...
Click to collapse
Oh. My bad. Meant ramdisk. Not sure why kernel came out. The devs over with the Sony Xperia SP (I think, lemme double check) managed to run Lollipop on their JB 4.3 device using the 2nd init. Let me look some more and report back with (hopefully) useful info.
Edit: Yep, it is the SP. Their rd hijack process: https://bitbucket.org/bagyusz/hijack-ramdisk-huashan/src/20a66537e120?at=cm-10.2_LBL. They list the rest of their sources at the bottom of the post here (Device tree, vendor tree, how to make the ramdisk alone, etc...): http://forum.xda-developers.com/xperia-sp/development/xperiasp-locked-bootloader-lbl-t2947194
Cool, will take a look
Sent from my Nexus HDX 7 using Tapatalk
r3pwn said:
Oh. My bad. Meant ramdisk. Not sure why kernel came out. The devs over with the Sony Xperia SP (I think, lemme double check) managed to run Lollipop on their JB 4.3 device using the 2nd init. Let me look some more and report back with (hopefully) useful info.
Edit: Yep, it is the SP. Their rd hijack process: https://bitbucket.org/bagyusz/hijack-ramdisk-huashan/src/20a66537e120?at=cm-10.2_LBL. They list the rest of their sources at the bottom of the post here (Device tree, vendor tree, how to make the ramdisk alone, etc...): http://forum.xda-developers.com/xperia-sp/development/xperiasp-locked-bootloader-lbl-t2947194
Click to expand...
Click to collapse
@r3pwn,
Thanks for the pointing me in that direction... With the 13.3.2.4 stock kernel I have a build of aosp lollipop 5.0.1 which now boots to some degree. Very early days yet but some progress. I now have adb access. I can see that in logcat services are starting up and then dying.
I can't see the boot animation yet because the video driver / surfaceflinger is not starting. First goal is to get that and full hw graphical support working.
Definitely a way forward
ggow said:
@r3pwn,
Thanks for the pointing me in that direction... With the 13.3.2.4 stock kernel I have a build of aosp lollipop 5.0.1 which now boots to some degree. Very early days yet but some progress. I now have adb access. I can see that in logcat services are starting up and then dying.
I can't see the boot animation yet because the video driver / surfaceflinger is not starting. First goal is to get that and full hw graphical support working.
Definitely a way forward
Click to expand...
Click to collapse
Thanks! Glad I could help! If there's anything you need help with, let me know and I could try to get in contact with the Xperia SP devs and maybe even get a Hangout set up.
I have examined aboot for some time now and I can think of 3 methods to unlock the bootloader:
Provide the unlock code. The code seems to be a 512 byte image, that is flashed by "fastboot flash unlock code.img". The code is somehow verified using a X509 certificate. Writing an arbitrary code to unlock_code won't work, because the code will be verified the same way the code.img is verified.
Overwrite the certificate a custom one and create a custom code. For this approach we have to understand the verification process and we obliviously need to know the location of the certificate and write access.
There is some variable called "production" we would have to change. The variable is obtained by
Code:
MOV R3, 0xFD511004
LDR R0, [R3,R0,LSL#4]
AND R0, R0, #1
R0 has the value 0x5C.
In C pseudocode:
Code:
int production = *(0xFD511004 + 92*2^4) & 1;
The default value of that variable is 1.
Anyone with ideas here?
vortox said:
I have examined aboot for some time now and I can think of 3 methods to unlock the bootloader:
Provide the unlock code. The code seems to be a 512 byte image, that is flashed by "fastboot flash unlock code.img". The code is somehow verified using a X509 certificate. Writing an arbitrary code to unlock_code won't work, because the code will be verified the same way the code.img is verified.
Overwrite the certificate a custom one and create a custom code. For this approach we have to understand the verification process and we obliviously need to know the location of the certificate and write access.
There is some variable called "production" we would have to change. The variable is obtained by
Code:
MOV R3, 0xFD511004
LDR R0, [R3,R0,LSL#4]
AND R0, R0, #1
R0 has the value 0x5C.
In C pseudocode:
Code:
int production = *(0xFD511004 + 92*2^4) & 1;
The default value of that variable is 1.
Anyone with ideas here?
Click to expand...
Click to collapse
I can't answer that, but @Cpasjuste may be revealing something soon according to this thread: http://forum.xda-developers.com/kindle-fire-hdx/development/cm-11-t2971457
I was using some information from this source aboot reverse engineering to try and figure more out about the structure of aboot. The fact that the strings are obfuscated and don't appear through the decompiled functions was the biggest hurdle I was running into starting with this. I tried to use the open source little kernel code to see if a few of these functions could be put into better pseudocode and perhaps crack the string obfuscation to be able to xref more strings throughout the decompilation of the hundreds of functions. Just kept getting stuck.
I've been using this loader for IDA. I see a lot of strings and they have been very useful .
Further I've found the certificate in the aboot partition. This means my 2. suggestion probably wouldn't work.
This leaves me with 2 two possible options:
Brute force the image (unlikely)
Looking at the production variable to see if it can be safely overwriten without a side effect
vortox said:
I've been using this loader for IDA. I see a lot of strings and they have been very useful. [/LIST]
Click to expand...
Click to collapse
Off-topic,
you can use this loader to load sbl1.mbn, sbl2,mbn, sbl3.mbn, aboot.mbn tz.mbn and rpm.mbn?
maybe a debricking solution...
aaronkatrini said:
Off-topic,
you can use this loader to load sbl1.mbn, sbl2,mbn, sbl3.mbn, aboot.mbn tz.mbn and rpm.mbn?
maybe a debricking solution...
Click to expand...
Click to collapse
Nope. It's just to load those files into IDA PRO and helps reverse engineering them.
vortox said:
I've been using this loader for IDA. I see a lot of strings and they have been very useful .
Further I've found the certificate in the aboot partition. This means my 2. suggestion probably wouldn't work.
This leaves me with 2 two possible options:
Brute force the image (unlikely)
Looking at the production variable to see if it can be safely overwriten without a side effect
Click to expand...
Click to collapse
Could you share the certificate? I think there should be no legal problem with that.
@vortox
This article may refer to the production variable your talking about.
http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
Seems to be following CVE: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0974
Besides of that, has somebody tried to insert the kexec module into the kernel? http://forum.xda-developers.com/galaxy-note-3/devs-only/kernel-kernel-execution-loading-custom-t2812650
D0ubl3_X said:
Could you share the certificate? I think there should be no legal problem with that.
Click to expand...
Click to collapse
I will try my best to obtain the cerificate.
@vortox
This article may refer to the production variable your talking about. http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
Click to expand...
Click to collapse
Thanks for the link.
Seems to be following CVE: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0974
Click to expand...
Click to collapse
I will take a look at that.
Edit:
@D0ubl3_X
Here the certificate used for checking the unlock code. http://www45.zippyshare.com/v/82885181/file.html
Edit2 :
The post in the blog does not match the CVE. This is the right one. This exploit hat been patched.
But the CVE you posted seems unpatched. Atleast on my device with .3.2.4. The newer version are probably patched.
Edit3:
Another possible exploit: https://www.codeaurora.org/projects...tion-leads-to-signature-forgery-cve-2014-0973
September 4th - @jcase said : "If you can port it yourself, feel free, more than one of these works on the HDX https://www.codeaurora.org/projects/security-advisories ..."
There are 18 exploits, but at least one of them works!