LG GW620 Development/Kernel hacking (Have LG source mods + trying to get 2.0 working)

Zacpod · Nov 26, 2009

We'd still need to be able to make the required mods to the mbn, which means somehow extracting the mtd image and reading/changing the yaffs2 filesystem. I'll have a look around and see if I can find specs on the bin format, and maybe get the yaffs2 extracted and mounted.

Grank · Nov 26, 2009

I don't know if it's helpful or relevant at all, but as far as the file system is concerned, someone posted a dump in this thread:
http://xdaforums.com/showthread.php?t=582972
I haven't looked at it much, it's just a zip of a pretty standard-looking linux directory tree so I don't know if it includes kernel binaries or not. But maybe it'll help somehow?
Also, I understand that the SETool software package can open LG .MBNs, if you have that or can get a hold of someone who does. I don't know if you can mount them directly like you're suggesting though. And I'm sure you can't go back to an LG-signed .MBN afterwards, but maybe we can convince it to accept an unsigned BIN somehow... *shrug* I don't know what I'm talking about, just trying to generate ideas

harnish · Nov 26, 2009

Where the LG .MBNs At?

Where does one find the MBNs you guys are talking about?

Zacpod · Nov 27, 2009

http://csmg.lgmobile.com:9002/swdata/WEBSW/GW620R/ARGSBK/V10c_00/V10C_00.kdz

Zacpod · Nov 27, 2009

A guy over here has a broken Eve that he's going to take apart. Hopefully that will shed some light on the hardware platform, and maybe (hopefully!) there will be a JTAG.

harnish · Nov 27, 2009

Decompressing the KDZ

Okay, it took me a while to find the right version of the LG-Utils program to decompress the KDZ file. From those of you following along at home, you want at least version 0.4.2 (the most common version is 0.4.0, which is great if you want to flash your phone with the firmware it appears).

Okay, for those looking at this thread for the first time, here are a quick set of instructions to get you caught up to ZacPod (as of the 19th anyway).

(1) Download the firmware: http://csmg.lgmobile.com:9002/swdata/WEBSW/GW620R/ARGSBK/V10c_00/V10C_00.kdz
(2) Download LG-Utils 0.4.2: http://www.assembla.com/spaces/ks36...eJe5afGb/download?filename=LG-Utils-0.4.2.zip
(3) Run KP500-Utils-EN.exe (or whatever language you prefer out of the available choices) and select I to extract the KDZ.
(4) Open the resulting CAB file and extract the DZ file.
(5) Download DZExtract: http://www.frenchcoder.com/upload/DZExtract-V0.2.zip
(5) Use DZExtract to extract the MBN files:

Code:

DZExtract -x GW620RAT-V10c-OCT-21-2009-RGS-CA_DZ+0.dz C:\extractedTo\

Voila, lots of MBN files: amss.mbn (8717kb), partition.mbn (0kb), qcsblhd_cfgdata.mbn (0kb), qcsbl.mbn (32kb), oemsblhd.mbn (0kb), oemsbl.mbn (150kb), amsshd.mbn (0kb), appsboothd.mbn (0kb), appsboot.mbn (215kb), zImage_Ramdisk.mbn (2030kb), System.mbn_0 (95089kb), System.mbn_1 (12158kb)

Now, the zImage_Ramdisk likely contains the kernel. The question is if there is anything else in there. In a hex editor, it starts with the string "ANDROID!" and later on has "mem=88M console=ttyMSM0 androidboot.console=ttyMSM0". Running strings on the mbn files might yield interesting tidbits.

System appears to be too big and was broken into two pieces ... I suspect it needs to be put together again before it will be of any use.

