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
Related
I know the linux and android kernel are different, but not much if you can already chroot into ubuntu. My question is, how do I make/compile a kernel that can boot with Ubuntu NATIVELY? Not chroot, but flash to the internel memory (maybe have to cut some bloatware out for it to fit). Or could I even just use a kernel from android?
I have wondered the same thing! I would love to turn my old Evo into a dedicated BT5 device! No need for Android OS as it just slows down BT5. I am interested in looking into that but and not sure exactly atm.
I get the impression this would be a 10x greater effort than a build of Cyanogenmod.
How so? To my understanding, TECHNICALLY we could have cyanogenmod 6, correct? Since we have froyo source...but thats not the point. With a stripped down linux distro (768mb if we could merge data and system partitions together), and a kernel built for the phone (linux kernel, not android) it should be COMPLETELY possible. My question atm is, how could I compile a kernel compatible with linux (or will the android one work)?
You mean something like this?
http://forum.xda-developers.com/showthread.php?t=892877
No, thats the chroot+vnc method. Basically that runs android in a vm, which is not what I am talking about. I mean installing linux to the internal memory, completely removing android. That way linux could use all 512mb of ram, the only downside is losing android.
ugothakd said:
No, thats the chroot+vnc method. Basically that runs android in a vm, which is not what I am talking about. I mean installing linux to the internal memory, completely removing android. That way linux could use all 512mb of ram, the only downside is losing android.
Click to expand...
Click to collapse
I think that would run a heavy risk of bricking the device since you'd have to overwrite the entire memory.
Maybe, but if you just flashed the root file system to the system (256mb), you would still have the bootloader recovery etc. partitions. Or I'm not exactly sure, maybe delete the data and system partitions and create a new 768mb partition. The only problem is I cant find anything to handle the partitions, fastboot is the closest, and fastboot doesn't work/isnt supported.
You're delving into an area that already has been delved in before. Considering the fact nobody has gotten this working ever, I would go so far as to say you're wasting your time. By all mean have at it, but keep in mind you will need a linux kernel modified in such a way that it will completely support this hardware or it would be useless. Good luck to you!
Sent from my SPH-D700 using XDA Premium App
http://blogs.sonyericsson.com/wp/2011/05/06/how-to-build-a-linux-kernel/
^^^That is the type of kernel suitable for a distro like Ubuntu, correct? Building a kernel with the samsung sources using that guide, should give me a kernel that can be used with linux, correct? I don't see why it is so hard... If you can port linux to a device such as the hd2 whats so different about running it on the epic? Linux and android are very close... the only problem I'm having is finding a way to get a .img to the device.
thomasskull666 said:
You're delving into an area that already has been delved in before. Considering the fact nobody has gotten this working ever, I would go so far as to say you're wasting your time. By all mean have at it, but keep in mind you will need a linux kernel modified in such a way that it will completely support this hardware or it would be useless. Good luck to you!
Sent from my SPH-D700 using XDA Premium App
Click to expand...
Click to collapse
not to mention a few of the drivers are closed source and aren't likely to be compatible with any other kernel version be it one of samsung's kernels or one from linux.....that isn't to say it is impossible but definitely a hurdle
ugothakd said:
http://blogs.sonyericsson.com/wp/2011/05/06/how-to-build-a-linux-kernel/
^^^That is the type of kernel suitable for a distro like Ubuntu, correct? Building a kernel with the samsung sources using that guide, should give me a kernel that can be used with linux, correct? I don't see why it is so hard... If you can port linux to a device such as the hd2 whats so different about running it on the epic? Linux and android are very close... the only problem I'm having is finding a way to get a .img to the device.
Click to expand...
Click to collapse
the first line of that article..."Since the launch of the unlock boot loader site, we have received a lot of really great feedback."
we do not have a modified boot loader and our bootloader is a 2 stage process...i believe the first one is efuse protected...which unless exploited cannot be modified...i'm not sure what kind of checking is done to the secondary bootloader..but one mistake with either of these files you have yourself an expensive paperweight that odin will not fix (no download mode)
edit: i see that site goes on to talk about rebuilding the kernel but still important to remember that stuff about our bootloaders
So even if the kernel worked, the drivers were perfect (which wouldn't be, I know that) and I somehow got an image to the phone it wouldn't boot because of the bootloader?
http://forum.xda-developers.com/showthread.php?t=933667
It can be done but it's not an easy task. This guy has Ubuntu natively booting on the Galaxy Tab.
He's been working on it for a long time and I still don't think it's anywhere close to fully functional, it probably never will be.
Ubuntu + Mobile Phones just weren't meant to be. However.. as this shows... if you devote enough hours to something, anything is "sorta" possible.
There's a thread in the fascinate forum that's relevant to this, about building jigs.
The issue is, as you mentioned, the bootloader. Apparently, it is much like the BIOS on a PC, where you have the option to boot up from different sources. However, our bootloader has those options removed (it actually might have been disabled by hardware, but I can't remember), and only includes normal bootup, recovery kernel, and the kernel/partition that handles download mode.
Obviously you know all this. The developer there is working on a solution, and it could end up being either a software or hardware hack. I suggest you search for the thread (I would if I wasn't on my app).
However, this is relevant because his goal is different than yours, but will most likely be your solution. Rather than modifying the bootloader to handle a larger partition or a linux kernel, it would be easier to get the bootloader to do something it was intended to do back at the factory: boot from USB. There are unused pin configurations that were meant for this, and if enabled could allow a lot of possibilities. Booting ubuntu would be just the tip of the iceberg.
The developer actually has gotten as far as getting a boot log from the very first, barebone bootloader (whatever the acronym is), and shows it searching for usb host or whatever. I'm gonna see if I can dig up the link.
EDIT: er, maybe not fascinate forum, I'm having trouble finding it
Sent from my SPH-D700 using XDA Premium App
Try searching for the SGS Ubuntu attempts. I know that someonne in #ubuntu-arm has gotten it to a usable state on his SGS. However, be prepared to lose functionality.
Question is why. There won't be an accelerated X server, and if you are looking to target a embedded linux surely there are better systems out there. You'll also have to deal with the keymappings afaik because that's apparently dealt through system_server via keymaps, and not the kernel.
-- Starfox
Starfox said:
Question is why.
-- Starfox
Click to expand...
Click to collapse
Hacker Mantra: Cause you can
Why climb Mt. Everest? Cause you can.
Why put linux on every device out there? Cause you can.
tyl3rdurden said:
Hacker Mantra: Cause you can
Why climb Mt. Everest? Cause you can.
Why put linux on every device out there? Cause you can.
Click to expand...
Click to collapse
True that, it is pretty damn adaptable that's for sure.
Sent from my SPH-D700 using XDA Premium App
haha found it!
relevant http://forum.xda-developers.com/showthread.php?t=1065318
I own a tegra 2 device that can boot BT natively, I know it's nowhere close to our chipset but perhaps it could lead somebody with the right skillset down this road for the Epic; http://forum.xda-developers.com/showthread.php?t=1075054
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,
while searching around the web I saw this very interesting and hot topic on CAF.
https://www.codeaurora.org/2010/03/02/little-kernel-based-android-bootloader/
Sources:
https://github.com/travisg/lk/commits/master
fixes for 7x30:
https://android.googlesource.com/kernel/lk/+/qcom-dima-7x30-fixes/AndroidBoot.mk
Simlar projects:
http://forum.xda-developers.com/showthread.php?t=2147997
http://rtammekivi.tumblr.com/post/18995217696/working-little-kernel
http://www.pocketpc.ch/htc-hd2-andr...smiths-little-kernel-loader-installation.html
The thing is, I'm not that good to compile it for our device.
I hope someone more advanced than me is able to compile that without hardbricking his phone...
Regards
trapjul
AW: [DEV] MSM7x30 Open Source Bootloader '(L)ittle (K)ernel'
This looks very interesting. But i dont know why you think this will get us dualboot?
But i would really love to.have fastboot. Its very handy and easy to use.
Sent from my GT-I9001 using xda app-developers app
XeLLaR* said:
This looks very interesting. But i dont know why you think this will get us dualboot?
But i would really love to.have fastboot. Its very handy and easy to use.
Sent from my GT-I9001 using xda app-developers app
Click to expand...
Click to collapse
Because the current problem at Dual Boot is the switch between the kernels. With an Open Source Bootloader we could switch between them mich more easy.
trapjul said:
Because the current problem at Dual Boot is the switch between the kernels. With an Open Source Bootloader we could switch between them mich more easy.
Click to expand...
Click to collapse
Dual boot needs some where for storing second rom 's data / cache / & most important thing is BattertState which can cause lots of problem in dual ROM mod !
Another thing :: we have secondary boot loader which made our device harder to brick so do not worry about ! Your device just breaks when you wipe both boots !
Dead thread ? I think LK is a good project !?!
I think this is a good start!
But I'm sorry, I have too less knowledge of Linux/Android :/
I can't help you...
Maybe I can test it
(of course when there is no risk that I break my phone )
I think it's difficult to make it for our device full working, that's the problem.
Harrocan said:
I think it's difficult to make it for our device full working, that's the problem.
Click to expand...
Click to collapse
No !
You need to just make up it for MSM7X30 , boot loader loads up by SoC then loads Boot.img ! It won't need any GPU driver or WiFi driver or can driver ! Just you need to port it to msm7x30 which the LK progect supports it !
I've tried to compile it several times but I couldn't make it work for our board so far.
Also how in earth will we implement this into our system ?
Anyways I think this is a great project. I would love to make a custom bootloader if the information is there.
AW: [DEV] MSM7x30 Open Source Bootloader '(L)ittle (K)ernel'
Maybe a look here is helpful: https://github.com/chirayudesai/android_bootable_bootloader_lk
Sent from my GT-I9100 using xda app-developers app
Isn't it what we need? https://www.codeaurora.org/cgit/ext...sm7630_surf/tree/AndroidBoard.mk?h=jb_2.1.3.7
Tapatalk 4 küldve GT-I9001-ről
czobor said:
Isn't it what we need? https://www.codeaurora.org/cgit/ext...sm7630_surf/tree/AndroidBoard.mk?h=jb_2.1.3.7
Tapatalk 4 küldve GT-I9001-ről
Click to expand...
Click to collapse
what i see the problem in:
your suggestion is for msm7630.
we have/need msm7x30.
Lei M said:
what i see the problem in:
your suggestion is for msm7630.
we have/need msm7x30.
Click to expand...
Click to collapse
That's the same.
Tapatalk 4 küldve GT-I9001-ről
czobor said:
That's the same.
Click to expand...
Click to collapse
do you have a source for your information?
it's very strange:
according to http://en.wikipedia.org/wiki/MSM7000 it could be the same but if you take a look here: http://en.m.wikipedia.org/wiki/Snapdragon_(system_on_chip) you see that the msm7630 only has 800MHz cpu
edit:
http://snapvoip.blogspot.co.at/2009/11/qualcomm-introduces-new-mobile-msm7x30.html?m=1
says that msm7x30 is a family of chipsets.
Before doing any thing we have to establish a UART or JTAG Connection to board
I am a total noob at this, but:
My opinion is that if we can access and modify or divide /system /data and /cache on out like, it would be easy to install 2 ROMs.
For example system is mmcblk08
Divide it in 08 and 09.We have 2x /system.Do this with /data, /cache /ramdisk.
But booting is a prob here.
I may be wrong.I don't know if we can touch those partitions.
Costinutz32 said:
I am a total noob at this, but:
My opinion is that if we can access and modify or divide /system /data and /cache on out like, it would be easy to install 2 ROMs.
For example system is mmcblk08
Divide it in 08 and 09.We have 2x /system.Do this with /data, /cache /ramdisk.
But booting is a prob here.
I may be wrong.I don't know if we can touch those partitions.
Click to expand...
Click to collapse
No. We cannot do that. mmcblk0p9 is the ADSP partition (it deals with encoding and decoding video and things like this). And, we cannot modify the bootloaders either, that would require a direct hardware connection through UART. This CAF project is really not that useful for our device...
What we can do for dual-booting is simply partition the ext-sd like we did with the /data on bricked emmc devices, but I'm not sure the system can be mounted on it....
Anyways, managing two backups of two different ROM's can give the same result, but it takes more time.
educk said:
No. We cannot do that. mmcblk0p9 is the ADSP partition (it deals with encoding and decoding video and things like this). And, we cannot modify the bootloaders either, that would require a direct hardware connection through UART. This CAF project is really not that useful for our device...
What we can do for dual-booting is simply partition the ext-sd like we did with the /data on bricked emmc devices, but I'm not sure the system can be mounted on it....
Anyways, managing two backups of two different ROM's can give the same result, but it takes more time.
Click to expand...
Click to collapse
This was just an example, i didn't even know it mmcblk09 exists.
educk said:
And, we cannot modify the bootloaders either, that would require a direct hardware connection through UART. This CAF project is really not that useful for our device...
Click to expand...
Click to collapse
As far as I know the Xperia T hasnt UART too. Wherefor do you need UART? I would just override the bootloader partitions via command line because in a running system the bootloader shouldnt be mounted or even used.
At all it shouldnt be toooo impossible because it has intial support for 7x30...
trapjul
trapjul said:
As far as I know the Xperia T hasnt UART too. Wherefor do you need UART? I would just override the bootloader partitions via command line because in a running system the bootloader shouldnt be mounted or even used.
At all it shouldnt be toooo impossible because it has intial support for 7x30...
trapjul
Click to expand...
Click to collapse
How can you debug a bootldr if no UART is given? The first compiled LK-bootldr will 100% not work correctly, which means the phone will NOT work at all after that! Then you need a UART connection, to revert to the old bootloader or to debug through UART. The Final WORKING build can be flashed through terminal, but the developer who has to get through all the debugging must have UART.
UART
Sometime in the next few days (maybe this weekend), we will be merging https://gerrit.omnirom.org/#/c/1169/
This will allow TWRP to build properly on userdebug builds. As a warning, it WILL break anyone who doesn't have TWRP config in their device tree when it is merged! (You will get errors about missing files in bootable/recovery/res if I recall correctly)
See http://forum.xda-developers.com/showthread.php?t=1943625 for info on various TWRP device tree configurations. At an absolute minimum I believe you will need the device resolution added to avoid breaking your build.
For additional details, see:
Find5:
https://gerrit.omnirom.org/#/c/1633/
Yuga:
https://gerrit.omnirom.org/#/c/1682/ (Depends on fusion3-common changes)
pollux-common (pollux_windy and pollux don't have specific items and just inherit common):
https://gerrit.omnirom.org/#/c/1155/ (Depends on fusion3-common changes)
fusion3-common:
https://gerrit.omnirom.org/#/c/1152/
flo:
https://gerrit.omnirom.org/#/c/1634/
mako:
https://gerrit.omnirom.org/#/c/1635/
@Entropy512
Hey there!
Add me on hangouts sir:
[email protected]
What about this TWRP configuration for honami?
https://github.com/Omni-Xperia/android_device_sony_rhine-common/commits/cm-10.2
i have built one for pollux and it works
Just wondering, does this recovery actually get flashed when installing? I.e. do all the parameters need to be set properly to build the ROM, or just enough to not break the build? I'm already using TWRP and I'm not sure of the right BoardConfig.mk settings but if I'm just trying to port it to my device that shouldn't matter right? Though I noticed there are device trees on the TeamWin GitHub for building TWRP, for my device (n8013) it seems out of date.
Edit: well cool, turned out not to matter and it seems like my build actually booted, I'm pleasantly surprised .
iofthestorm said:
Just wondering, does this recovery actually get flashed when installing? I.e. do all the parameters need to be set properly to build the ROM, or just enough to not break the build? I'm already using TWRP and I'm not sure of the right BoardConfig.mk settings but if I'm just trying to port it to my device that shouldn't matter right? Though I noticed there are device trees on the TeamWin GitHub for building TWRP, for my device (n8013) it seems out of date.
Edit: well cool, turned out not to matter and it seems like my build actually booted, I'm pleasantly surprised .
Click to expand...
Click to collapse
Pretty much what happens is, TeamWin will get a device tree, modify it to be compatible with TWRP, and use that to build for that device. The actual core source for TWRP itself is in a separate repository that is constantly updated. So pretty much its like this : once your device tree is modified to build TWRP for your device during a build, it will build using TWRP source , which is android_bootable_recovery, for omnirom specifically.
Think of it like this: you setup a device tree to say "build TWRP using this source code" . once the device tree is looking for that source code, it'll always build twrp without issues (for the most part). Now the location your device tree looks to is the twrp source itself, which is updated and improved all the time, so if you're device tree is setup properly for tarp, you will have a recovery.img in your out directory after a build that is as up-to-date build of twrp to when you last did a repo sync
Sent from my SGH-I337 using Tapatalk
jakew02 said:
Pretty much what happens is, TeamWin will get a device tree, modify it to be compatible with TWRP, and use that to build for that device. The actual core source for TWRP itself is in a separate repository that is constantly updated. So pretty much its like this : once your device tree is modified to build TWRP for your device during a build, it will build using TWRP source , which is android_bootable_recovery, for omnirom specifically.
Think of it like this: you setup a device tree to say "build TWRP using this source code" . once the device tree is looking for that source code, it'll always build twrp without issues (for the most part). Now the location your device tree looks to is the twrp source itself, which is updated and improved all the time, so if you're device tree is setup properly for tarp, you will have a recovery.img in your out directory after a build that is as up-to-date build of twrp to when you last did a repo sync
Sent from my SGH-I337 using Tapatalk
Click to expand...
Click to collapse
Ah thanks, that's useful, but not really what I was asking about. I got that part, I just wanted to know if flashing the ROM actually flashes the recovery that was built in tree as well, and it seems like the answer is no (at least for me my recovery didn't change). As such it seems like the main point that Entropy512 was making is that if you don't add the resolution to your BoardConfig.mk the build won't complete, but otherwise it doesn't really matter if you set the other parameters correctly.
The paths I was referring to were the mount points for the internal and external SD, I thought they had changed since ICS but I think they might still have symlinks to the old paths for compatibility's sake.
iofthestorm said:
Ah thanks, that's useful, but not really what I was asking about. I got that part, I just wanted to know if flashing the ROM actually flashes the recovery that was built in tree as well, and it seems like the answer is no (at least for me my recovery didn't change). As such it seems like the main point that Entropy512 was making is that if you don't add the resolution to your BoardConfig.mk the build won't complete, but otherwise it doesn't really matter if you set the other parameters correctly.
The paths I was referring to were the mount points for the internal and external SD, I thought they had changed since ICS but I think they might still have symlinks to the old paths for compatibility's sake.
Click to expand...
Click to collapse
You mention mount points for the SD, I have been building for the HTC One S and while all the mount points in the my ville/rootdir are correct for example in the fstab.qcom file
# SD card
/devices/platform/msm_sdcc.1/mmc_host/mmc0 /storage/sdcard0 auto defaults voldmanaged=sdcard:36
The rom shows it as unavailable/missing and asks me to format the SD card, I tried and the message keeps popping up.
Basically my question is, will building twrp recovery for the device sort out the missing SD card.
iofthestorm said:
Ah thanks, that's useful, but not really what I was asking about. I got that part, I just wanted to know if flashing the ROM actually flashes the recovery that was built in tree as well, and it seems like the answer is no (at least for me my recovery didn't change). As such it seems like the main point that Entropy512 was making is that if you don't add the resolution to your BoardConfig.mk the build won't complete, but otherwise it doesn't really matter if you set the other parameters correctly.
The paths I was referring to were the mount points for the internal and external SD, I thought they had changed since ICS but I think they might still have symlinks to the old paths for compatibility's sake.
Click to expand...
Click to collapse
flashing a ROM will never flash a recovery, but some devices have the recovery as part of the boot.img, so when you flash a new kernel, for example, you will be flashing a new recovery as well
iofthestorm said:
Just wondering, does this recovery actually get flashed when installing? I.e. do all the parameters need to be set properly to build the ROM, or just enough to not break the build? I'm already using TWRP and I'm not sure of the right BoardConfig.mk settings but if I'm just trying to port it to my device that shouldn't matter right? Though I noticed there are device trees on the TeamWin GitHub for building TWRP, for my device (n8013) it seems out of date.
Edit: well cool, turned out not to matter and it seems like my build actually booted, I'm pleasantly surprised .
Click to expand...
Click to collapse
Ideally you should have a goal of building a fully functional recovery.
However, with the exception of older Samsungs (galaxys2 family and older for the most part) and Sonys, you don't NEED the recovery to be fully functional. With the galaxys2 family and Sonys - yeah you need it. (Actually Sonys do have a workaround, but the GS2 family does not.)
That said, leaving a partially configured recovery configuration is bad practice.
jakew02 said:
flashing a ROM will never flash a recovery, but some devices have the recovery as part of the boot.img, so when you flash a new kernel, for example, you will be flashing a new recovery as well
Click to expand...
Click to collapse
Yeah, that'd be what I was thinking of. My first Android phone, the Samsung Fascinate, had a weird setup like that.
Entropy512 said:
Ideally you should have a goal of building a fully functional recovery.
However, with the exception of older Samsungs (galaxys2 family and older for the most part) and Sonys, you don't NEED the recovery to be fully functional. With the galaxys2 family and Sonys - yeah you need it. (Actually Sonys do have a workaround, but the GS2 family does not.)
That said, leaving a partially configured recovery configuration is bad practice.
Click to expand...
Click to collapse
Alright, that's what I figured. Yeah, I'll fix it later for sure, I just didn't have the time this weekend and I didn't plan on submitting a patch to make it officially supported anyway, as I just wanted to try it out for myself at this point. And I figured since it's the n8013 you'd be the best person to support that anyway, I only know enough to get myself in trouble.
(do you still have your N8013 by the way?)
iofthestorm said:
Yeah, that'd be what I was thinking of. My first Android phone, the Samsung Fascinate, had a weird setup like that.
Alright, that's what I figured. Yeah, I'll fix it later for sure, I just didn't have the time this weekend and I didn't plan on submitting a patch to make it officially supported anyway, as I just wanted to try it out for myself at this point. And I figured since it's the n8013 you'd be the best person to support that anyway, I only know enough to get myself in trouble.
(do you still have your N8013 by the way?)
Click to expand...
Click to collapse
I do, but it mostly collects dust these days. At some point I'll try to get Omni up on it, I've just had too much else to do lately.
So another question, what is the mechanism by which twrp.fstab is used? I decided to flash my recovery for the heck of it (sidenote: on the 4.4 branch it still has the AOSP recovery in the manifest, but I just added omnirom/android_bootable_recovery to my local_manifests.xml) and it actually runs but nothing appears to be mounted. I notice that some TWRPify commits have a twrp.fstab but they don't do a PRODUCT_COPY_FILES for that file so I'm wondering how it even gets used? I see for example that your commit for flo is doing it: https://gerrit.omnirom.org/#/c/1523/ but then this guy didn't actually add it to PRODUCT_COPY_FILES for hammerhead: https://gerrit.omnirom.org/#/c/1588/ . Is that just a mistake on Mithun's part, or am I misunderstanding how this fstab is used? Is there any reason for it to be any different than the fstab.smdk4x12 in the device tree? Just trying to figure out how things work here.
Also, is it preferable to use the by-name symlinks over the raw /dev/block/mmcblk0p9 type device identifiers? Should I open another thread for this?
My hackjob device trees are https://github.com/ibrahima/android_device_samsung_n80xx-common and https://github.com/ibrahima/android_device_samsung_n8013 .
Edit: I guess my main question is, how is that twrp.fstab different from TARGET_RECOVERY_FSTAB? Some of the device trees with it (eg. your flo changeset that I linked above) don't seem to set this unless I'm looking in the wrong place, and I've seen at least one that sets TARGET_RECOVERY_FSTAB to /etc/twrp.fstab. Found this quote from @Dees_Troy:
You can create a twrp.fstab file and then use PRODUCT_COPY_FILES += device/oem/codename/twrp.fstab:recovery/root/etc/twrp.fstab to get the twrp.fstab into the recovery ramdisk
Click to expand...
Click to collapse
from http://forum.xda-developers.com/showthread.php?p=45164117 . If I already have an /etc/recovery.fstab it should work without the twrp.fstab right?
Edit2: Oh, derp, the twrp.fstab explanation is in the "How to Compile TWRP" thread. Filing away for later reading... (this is fun and all, but my professors aren't going to accept an Android 4.4 build in place of my homework )
Edit3: My god, this is basically me: http://xkcd.com/356/ and the truck is my homework/midterms... welp, at least I got a recovery with proper fstab, so for anyone else trying to TWRPify yes, you do need a twrp.fstab because the new fstab format in Android 4.3+ is not used by TWRP yet so you need one in the older format for it to mount your stuff. Haven't actually tried flashing anything with my recovery yet, but I feel like it should probably work, but again... trucks and all that
If it's not in PRODUCT_COPY_FILES - yes, that is a mistake.
(hopefully that commit isn't merged - accessing omni's gerrit is problematic for me from some locations. If the TWRP FSTAB is added to the device tree but isn't being copied that's grounds for a -1)
Yeah, he -1ed it himself for other reasons I suppose. Cool cool, looks like I'm learning stuff
By the way, after the hard drive meltdown and subsequent loss of two weeks of gerrit data, a lot of the links in your OP are broken in that they go to different tickets which have now subsumed those ticket numbers that were lost. For those who are curious and have been foiled by Gerrit's somewhat obtuse search box, if you type message:TWRP in the search box (to search commit messages) you'll find examples.
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!