Related
Hi devs,
Are you aware of any work (for other Android phones, for instance), where an altered mtd kernel driver was used to allow (raw) root access anyplace within flash memory? (For example, maybe a raw pseudo-partition which overlaps all the other partitions?) The stock mtd driver creates devices in the kernel device tree only for specific partition slices (boot, system, recovery, data, cache) - for obvious safety and security reasons.
After all these months, I stumbled across this tonight
Code:
C:\foo>fastboot oem listpartition
...
INFO[radio]:(OTHER) block start=0, size=332 (42496 KB)
INFO[hboot]:(RAW) block start=333, size=6 (768 KB)
INFO[misc3]:(RAW) block start=339, size=2 (256 KB)
INFO[mfg]:(RAW) block start=341, size=2 (256 KB)
INFO[sp1]:(RAW) block start=343, size=6 (768 KB)
INFO[misc2]:(RAW) block start=349, size=3 (384 KB)
INFO[mfg2]:(RAW) block start=352, size=3 (384 KB)
INFO[recovery]:(RAW) block start=355, size=40 (5120 KB)
INFO[boot]:(RAW) block start=395, size=20 (2560 KB)
INFO[system]:(YAFFS) block start=415, size=1360 (179520 KB)
INFO[cache]:(YAFFS) block start=1775, size=1040 (137280 KB)
INFO[userdata]:(YAFFS) block start=2815, size=1276 (168432 KB)
INFO[misc]:(RAW) block start=4091, size=5 (640 KB)
INFO[microp]:(OTHER) block start=0, size=0 (0 KB)
INFO[nv]:(OTHER) block start=0, size=0 (0 KB)
INFO[tp-melfas]:(OTHER) block start=0, size=0 (0 KB)
OKAY [ 0.071s]
finished. total time: 0.071s
I had never seen references in the Eris forums to the misc3, mfg, sp1, misc2, or mfg2 partitions - I suppose one or more are for boot images. Maybe interesting to boot a kernel image that had access to them, and have a peek at them?
bftb0
You are venturing into an area that is slightly beyond my current level of understanding. (Although we can all learn more.)
Is this even close to what you are looking for?
http://forum.xda-developers.com/showthread.php?t=754805
I'm thinking not, since they appear to be resizing the existing partitions, which doesn't seem to be quite what you are looking for.
I was asking about this a while back to see if anyone was able to get read access to the splash1 (i'm guessing sp1) partition so we could dump the REAL original splash screen for people that needed to go back to full stock. This was basically the only thing that is left out of going to stock since the "original" boot image that I had used for the android skateboards in my post about changing the boot logo was just a resized version I found online somewhere which is slightly bigger than the original if you look closely. I had some info laying around somewhere but it was definitely something about people modifying the mtd drivers in the kernel to get this done.
Without the modified drivers there is no way to do a FULL nand dump at this point.
gnarlyc said:
You are venturing into an area that is slightly beyond my current level of understanding. (Although we can all learn more.)
Is this even close to what you are looking for?
http://forum.xda-developers.com/showthread.php?t=754805
I'm thinking not, since they appear to be resizing the existing partitions, which doesn't seem to be quite what you are looking for.
Click to expand...
Click to collapse
Well, I'd seen that before - but THANK YOU - your post encouraged me to do a better job of searching, and I came up with this:
http://forum.xda-developers.com/showthread.php?t=542688
[SIZE=+2]Awesome![/SIZE] It appears that no mtd kernel hack is needed - as long the Eris kernels we are using accept those parameters (obviously, a little additional work is needed to get the offsets correct for the Eris).
I knew that partitions could be resized - but I wasn't aware that you could add new partition definitions. If it works for the Eris, then cool. (I have to say - the G1/G2/Hero devs surely have turned over a lot of stones that have helped us.)
bftb0
Mohahahhahahahaaha (rubbing hands together deviously). I smell either some interesting development or at least some interesting information coming out of this.
It's working.
More details later.
Flash Memory Map for the Eris:
Code:
PARTITION START END SIZE(1KB) SIZE(128KB) NOTES
radio 0x00000000 - 0x02980000 42,496 332 (3)
- gap! - 0x02980000 - 0x029a0000 128 1 (3)
hboot 0x029a0000 - 0x02a60000 768 6 (2)
misc3 0x02a60000 - 0x02aa0000 256 2 (5)
mfg 0x02aa0000 - 0x02ae0000 256 2 (6)
sp1 0x02ae0000 - 0x02ba0000 768 6 (4)
misc2 0x02ba0000 - 0x02c00000 384 3 (4)
mfg2 0x02c00000 - 0x02c60000 384 3 (4)
recovery 0x02c60000 - 0x03160000 5,120 40
boot 0x03160000 - 0x033e0000 2,560 20
system 0x033e0000 - 0x0dde0000 174,080 1360
cache 0x0dde0000 - 0x15fe0000 133,120 1040
userdata 0x15fe0000 - 0x1ff60000 163,328 1276
misc 0x1ff60000 - 0x20000000 640 5
( You can verify the above on your own phone with a combination of examining /proc/mtd, "dmesg" output immediately after the boot, and output of "fastboot oem listpartition" )
(1) Note all partitions are aligned to a 128-KB boundary (0x20000 - 18 bits)
Presumably this is why "fastboot oem listpartition" reports sizes in this unit
(2) Hboot images from HTC for the Eris have always been exactly 512 KB. Slack space is here,
but I found nothing but 0xFF's in the slack area.
(3) Attempting to dump the from this partition produces many, many error messages of the form:
mtd: MEMGETBADBLOCK returned -1 at 0x02940000 (errno=5)
mtd: MEMGETBADBLOCK returned -1 at 0x02960000 (errno=5)
(4) On my phone, dumps of partitions "sp1", "mfg2" and "misc2" produced un-interesting data blobs: all 0xFF's
Note that I have never flashed a custom boot splashscreen.
(5) Nearly "empty" - bytes not 0x00 or 0xFF are all string data (including CID)
(6) Contains "interesting" string data (including handset ID, manufacturing date, etc) and other binary data. Performing interesting handset operations and then recapturing a partition dump (before/after) and performing a binary diff could reveal strategic locations.
[SIZE=+1]HOW-TO[/SIZE]
Most people have absolutely no business doing this - you have been warned.
Under no circumstances should you hand-type any of these addresses; a simple typo could lead to disaster.
Code:
fastboot -c " mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata) " boot recovery-RA-Eris-v1.6.2.img
will produce the standard kernel partition mappings. Note the leading and trailing spaces in the quoted string - and that the order of appearance is critically important
You may append one or more** of the following, separated with commas as shown in the above (standard mapping) command.
[email protected](radio)
[email protected](hboot)
[email protected](misc3)
[email protected](mfg)
[email protected](sp1)
[email protected](misc2)
[email protected](mfg2)
** I performed individual boots adding only one non-standard partition, and can not guarantee that a disaster will not result if you try to append more than one - or all of them - in one boot.
You can verify the additional partitions have been kanged into the kernel's device tree with
adb shell cat /proc/mtd
and may dump individual partitions via the command "dump_image" (provided by Amon_RA in /sbin), as in the following example:
mount /sdcard
dump_image mfg /sdcard/part.mfg.img
bftb0
If you just want to dump a specific Eris flash memory partition(s) off your phone, there is an even easier method. (Doh!)
Prerequisites:
- 1.49.2000 S-OFF bootloader is installed on your Eris.
- working device drivers on PC and fastboot utility
Steps:
1) Connect via USB to your PC and put phone in FASTBOOT mode (Power up with Send+End)
2) Get the partition names listing using
Code:
fastboot oem listpartition
3) Using the following fastboot syntax, plug in the desired partition name (PNAME):
Code:
fastboot oem saveprt2sd PNAME -n PNAME.bin -a
for example, the "sp1" partition:
Code:
$ fastboot oem saveprt2sd sp1 -n sp1.bin -a
... INFOSaveImageToSD partition file name:sp1
INFOSaveImageToSD output file name:sp1.bin
INFOCmd5 CMD_TIMEOUT
INFOsdcc_poll_status(): i=21
INFOCmd5 polling status timed out
INFOSD: CMD5 fail, rc=2 ..
INFOSD 2.0
INFOHC card
INFO Searching free data sectors....
INFO [SAVE2SD] 131072 bytes saved.
INFO [SAVE2SD] 262144 bytes saved.
INFO [SAVE2SD] 393216 bytes saved.
INFO [SAVE2SD] 524288 bytes saved.
INFO [SAVE2SD] 655360 bytes saved.
INFO [SAVE2SD] 786432 bytes saved.
INFO [SAVE2SD] Done.
OKAY [ 1.728s]
finished. total time: 1.728s
Yep, it really is that simple.
bftb0
Hello,
After a failed attempt to install VEGAn-TAB GingerEdition on my Malata Zpad, I followed an advice on a thread to reflash the tablet with nvflash.
I made a big mistake at that time and flashed a Gtablet configuration.
This stuck me in APX mode, without anything on screen (for the first flash operation, I get one line telling I was in this mode, but after that I never saw this line again).
I can put the tablet is in APX mode (lsusb gives: Bus 001 Device 110: ID 0955:7820 NVidia Corp.). I can read slowly some elements using nvflash and --rawdeviceread (552 sectors at a time only) from my Linux computer. If I try to read too many byte, I get "data receive failure NvError 0x120000". I also have to switch the tablet on and off one or two times between each read attempt. Patiently reading sectors and assembling them on the computer with commands like cat, dd, od -x and the like, I get the impression that most of the gtablet configuration has been written (including PT but not BCT, or it was overwritten later), but there were some errors (binary files differ after some hundreds of thousands bytes).
However, most of the commands I send with nvflash fail as never completing or sending only the bootloader and not the other files, or sending the bct and stopping ... I also tried to use --rawdevicewrite but was able to overwrite neither BCT nor PT partitions. In fact, after the rawdevicewrite attempt, now rawdeviceread returns lots of alternating series of ffffffff and 000000. It also seem that if I read at the sectors corresponding to partitions BCT and PT, I get the same patterns, but if I do a --getBCP I get "normal" bytes (first line of od -x shows: 0000000 b380 6840 476e 15b9 23f1 5b07 18d2 8a58 ...). I think the fffff and 0000 are really there and correspond to write errors, but cannot be sure.
I also tried using directly --download to put the BCT partition but got another error: "failed executing command 14 NvError 0x120002 / command failure: partition download failed (bad command)". If I try the same command on partition 4 (EBT, with the bootloader) the bytes are sent but the error becomes "failed executing command 25 NvError 0x120000 / command failure: sync failed".
I don't understand what happens and how I can flash a working configuration again.
I have made some very small progress.
I now can see the following line on the tablet when nvflash has sent the appropriate bootloader (the one I used before was corrupted):
Code:
Entering NvFlash recovery mode / Nv3p server
This bootloader however does not support the --getbct command, it replies:
Code:
Failed sending command 2 NvError 1179650command failure: getbct failed (bad data)
bootloader status: operation not implemented (code: 3) message: nverror:0x1 (0x1) flags: 0
So I have to switch to another bootloader (fastboot.bin, retrieved from an ac100 forum) to get the BCT.
I can use --download without errors, so I tried to download recovery.img from cwm 0.8 into partition 9 as a recovery boot, hoping to repartition my tablet from CWM. No error on download, but nothing happens if I try to reboot in recovery mode (I guess this boot image is used when powering up the tablet while Vol+ is pressed. Rereading the first 94MB of the flash memory, I searched for the header bytes of recovery.img but did not found them (the longest match I found were only 8 bytes long), so I think --download did not download anything.
So I am still stuck with an unusable tablet.
Could someone give me some advice ?
Another strange thing I get is when I try to reset the BCT after having sent the bootloder to the tablet in a previous command. I use:
Code:
sudo ../nvflash --bct Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct --setbct --configfile android_fastboot_full.cfg --odmdata 0xbb0c0011 --create --go
Then I get messages about creating BCT, PT and EBT partitions, followed by a message about BCT being full and unable to add a new boot loader. I'm not sure anything has really been written on the tablet.
Does anyone know how to empty the BCT before attempting to relaunch the previous flash operation ?
It seems I am the only one in this thread and nobody wants to help me.
Current status is that I am still stuck. I can write at some places using nvflash --rawdevicewrite, but not everywhere. Even in the middle of the memory, I had write operations where the first 64kbytes of the write were replaced by ffff, then the following 64k bytes were written properly, and the rest was again replaced by ffff. Trying to write blocks smaller than 64k did not help, it is as if the target sector was corrupted (depite at the beginning it did not contain ffff, but a part of the initial flash).
Then I tried reformating the partitions. Some succeeded, some didn't.
Then I read in nvflash internal help (using nvflash --cmdhelp --format_all) the --format_all would reformat also the BCT an PT partitions, using the provided configfile. It was exactly what I needed! I tried it:
Code:
sudo ../nvflash --configfile android_fastboot_full.cfg --format_all --bl bootloader.bin --go
and it failed with the error messages
Code:
waiting for bootloader to initialize
bootloader downloaded successfully
Formatting all partitions please wait.. bootloader status: partition table is required for this command (code: 8) message: nverror:0x4 (0x4) flags: 0
FAILED!
formatting failed
format-all failed
NvError 0x0
It looks as if the --format_all which should create the partition table needs the partition table, and cannot only use the provided configuration file. This seems rather strange to me, so I may miss something obvious.
Please, help me.
unbricked!
I finally got the device unbricked.
Since I always got messages about full BCT, I finally decided to try to reset it with nvflash --rawdeviewrite. The BCT is at the very beginning of the memory (from block 0 included to block 1536 excluded). It starts with 16 bytes of magic numbers: b380 6840 476e 15b9 23f1 5b07 18d2 8a58, followed by 16 bytes set to 0, followed by the 4080 bytes you find in the various bct files lying around these threads. This pattern seems to be repeated several times, each 64k, so I thought it could hold several configuration (1536 blocks of 2048 bytes each can hold a bunch of such 64k sections).
So I forged a first 64k block from the magick numbers, the zeros, my Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct file and filled the rest with ffff. I wrote this to the tablet and ... it did only write a long series of ffff. So I have finally completely overwritten my BCT with garbage
After that, almost all nvflash operations failed, even simply downloading the bootloader. Error messages were either bad data, or missing partition table, or BCT related.
I tried several bootloaders, fastboot.bin from an ac100 thread the bootloader from the dropbox link in Roebeet's thread here: http://forum.xda-developers.com/showpost.php?p=9603803&postcount=1, and the one from the Malata image in nvflash_t2_mp_wifi_1202.rar. This last one succeeded. Since I had already used this commands a very large number of times and it always failed before, I think this time it succeeded because I had erased the BCT with my bunch of ffff.
Here are the final command I set and its output:
Code:
sudo ../nvflash --bl bootloader.bin --bct Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct --setbct --configfile an
droid_fastboot_full.cfg --odmdata 0xbb0c0011 --create --go
Nvflash started
rcm version 0X20001
System Information:
chip name: t20
chip id: 0x20 major: 1 minor: 3
chip sku: 0x8
chip uid: 0x17144040432025d7
macrovision: disabled
hdcp: enabled
sbk burned: false
dk burned: false
boot device: nand
operating mode: 3
device config strap: 0
device config fuse: 0
sdram config strap: 0
sending file: Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct
- 4080/4080 bytes sent
Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct sent successfully
odm data: 0xbb0c0011
downloading bootloader -- load address: 0x108000 entry point: 0x108000
sending file: bootloader.bin
| 928956/928956 bytes sent
bootloader.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
setting device: 1 0
creating partition: BCT
creating partition: PT
creating partition: EBT
creating partition: NVC
creating partition: MBT
creating partition: BLO
creating partition: MSC
creating partition: KLO
creating partition: OGO
creating partition: SOS
creating partition: LNX
creating partition: APP
creating partition: CAC
Formatting partition 2 BCT please wait.. done!
Formatting partition 3 PT please wait.. done!
Formatting partition 4 EBT please wait.. done!
Formatting partition 5 NVC please wait.. done!
Formatting partition 6 MBT please wait.. done!
Formatting partition 7 BLO please wait.. done!
Formatting partition 8 MSC please wait.. done!
Formatting partition 9 KLO please wait.. done!
Formatting partition 10 OGO please wait.. done!
Formatting partition 11 SOS please wait.. done!
Formatting partition 12 LNX please wait.. done!
Formatting partition 13 APP please wait.. done!
Formatting partition 14 CAC please wait.. done!
done!
sending file: bootloader.bin
| 928956/928956 bytes sent
bootloader.bin sent successfully
sending file: bootloader.bin
| 928956/928956 bytes sent
bootloader.bin sent successfully
sending file: mbtdata.img
- 1024/1024 bytes sent
mbtdata.img sent successfully
sending file: boot.bmp
- 1843254/1843254 bytes sent
boot.bmp sent successfully
sending file: boot.bmp
- 1843254/1843254 bytes sent
boot.bmp sent successfully
sending file: logodata.img
| 418176/418176 bytes sent
logodata.img sent successfully
sending file: recovery.img
/ 3362816/3362816 bytes sent
recovery.img sent successfully
sending file: boot.img
| 2758656/2758656 bytes sent
boot.img sent successfully
sending file: system.img
- 152334336/152334336 bytes sent
system.img sent successfully
After that, the tablet rebooted automatically, with the Malata logo.
Last few problems were that it was in chinese and with the touch screen not responding. The touch screen problem was due to not understanding the slider at the bottom of the initialization screen was an unlocking slider and should be moved to activate the touch screen. Then I had to search a little to reset the tablet in english.
The last few days have been tiresome, and I would have appreciated getting some help here ...
There were probably a few who were following this thread (myself included), but couldn't help, because we have very little info on the BCT.
Plus you have a ztab, rather than a gtablet.
Congratulations on you success and persistence, and thanks for posting this info.
I do have one question: how'd you figure out what to use for the odmdata? That's another piece of the puzzle w little info....
Jim
Misty soul said:
I finally got the device unbricked.
Since I always got messages about full BCT, I finally decided to try to reset it with nvflash --rawdeviewrite. The BCT is at the very beginning of the memory (from block 0 included to block 1536 excluded). It starts with 16 bytes of magic numbers: b380 6840 476e 15b9 23f1 5b07 18d2 8a58, followed by 16 bytes set to 0, followed by the 4080 bytes you find in the various bct files lying around these threads. This pattern seems to be repeated several times, each 64k, so I thought it could hold several configuration (1536 blocks of 2048 bytes each can hold a bunch of such 64k sections).
So I forged a first 64k block from the magick numbers, the zeros, my Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct file and filled the rest with ffff. I wrote this to the tablet and ... it did only write a long series of ffff. So I have finally completely overwritten my BCT with garbage
After that, almost all nvflash operations failed, even simply downloading the bootloader. Error messages were either bad data, or missing partition table, or BCT related.
I tried several bootloaders, fastboot.bin from an ac100 thread the bootloader from the dropbox link in Roebeet's thread here: http://forum.xda-developers.com/showpost.php?p=9603803&postcount=1, and the one from the Malata image in nvflash_t2_mp_wifi_1202.rar. This last one succeeded. Since I had already used this commands a very large number of times and it always failed before, I think this time it succeeded because I had erased the BCT with my bunch of ffff.
Here are the final command I set and its output:
Code:
sudo ../nvflash --bl bootloader.bin --bct Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct --setbct --configfile an
droid_fastboot_full.cfg --odmdata 0xbb0c0011 --create --go
Nvflash started
rcm version 0X20001
System Information:
chip name: t20
chip id: 0x20 major: 1 minor: 3
chip sku: 0x8
chip uid: 0x17144040432025d7
macrovision: disabled
hdcp: enabled
sbk burned: false
dk burned: false
boot device: nand
operating mode: 3
device config strap: 0
device config fuse: 0
sdram config strap: 0
sending file: Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct
- 4080/4080 bytes sent
Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct sent successfully
odm data: 0xbb0c0011
downloading bootloader -- load address: 0x108000 entry point: 0x108000
sending file: bootloader.bin
| 928956/928956 bytes sent
bootloader.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
setting device: 1 0
creating partition: BCT
creating partition: PT
creating partition: EBT
creating partition: NVC
creating partition: MBT
creating partition: BLO
creating partition: MSC
creating partition: KLO
creating partition: OGO
creating partition: SOS
creating partition: LNX
creating partition: APP
creating partition: CAC
Formatting partition 2 BCT please wait.. done!
Formatting partition 3 PT please wait.. done!
Formatting partition 4 EBT please wait.. done!
Formatting partition 5 NVC please wait.. done!
Formatting partition 6 MBT please wait.. done!
Formatting partition 7 BLO please wait.. done!
Formatting partition 8 MSC please wait.. done!
Formatting partition 9 KLO please wait.. done!
Formatting partition 10 OGO please wait.. done!
Formatting partition 11 SOS please wait.. done!
Formatting partition 12 LNX please wait.. done!
Formatting partition 13 APP please wait.. done!
Formatting partition 14 CAC please wait.. done!
done!
sending file: bootloader.bin
| 928956/928956 bytes sent
bootloader.bin sent successfully
sending file: bootloader.bin
| 928956/928956 bytes sent
bootloader.bin sent successfully
sending file: mbtdata.img
- 1024/1024 bytes sent
mbtdata.img sent successfully
sending file: boot.bmp
- 1843254/1843254 bytes sent
boot.bmp sent successfully
sending file: boot.bmp
- 1843254/1843254 bytes sent
boot.bmp sent successfully
sending file: logodata.img
| 418176/418176 bytes sent
logodata.img sent successfully
sending file: recovery.img
/ 3362816/3362816 bytes sent
recovery.img sent successfully
sending file: boot.img
| 2758656/2758656 bytes sent
boot.img sent successfully
sending file: system.img
- 152334336/152334336 bytes sent
system.img sent successfully
After that, the tablet rebooted automatically, with the Malata logo.
Last few problems were that it was in chinese and with the touch screen not responding. The touch screen problem was due to not understanding the slider at the bottom of the initialization screen was an unlocking slider and should be moved to activate the touch screen. Then I had to search a little to reset the tablet in english.
The last few days have been tiresome, and I would have appreciated getting some help here ...
Click to expand...
Click to collapse
Hi, how did you manage to restore "nvflash_t2_mp_wifi_1202.rar"...I restored my malata smb-a1011 with the nvflash tutorial posted here: http://forum.xda-developers.com/showthread.php?t=861950 but I'm having major problems and I can't use my hardware keys (i.e. Home, Back, Menu)
any help would be appreciated. Thank you!
jimcpl said:
I do have one question: how'd you figure out what to use for the odmdata?
Click to expand...
Click to collapse
I found a link to a Malata image named nvflash_t2_mp_wifi_1202.rar. the file itself can be found using a web search engine, it seems to be available at several places. In this file, the download.bat script reads:
Code:
"nvflash.exe" --bct Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct --setbct --bl bootloader.bin --configfile android_fastboot_full.cfg --odmdata 0xbb0c0011 --create --go
I also read in this post about using 0xba0c0011 and somewhere else about 0xbc0c0011. However if now I search for this I find a reference to an Adam, not a Zpad.
jimcpl said:
I do have one question: how'd you figure out what to use for the odmdata? That's another piece of the puzzle w little info....
Jim
Click to expand...
Click to collapse
Hi Jim,
Following an idea from one of your posts on another thread, I looked at the binary structure of the BCT as it is retrieved using nvflash --read 2 02-BCT.img.
The partition is composed of 24 exact copies of the same 128 kibibytes block. In this block, bytes 4068, 4069, 4070 and 4071 (counting from 0) are 0x11, 0x00, 0x0c, 0xbb, which appear to be the omddata I set, in reversed order.
So it may be easy to recover the good omddata from any working tablet by dumping its BCT partition and looking at these bytes. It would probably be good to gather this information for all tablets in some reference thread.
OK so I was following the instructions to put an alternative mod on my HTC Desire Z, when I relised I had put the HBoot for the Tmobile G2 rather than the Desire Z
by following the guide
I have clockwork mod there so I can run adb shell and look arround.
This user was fixing the reverse situation. But when I try to run gfreee...
Code:
/data/local/tmp # ./gfree -f
--secu_flag off set
--cid set. CID will be changed to: 11111111
--sim_unlock. SIMLOCK will be removed
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.28-cyanogenmod-g4f4ee2e
New .modinfo section size: 216
Attempting to power cycle eMMC... Failed.
Module returned an unknown code (No such file or directory).
He then goes on to dd the correct HBoot into a partition:
Code:
dd if=/data/local/hboot-eng.img /dev/block/mmcblk0p18(enter)
I also found this post that talks about doing a simular thing.
Code:
dd if=/data/local/hboot_7230_Vision_HEP_0.85.0005_101011.nb0 of=/dev/block/mmcblk0p18
Is this the right way to recover from this. does it matter that the gfree dident work?
Any guidence would be appreciated.
Stuart
Hello everyone, new user here from Montréal, Canada!
I have a question regarding the "boot" MTD device on this cheap gigabyte/proscan tablet (model: plt1066g) - When i try to write what looks like a perfectly valid boot file to the boot partition, the device freezes on the OEM (proscan) boot logo, just after adjusting the brightness. It never gets to the green trashcan/r2d2 that flashes for a second, or the android boot animation.
If i re-flash the original image that i dumped from the MTD device, it works fine, so i know it's not a problem with the flashing process or the flashing tool i'm using.
The aforementioned original boot image consists of the following parts at the following offsets:
Code:
10 0xA LZMA compressed data, properties: 0x2E, dictionary size: 8388608 bytes, uncompressed size: 259087888 bytes
2048 0x800 uImage header, header size: 64 bytes, header CRC: 0xBA042549, created: Fri Aug 1 03:43:38 2014, image size: 3027415 bytes, Data Address: 0x80008000, Entry Point: 0x80008000, data CRC: 0x74A1309A, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: lzma, image name: "Linux-3.0.8"
3031040 0x2E4000 gzip compressed data, was "ramdisk.cpio", from NTFS filesystem (NT), last modified: Fri Aug 1 04:24:34 2014, max compression
I simply extracted the cpio archive, modified the init.rc script in this archive, then re-generated the archive and wrote it at the correct offset in my new copy of the boot image. This new boot image now contains:
Code:
10 0xA LZMA compressed data, properties: 0x2E, dictionary size: 8388608 bytes, uncompressed size: 259087888 bytes
2048 0x800 uImage header, header size: 64 bytes, header CRC: 0xBA042549, created: Fri Aug 1 03:43:38 2014, image size: 3027415 bytes, Data Address: 0x80008000, Entry Point: 0x80008000, data CRC: 0x74A1309A, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: lzma, image name: "Linux-3.0.8"
3031040 0x2E4000 gzip compressed data, was "ramdisk.cpio", from Unix, last modified: Wed Sep 16 14:55:00 2015, max compression
.... so it's not a problem with the image file, or with the cpio archive contained in the file (i checked that as well), or - at least i think - not a problem with the added lines in the init.rc file. Which leads me to suspect that the only possibiliity is that there's somehow a checksum or some other kind of hash check being done on the partition - for example in that small unused section at the beginning of the partition/image. If that's the case, is there some documentation about the process, or at least some ready-made tool that would generate the proper hash check?
Thanks very much for any assistance.
/* edit */ Oh, i forgot to mention that this device is running Android 4.1.1.
/* edit2 */ Also thought it might be a good idea to share the actual resulting image. Here it is: (sorry, message board is preventing me from attaching/linking to files :/ )
Most shipping devices have locked bootloaders that allow only booting signed kernels. Is your bootloader unlocked?
I still don't know the answer to my original question, but using a utility called 'mkbootimg' instead of manually assembling the image myself, solved the problem. There doesn't seem to be any (other) locking mechanism on the boot loader of this device.
Thanks for your reply!
Hello ... so i have an Radio.img and i know inside there are this files
(bootloader) Validating 'radio.default.xml'
(bootloader) Committing 'radio.default.xml'
(bootloader) - flashing 'NON-HLOS.bin' to 'modem'
(bootloader) - flashing 'fsg.mbn' to 'fsg'
(bootloader) - erasing 'modemst1'
(bootloader) - erasing 'modemst2'.
How can i extract NON-HLOS and fsg ? thanks in advance ...
I know this is an ancient thread, but it's still the first search result, so I figured a solution could help anyone else that stumbles upon this..
I made a quick and dirty extractor that works at least for motorola edge 2021 xt2141 radio images. These files seem to start with magic "SINGLE_N_LONELY" and end with "LONELY_N_SINGLE". Filenames are provided, followed by the length of the contents (in little endian), then the contents.
This script will try to open radio.img in the current dir if a filename is not provided. Dumped files will go right in the working dir, so be careful. File content reading isn't done in chunks here, so be mindful of memory usage. Likely not an issue, but you can code in some chunking if needed.
Code:
#!/usr/bin/env python
import io
import sys
# supply filename as argument or default to 'radio.img'
try:
filename = sys.argv[1]
except IndexError:
filename = 'radio.img'
with open(filename, 'rb') as f:
magic = f.read(0x100).strip(b'\0').decode()
print(magic)
assert magic == 'SINGLE_N_LONELY'
while True:
# filename
fn = f.read(0xF0).strip(b'\0').decode()
print(fn)
if fn == 'LONELY_N_SINGLE':
break
# size of file in little endian
f.seek(0x08, io.SEEK_CUR)
l = int.from_bytes(f.read(0x08), 'little')
print(l)
# warning: not reading in chunks...
# warning: outputs to working dir
with open(fn, 'wb') as o:
o.write(f.read(l))
# seek remainder
rem = 0x10 - (l % 0x10)
if rem < 0x10:
f.seek(rem, io.SEEK_CUR)
# seek until next filename
while not f.read(0x10).strip(b'\0'):
continue
# rewind back to start of filename
f.seek(-0x10, io.SEEK_CUR)
Note the resulting images will likely be in sparse format. You'll need simg2img to convert to raw images if you're trying to mount or otherwise manhandle the images.
If interested in dumping carrier profiles (from inside the fsg image), EfsTools has an extractMbn function. Not sure how to reassemble though. https://github.com/JohnBel/EfsTools
ziddey said:
I know this is an ancient thread, but it's still the first search result, so I figured a solution could help anyone else that stumbles upon this..
I made a quick and dirty extractor that works at least for motorola edge 2021 xt2141 radio images. These files seem to start with magic "SINGLE_N_LONELY" and end with "LONELY_N_SINGLE". Filenames are provided, followed by the length of the contents (in little endian), then the contents.
This script will try to open radio.img in the current dir if a filename is not provided. Dumped files will go right in the working dir, so be careful. File content reading isn't done in chunks here, so be mindful of memory usage. Likely not an issue, but you can code in some chunking if needed.
Code:
#!/usr/bin/env python
import io
import sys
# supply filename as argument or default to 'radio.img'
try:
filename = sys.argv[1]
except IndexError:
filename = 'radio.img'
with open(filename, 'rb') as f:
magic = f.read(0x100).strip(b'\0').decode()
print(magic)
assert magic == 'SINGLE_N_LONELY'
while True:
# filename
fn = f.read(0xF0).strip(b'\0').decode()
print(fn)
if fn == 'LONELY_N_SINGLE':
break
# size of file in little endian
f.seek(0x08, io.SEEK_CUR)
l = int.from_bytes(f.read(0x08), 'little')
print(l)
# warning: not reading in chunks...
# warning: outputs to working dir
with open(fn, 'wb') as o:
o.write(f.read(l))
# seek remainder
rem = 0x10 - (l % 0x10)
if rem < 0x10:
f.seek(rem, io.SEEK_CUR)
# seek until next filename
while not f.read(0x10).strip(b'\0'):
continue
# rewind back to start of filename
f.seek(-0x10, io.SEEK_CUR)
Note the resulting images will likely be in sparse format. You'll need simg2img to convert to raw images if you're trying to mount or otherwise manhandle the images.
If interested in dumping carrier profiles (from inside the fsg image), EfsTools has an extractMbn function. Not sure how to reassemble though. https://github.com/JohnBel/EfsTools
Click to expand...
Click to collapse
Thanks for making python script to unpack these SINGLE_N_LONELY header files(bootloader.img, radio.img, singleimage.bin, gpt.bin) from Moto Stock ROM zips.
But why reading filename only 240 bytes and skipping 8 bytes instead of reading whole 248 bytes?
This guy wrote to read 248 bytes instead https://forum.xda-developers.com/t/...t-of-the-moto-g-5g-plus.4371213/post-87807175
I also made quick and dirty unpacked using Lua 5.3 at https://forum.xda-developers.com/t/...t-of-the-moto-g-5g-plus.4371213/post-87931915
I guess one of us has to post this to github, since I can't find any Open Source tool to unpack this simple format image files.
Currently, only star tool that we can find from some of blankflash files(eg. this) and imjtool can unpack these SINGLE_N_LONELY header files as far as I know. But I guess these are not Open Source.
Thanks
HemanthJabalpuri said:
But why reading filename only 240 bytes and skipping 8 bytes instead of reading whole 248 bytes?
This guy wrote to read 248 bytes instead https://forum.xda-developers.com/t/...t-of-the-moto-g-5g-plus.4371213/post-87807175
Click to expand...
Click to collapse
Ah neat. I only used xt2141 radio images as reference for approximating the file format. It's been a while, but I think based on the actual positioning of the filenames in the images I was testing, I wasn't sure if the final 8 bytes were part of the filename or padding.
Likewise, I wasn't sure of how padding works after the file data, so I just did a dumb seek and rewind.