amss.mbn is intriguing ... it starts with the string ELF, which is common of linux executables. Not sure what the smss.mbn is. There are also page after page of "empty" sections (all null's). Are there multiple files in here? I don't think this is a filesystem ...

partition.mbn is kind of interesting too. It contains the strings MIBIB, WALLPAPER, OEMSBL2, DLOAD, AMSS, APPSBL, FOTAUSD, FOTAPKG, ZIMAGE, SYSTEM, DRM, CACHE, and USERDATA. I'm assuming it defines the partition tables.

The question really is, what are these mbn files? They don't look like filesystems, but I'm not really familiar with YAFFS2.

This thread here:
http://xdaforums.com/showthread.php?t=399249
Talks a lot about the DZ file format and there is some discussion about MBN files.

However, it doesn't appear they are in any special format so I tracked down the YAFFS specs (http://www.yaffs.net/yaffs-spec). I'm hoping they might shed some light on what these files really are. Some notes on YAFFS2 are here: http://www.yaffs.net/yaffs-2-specification-and-development-notes, but they are rather out of date.

Zacpod · Nov 27, 2009

Wow Harnish! Glad to see someone else is looking at this!
I had thought that the two system.mbn files were the main system partition and the recovery partition. But, if it's a split file then that may be why I couldn't mount it to a MTD.
Fyi, if you have access to a linux box you may want to check out this page about using an MTD simulator. I /think/ we need to attach the bins to a nandsim and then mount the MTD as a yaffs2 filesystem - I don't think you can mount the yaffs2 directly. I haven't had much luck with that so far, but I hadn't thought to combine the two system.mbn files. I'll give that a try this weekend.

Zacpod · Nov 28, 2009

Yep, you were right. The System.mbn files are one file that was split on the 32bit size boundary. I looked at the files in a hex editor, and the 2nd file continues the patern at the end of the first.
I concated them together, but... Sadly. Still couldn't get it to mount.
I tried mounting it directly via loopback. I tried burning the file to a NAND simulator MTD device and then mounting the MTD, but no joy.
I think there's something at the beginning of the MBN file (the signed cert, perhaps?) that needs to be stripped out before the filesystem will mount.
Tomorrow I'll try making a yaffs2 filesystem on an MTD and then export it to a .img file to see what the start of it looks like - hopefully that'll give us a clue as to what to look for in the MBN, and how much to strip away.

Zacpod · Nov 28, 2009

Some interesting developments...
I compared the system.mbn file with a system.img downloaded and they are very very similar. The headers start the same. E.g. the first few bytes in the hex editor for both files is "03 00 00 00 01 00 00 00 FF FF 00 00 00 00 00 00 00"
I think after all that, that the MBN is actually just a BIN or IMG. Hell, unless the signature is at the end I don't even think it's signed anymore.
Now, that being said, I was unable to start the Android emulator using the system.mbn file as the system.img. It just hung at the android_ screen.

I'm going to see if I can get a console screen from the emulator to see where it's failing.

Zacpod · Nov 29, 2009

Now things are starting to come along...

I used nandsim to simulate a 512mb NAND

Code:

sudo modprobe nandsim first_id_byte=0x20 second_id_byte=0xac third_id_byte=0x00 fourth_id_byte=0x15

I used mtdblock to make the resulting /dev/mtd0 a block device (dev/mtdblock0)

Code:

sudo modprobe mtdblock

I used nandwrite to write the system.mbn to the simulated nand

Code:

 sudo nandwrite /dev/mtd0 System.mbn -n -a -o

I then try to mount the yaffs2 filesystem

Code:

 sudo mount /dev/mtdblock0 -t yaffs2 system

and get an error. mount: wrong fs type, bad option, bad superblock on /dev/mtdblock0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

I tried a few variations of the nandwrite, and at one point the mount succeeded, but it was an empty filesystem.
We're getting closer!

Oh, I also found this which has some good info...
And this which has info on extracting filesystems from .img files on Android
And this which has info on unpacking and repacking boot images.
That last one may be the key... If we can unpack, modify, repack, and successfully burn this to a phone we will be rooted!

harnish · Nov 30, 2009

Great Work!

Great Work Zacpod!

So I've been attacking the boot image (zImage_ramdisk.mbn) ... The HowTo has a lot of information, but the addresses are definitely wrong for the image we are looking at. Either it's out of date (IE: Android 1.0) or our boot images are a little more packed. With that said, I figured I'd run the automated method on it to confirm.

Code:

./split_bootimg.pl boot.img
Page size: 2048 (0x00000800)
Kernel size: 1610880 (0x00189480)
Ramdisk size: 427851 (0x0006874b)
Second size: 0 (0x00000000)
Board name:
Command line: mem=88M console=ttyMSM0 androidboot.console=ttyMSM0▒▒F_▒▒ɖ▒▒*b
Writing boot.img-kernel ... complete.
Writing boot.img-ramdisk.gz ... complete.

This, as you can guess from the command line, didn't produce usable files. But things _did_ line up at least in the initial header so I think it should be possible to tweak a few settings and perhaps get things working.

harnish · Nov 30, 2009

Okay ... that didn't work.

There are three valid GZIP magic numbers (1F 8B) in the file. Addresses 4634, 196500 & 199A95, but they don't seem to generate valid GZIP files for the kernel/ramdisk. The first two generate an invalid compressed data--format violated error and the other generates a multi-part gzip file -- not supported error.

I am beginning to suspect that the contents of the boot.img file might not be gzipped. However, piping the result of cat on just the boot.img-ramdisk.gz file results in nothing but a screen of errors. I'm going to track down a copy of bootimg.h for Android 1.5 and confirm that things are the same.

harnish · Nov 30, 2009

So I've looked through bootimg.h, flash.h, main.c (in usbloader) and it all looks right. However, none of this branch has been modified since December 2008 so either it is fully stable (highly likely) or I'm looking at the wrong branch entirely (possible). In any case, assuming the code is right (which I have no reason to doubt it), our cutting up of the image file should be correct.

Note: Values are coded in little-endian, reverse to convert from hex to dec. IE: 00 80 00 10 is actually 10 00 80 00 = 268468224

Code:

HEADER
======
BOOT MAGIC          [0000-0007] ANDROID!
KERNEL SIZE         [0008-000B] 80 94 18 00 (1610880)
KERNEL LD ADDR      [000C-000F] 00 80 00 10 (268468224)
RAMDISK SIZE        [0010-0013] 4B 87 06 00 (427851)
RAMDISK LD ADDR     [0014-0017] 00 00 00 11 (285212672)
SECOND SIZE         [0018-001B] 00 00 00 00
SECOND LD ADDR      [001C-001F] 00 00 00 00
TAGS ADDR           [0020-0023] 00 01 00 10
PAGE SIZE           [0024-0027] 00 08 00 00 (2048)
UNUSED              [0028-001F] 00 00 00 00 00 00 00 00
NAME                [0030-0039] 00 00 00 00 00 00 00 00
CMD LINE            [0040-????] mem=88M console=ttyMSM0 androidboot.console=ttyMSM0
ID                  [????-????]

In any case ... I'm out of ideas at the moment.

kingrz · Nov 30, 2009

Hy,
I came from http://androidarena.pytalhost.net/
We are trying to port Android on Lg Arena. We have dissambled allot of files of the firmware, we have compiled an android kernel,... we need help. I see that you are very skilled!

So your help would be one big bust to our project!

TNX anyway

Zacpod · Dec 1, 2009

Wow, nice Harnish!
It's been an insane day for me at work, but I should have some more time to play with this on Wed.

harnish · Dec 1, 2009

Well the header is right, but ...

The header part of the code is the only part I can guarantee is correct.

According to the documentation, we should have a HEADER (1 page), KERNEL (n pages), and RAMDISK (m pages). Ergo the size of the file should be 1+n+m, with the end result being evenly divisible by the page size of 2048 (pulled from the header and seems to be standardized on).

The problem is this:

Code:

0 - 2047			  1 page    HEADER
2048 - 1613824 (18 A0 00)	787 pages   KERNEL
1613825 - 2041857 (1F 28 01)	209 pages   RAMDISK
2041858 - 2105663 (20 21 3D)    31 pages + 317 bytes ????

We have a lot of left over bits & bytes at the end of the file, assuming the file sizes are correct (kernel is 1610880 bytes and the ramdisk is 427851 bytes). I haven't been able to cut the file correctly based off the valid GZIP magic numbers (1F 8B 08) or the BZIP2 magic numbers (42 5A 68) [which were not found].

According to this http://wiki.kldp.org/wiki.php/AndroidPortingOnRealTarget#s-3.2, the ramdisk must be a gzipped cpio archive (which is what the other article mentioned) so I'm not sure there isn't some LG wrapping done on this mbn file ... but that doesn't explain why the header matches.

harnish · Dec 2, 2009

System.img

Alrighty, I combined System.img and like ZacPod, failed to get it work in the emulator.

Windows:

Code:

copy /b System.mbn_* System.mbn /b

Linux:

Code:

cat System.mbn_* > System.mbn

After comparing our System.img w/ the default one, I noticed that our NULL blocks before files/directories were different, I suspected slightly different owner/property options. I figured that might be the cause so I decided I'd remove it:

Code:

cat System.mbn | perl -pe 's/(\xFF{5}\x00{4}\xFF{54})[^\xFF]{10}(\xFF{16})/\1\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\2/g' | perl -pe 's/(\xFF{32})\xA8\xCF\x56\xCF\xFA\x43\x09\x9F\x79(\xFF{32})/\1\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\2/g' > system.img

However, that doesn't seemed to have changed anything, it still won't load in the emulator. I'm thinking it might have to do with the init.rc on the ramdisk.

I'm going to try mounting the modified image file under nandsim once I get yaffs compiled on my laptop.

Zacpod · Dec 2, 2009

Wow, you're way more hardcore with Perl than I am!
I managed to get the emulator going with console output, and it does look like it's down to a different init.rc + ramdisk. The default emulated kernel is trying to mount stuff that just isn't there.
You can get console output with:

Code:

(in the SDK tools dir, if it's not in the path)
emulator -avd Test -show-kernel

There's also a bunch of stuff in "emulator -help" about specifying the ramdisk/kernel/etc. Perhaps we can get the emulator going using a few of the files from the firmware extract - Instead of just System.mbn like I was trying.

Here's the tail end of kernel messages for reference.

Code:

Freeing init memory: 104K
init: cannot open '/initlogo.rle'
yaffs: dev is 32505856 name is "mtdblock0"
yaffs: passed flags ""
yaffs: Attempting MTD mount on 31.0, "mtdblock0"
yaffs: dev is 32505857 name is "mtdblock1"
yaffs: passed flags ""
yaffs: Attempting MTD mount on 31.1, "mtdblock1"
yaffs_read_super: isCheckpointed 0
yaffs: dev is 32505858 name is "mtdblock2"
yaffs: passed flags ""
yaffs: Attempting MTD mount on 31.2, "mtdblock2"
yaffs_read_super: isCheckpointed 0
init: cannot find '/system/bin/sh', disabling 'console'
init: cannot find '/system/bin/servicemanager', disabling 'servicemanager'
init: cannot find '/system/bin/vold', disabling 'vold'
init: cannot find '/system/bin/debuggerd', disabling 'debuggerd'
init: cannot find '/system/bin/rild', disabling 'ril-daemon'
init: cannot find '/system/bin/app_process', disabling 'zygote'
init: cannot find '/system/bin/mediaserver', disabling 'media'
init: cannot find '/system/bin/playmp3', disabling 'bootsound'
init: cannot find '/system/bin/dbus-daemon', disabling 'dbus'
init: cannot find '/system/bin/installd', disabling 'installd'
init: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery'
init: cannot find '/system/bin/keystore', disabling 'keystore'
init: cannot find '/system/etc/init.goldfish.sh', disabling 'goldfish-setup'
init: cannot find '/system/bin/qemud', disabling 'qemud'
init: cannot find '/system/bin/logcat', disabling 'goldfish-logcat'

Zacpod · Dec 2, 2009

I tried to extract the kernel and ramdisk manually with a hex editor and had similar results. i.e. Fail.

The kernel wouldn't boot in the emulator. That could be due to the emulated hardware being different from the Eve, but I suspect it would at least give us some notice that it was starting to work before failing.

The Ramdisk wouldn't decompress in gzip/gunzip. Gave me a "invalid compressed data--format violated" error. Not much help there. I wonder if the gzip they used to compress it was little endian, and the one we're trying to decompress with is big endian... Not sure if that matters in a compression program - shouldn't matter if it's compressing in to bytes, but would if it's compressing in to words.

Anyhoo. I'm giving up for the night. I'll sleep on it and see what we can come up with tomorrow.

Zacpod · Dec 2, 2009

Also just got confirmation from fortunemonkey at AndroidOverdrive that the Eve is running on a Qualcomm MSM7200A.
He'll have some disassembly pics for us soon.

Hopefully we'll be able to spot the jtag... It's a thin hope, but a hope nonetheless.

LG GW620 Development/Kernel hacking (Have LG source mods + trying to get 2.0 working)

Senior Member

Senior Member

Member

Senior Member

Senior Member

Member

Senior Member

Senior Member

Senior Member

Senior Member

Member

Member

Member

Senior Member

Senior Member

Member

Member

Senior Member

Senior Member

Senior Member

Similar threads

Top Liked Posts