• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Behold 2 flashing kernel and security (?)

kam187

Android Expert
Aug 3, 2009
1,320
46
UK
So I decided to split this off to a new thread, and hope some coders will join in and start compiling a kernel. We could then merge this with the galaxy asop effort.

Here's a bit more technical information.

Galaxy

The galaxy flash files are just yaffs images and a zimage (and of course AMSS) all tarred up. The tar format needs to be oldgnu for odin to accept it.
There's no protection at all. Thats because the glaxy is released completly security unlocked (simlocks are different, not the same thing). You can flash any image you like.

AMSS - arm ELF binary for baseband
kernel - zimage
system - standard yaffs image
recovery - standard recovery format
tar - oldgnu style standard tar file

The Galaxy also has a mtd device driver which means you can read/write its partitions with dd.

/dev/mtd

Behold 2

The behold has the same image format, yaffs, zimage and AMSS. See below for specific differences per image:

AMSS - arm ELF binary for baseband

The behold 2 also contains a partitions file. This is most likely for the AMSS, and allows the layout of the baseband to change. I'm not sure if the galaxy supports the same, but probably does.

Its safe to say you should NOT try to flash an AMSS from galaxy to the behold or vice versa.

Since the radios have the same functionality, and we don't know how to recompile and AMSS, you should never flash any new AMSS with a custom rom. Only flash AMSS with official updates.


> kernel - zimage

Just like the Galaxy this is a standard zimage. There's nothing special about it and you can modify it however you want. BUT in order for it to flash the tar file needs a special header (see tar below)

Since we can change the kernel, upgrades to newer OS versions is now possible.


> System - standard yaffs image

It appears the system image format on the behold2 is DIFFERENT to that on the galaxy. If you flash a galaxy system file onto the behold 2 you will most likely end up with a brick.

I suspect the behold 2 file has the flash address embedded inside it. Flashing the galaxy system file writes to a bad address killing the bootloader. When i say BRICK i really mean BRICK. No life in the phone at all, it wont even charge. so DONT DO IT!

In order to write a custom system to the behold 2, we will need to untar or unyaffs the modified system from the sdcard on first boot. This can easily be accomodated in the init.rc of you're modified zimage.


> Recovery - standard recovery format (protected?)

The recovery image format seems to be the same - standard android format with a ramdisk, kernel etc. However flashing it using odin doesnt work. There is some sort of protection which is preventing the image being flashed. I havnt looked thoroughly at this and someone really should. I suspect either it is signed (unlikely since the other images dont seem to be protected), or there is a write address embedded in the file, like the system file.

It would be nice to be able to flash a custom recovery, or even boot from a ramdisk, but I think this wont be simple.


> tar - oldgnu style standard tar file (with header)

Both the galaxy and behold2 have a header at the top of tar. The galaxy will flash regardless of if this header is intact or not. The behold 2 however MUST have this header intact for it to flash anything.

It seems this header contains the size, and write address of the zimage. Its possible the addresses of other images like the recovery are embedded in this too. We should look more closely at this header, especially between firmware versions to see what changes. In the mean time to replace the zimage, just hexedit your new image over the existing 'kernel' file in the tar. Remember you need to keep the size the same, so pad with zero's or just leave the remainder of the old kernel in the extra space.


Progress?

The sources that samsung provided are missing patches. This means you can't compile the behold kernel simply.

Also because the partitions are different, and the memory layout is different (compare msm/board-init files) a standard galaxy kernel will not boot.

Making the changes to get it to boot are not that dificult. It would be nice if someone who actually has a behold 2 and linux knowledge could have a look at this. It takes far to long for me to do this remotly, and frankly I just dont have that much time.

All you need to do is:

- compile the galaxy kernel (test your environment)
- replace board-init in the galaxy source with that from behold2 sources
- turn on linux console

Now boot and check if the galaxy kernel is able to see device's for each partition on the behold. If not you'll need to copy the disk/flash driver from the behold 2 sources.

Once you are able to get that far, you can merge the changes into the i7500 asop project and add a kernel switch for the behold 2. Now all galaxy 2.x progress will be directly transferable to the behold2.

You will need to make a change to the init.rc to mount the drives and unyaffs the modified system.img the first time it boots. Again a simple change.

Good luck!

EDIT: Forgot to mention HOW to flash a kernel.

1) Take the stock behold 2 PDA tar file.
2) Use jzip (must be jzip on windows, winzip etc wont work) to remove ALL files except the kernel.
3) Extract the kernel file for reference (leave it in the tar too)
3) Download HexWorkshop or similar Hex utility.
4) Use Hex Workshop compare function to compare 'kernel' and the tar. It will highlight the kernel in the tar file
5) Open new kernel in Hexworkshop. Select all and Copy
6) Highlight the same number of bytes in the tar file and paste over the original kernel
7) Flash with Odin (JUST this tar) as PDA, and of course selecting the behold ops file.

By Kam187... Little Miss happen with the clean up.... Sorry guys....
 
