[myTouch 3G, Magic Android Development] hause:
A little look in the rom

I have (had) a:

Vodafone 32B (GoogleLogo on back-cover), ENG-SPL, S-OFF, AOSP24

Then i did this mistake:

RUU_Sapphire_HTC_Europe_3.05.401.3_release_signed_NoDriver.exe

Now it stays in HBOOT after switching on and shows:

SAPPHIRE PVT 32A SHIP S-ON H

HBOOT-1.76.0009 (SAPP10000)

CPLD-10

RADIO-6.35.08.29

Dec 8 2009, 17:38:48

RUU USB (with usb cable connected)

or

RUU (usb cable disconnected)

I think it is not bricked because communication over usb with fastboot is still possible.

Here is what not works:

-booting

-booting recovery with fastboot (downloading image OK but no boot)

-flashing unsigned stuff FAILED (remote: 12 signature verify fail)

-flashing signed stuff below version 1.76.0009

-flashing rom1.zip from 3.05.401.3-package (hangup on unzipping system)

-applying any .zip/.nbh/.img from goldcard

-erasing partitions (exp. cache) FAILED (remote: not allow)

-entering recovery mode with VOL-DN + POWER

-any recovering method found here or on the web

What works:

-press trackball (ACTION) and POWER (display is black, left led is black, right led is blue)

-goldcard (bypasses wrong custom id failure)

Since there is still breath in I decided to take a closer look on the 3.05.401.3-package:

rom.zip and rom1.zip:

First 256 bytes are "extra bytes" (different ones in each .zip, I think the htc-signature) followed by the 'PK' identifier and the zip payload.

Inside rom.zip:

android-info.txt

boot_special.img

hboot_7200A_1.76.0009_091208.nb0

radio.img

Inside rom1.zip:

android-info.txt

boot.img

recovery.img

splash1_HTC_Magic.nb0

system.img

I disassembled hboot_7200A_1.76.0009_091208.nb0 and found out this:

You can query some variables from hboot via fastboot:

./fastboot getvar [var] where [var] is one of the following:

boot-mode

version

version-bootloader

version-baseband

version-cpld

version-microp

version-main

mainver

product

build-mode

commitno-bootloader

version-tp

hbootpreupdate

platform

mid

modelid

cid (NOT the CID you need for goldcard creation)

cidnum

battery-status

battery-voltage

partition-layout

security

Maybe there are some other variables.

More interesting is that you can run oem commands on hboot. I discovered following commands:

./fastboot oem keytest

Starts a keypad-testing-tool on the device. Output goes to fastboot. End the keypad-testing-tool by hitting the back-key.

./fastboot oem enableqxdm [param]

Maybe this enables qxdm. I cannot find any USB-Driver that works with the Magic and QPST/QXDM.

./fastboot oem powerdown

Powers the device down and leaves it in battery charging mode.

./fastboot oem rebootRUU

Performs a reboot. Maybe this sets some flags for recovery.

./fastboot oem heap

Gives info about free heap segment size and heap size.

./fastboot oem task [param]

Take a look at the wiki here Hermes_BootLoader

./fastboot oem task 28

Output:

... INFOFormat start

and after a few seconds

INFOFormat end

./fastboot oem task 29

... INFOFormat BINFS start

INFOSystem partition only can be formated while security is OFF

INFOFormat BINFS end

./fastboot oem rtask [param] (accepts more [param]'s)

./fastboot oem rtask c

Makes fastboot and the device hanging.

./fastboot oem rtask c set 0 1

Output:

... OKAY

./fastboot oem reset

Performs a reset on the device.

It seems to me that there are many commands and tools in hboot.

How to bring the bricks back to life?

Here some of my ideas:

When I took a look on the fastboot source code I recognized that not all fastboot commands that hboot accepts are directly accessible from the fastboot command line interface.

Example: "download:". Fastboot uses this command internally.

So in hboot nearby "download:" are "SetFlag:" and "ClearFlag:"

Maybe it is is possible to execute much more stuff in hboot if fastboot is modified to act like a terminal application like minicom.

I also recognized that the fastboot command line interface input size is limited to 64 chars.

Maybe it is possible with a modified fastboot application to perform a buffer-overflow in hboot and execute some kind of other boot-code.

And what is this track-ball-press-power-on-blue-led-mode?

Maybe the device reconfigures the usb port as a serial interface and enters a serial-console-mode. And maybe this serial console is accessible with a custom cable over the devices usb connector.

I hope someone of you has some ideas how to to kick this hboot from the device.

Thank you for reading.