> tar - oldgnu style standard tar file (with header)

Both the galaxy and behold2 have a header at the top of tar. The galaxy will flash regardless of if this header is intact or not. The behold 2 however MUST have this header intact for it to flash anything.

It seems this header contains the size, and write address of the zimage. Its possible the addresses of other images like the recovery are embedded in this too. We should look more closely at this header, especially between firmware versions to see what changes.

I've checked the tar files provided on the forums for use with ODIN and they seem to infact be normal UStar file headers. These are different from standard tar headers in that they preserve a few extra pieces of information such as the owning user and group names for each file in the archive.

The only unique data I see in the headers that may need to be preserved are:

mode: 0644
uid: 2004
gid: 5670
owner: behold2
group: android

Additionally the header fields are null padded/terminated instead of with spaces as some tar programs prefer. I don't think this should matter though as both are acceptable for the format.

I don't see any non-standard data put in the headers. Now I may be looking at the wrong files so feel free to point towards anything you think needs to be looked at and include the byte offsets too.

If you try to modify the tar header directly be aware that the header includes a checksum and this will have to be updated as well.
 
Upvote 0
Is the Method of Un-splitting the Boot.img and splitting them back Different from a G1? I recompile the ramdisk with the Kernel I've edited & I get a none booting Phone that tries to boot, but then loops & tries again...

I can add the original Binary ( Hex ) back in all day & produce a booting phone.. Though, it my not like my split * un-split script that I always used for the mytouch & G1's.

Can anyone confirm or deny this is the Cause of my Failure?
Thanks,
~BH_MAN
 
Upvote 0
RE UStar - you're right! My knowledge of Tar formats is pretty limited.

BH_MAN - What modifications did you do? Did you compile the original BH2 kernel somehow (there were missing patches when I last checked).

Remember the partition structure is different on the BH2. Enable LINUX boot console and use that to check why its looping.
 
  • Like
Reactions: BH_MAN
Upvote 0
RE UStar - you're right! My knowledge of Tar formats is pretty limited.

BH_MAN - What modifications did you do? Did you compile the original BH2 kernel somehow (there were missing patches when I last checked).

Remember the partition structure is different on the BH2. Enable LINUX boot console and use that to check why its looping.

I used the Factory rom with Edits to the Ramdisk Default.prop for ADB service, I wanted to start small and work my Way up after I Successful Boot.img. Like they say, You must crawl before you walk :)

Other than that, the boot.img is un-touched. So I was thinking it was how I'm un-splitting the Image & the script I'm using could be wrong..
 
Upvote 0
Yeah there's patches missing :(

You should try to compile the galaxy kernel and enable linux console. Copy the board-init file over and try to boot it. Then move drivers over one by one.

If you can identify which bh2 drivers you need in the galaxy kernel, you can easily compile the galaxy 1.6 for behold 2 when they release the source, or the 2.1 ASOP galaxy build we are working on :)
 
Upvote 0
Yeah there's patches missing :(

You should try to compile the galaxy kernel and enable linux console. Copy the board-init file over and try to boot it. Then move drivers over one by one.

If you can identify which bh2 drivers you need in the galaxy kernel, you can easily compile the galaxy 1.6 for behold 2 when they release the source, or the 2.1 ASOP galaxy build we are working on :)

Thats an idea, but from experience as a linux sysadmin, kernel drivers tend to be stamped with the kernel version, etc, they were built against. So simply pulling out the driver module (*.ko) and putting it with a different kernel may not work. But hey go for it.

As for finding the missing bits from the released kernel source, I doubt it. Drivers are allowed to be closed source and as such they are under no obligation to release them.
 
Upvote 0
No i dont mean just copy the .ko, I mean copy the drivers source over and recompile it in the galaxy build :)

The drivers are going to be very similar. I expect the disk/partitions to be the main problem. Also definatly the board-init which handles the memory banks.

?????
I haven't poked around inside the phone much, but looking at the released source from the website, besides the missing patches referenced in their build scripts, there are driver sources missing. I think one was called rfs. Basically I tried to build the kernel and it would stop at a Kconfig inside kernel/drivers because a driver source wasnt there.
 
Upvote 0
?????
I haven't poked around inside the phone much, but looking at the released source from the website, besides the missing patches referenced in their build scripts, there are driver sources missing. I think one was called rfs. Basically I tried to build the kernel and it would stop at a Kconfig inside kernel/drivers because a driver source wasnt there.

RFS is probably the driver for Samsung's "Robust File System". Its specially designed to take advantage of their flash memory modules. I've seen instructions on how to build a kernel with it so I assume the source is out there.

SAMSUNG Semiconductor - Products - Flash - Flash Software

http://www.samsung.com/global/busin...cts/flash/downloads/RFS_130_Porting_Guide.pdf

Looks like the only way to obtain it is via license with Samsung. Maybe an alternative flash file system (like yaffs2) could be substituted when building the kernel.
 
Upvote 0

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones