yashsingh1/xdaforums huggingface dataset:
[G1 Android Development] ezterry:
Hi lbcoder

Fastboot on rogers locked SPL:

(Sorry not a fix.. yet)

With usb wire plugged in turn on phone holding camera:

DREAM PVT 32B SHIP S-ON d
HBOOT-1.3.0010 (DREA21000)
CPLD-4
RADIO-3.22.26.17
Jun 2 2009,21:33:16

HBOOT

<SEND> FastBoot Mode

if you hit send you enter "FASTBOOT USB"

$ ./fastboot devices
HT<myserial>	fastboot

Yes most commands fail.. the code doesn't even exist in the SPL for most of them .. but you are in what the SPL calls "fastboot"...

To open up all the commands in the SPL we just need to switch to RUU mode (the only block I see is the boot mode; and lack of existence)

$ ./fastboot oem rebootRUU
... OKAY

Now the screen says "RUU USB"

Now we can run FLASH/ERASE (well I think erase works but see no need

to attempt it)

$ ./fastboot -s HT<myserial> flash hboot ~/Desktop/android/fix_device/
hboot.img
sending 'hboot' (512 KB)... OKAY
writing 'hboot'... INFOsignature checking...
FAILED (remote: 12 signature verify fail)

On the actual phone this is multiple commands.. first DOWNLOAD to transfer the data to the phone (we see this succeeded) then flash..

which succeeded to recognize the command; however the SPL noticed the missing the 0x100 byte signature header.

I'm not positive it will flash anything other than an nbh file.. but has some logic for hboot.. other partitions (unless in the nbh) may not be possible.. That said if s-off was set we may be able to bypass the signature; thus flash any nbh bypassing the main version check (which

we could easily modify w/o the signature enforcement)

(as it is we need a sha1 collision for the data after 0x100 of the nbh)

However if the phone was actually security unlocked (and no my procedure won't make that happen) you have access to all the oem (SPL bootloader commands) and not the small unlocked subset:

$ ./fastboot oem h
... INFOcommand list
INFOkeytest
INFOheap
INFOboot
INFOreset
INFOpowerdown
INFOrebootRUU
INFOtask
INFOrtask
OKAY

This is also accessible on the serial console when in "HBOOT" mode (with echo on as a nice added touch)

Hopefully this cleared up the workings of the SPL some..

As for using JTAG to root the phone

Here is what I'd attempt: when halted at the breakpoint [as per my procedure] I'd try to load the 2005 hboot.img at

0x00000000 (load_image 0x00000000 hboot.img) then change 4 words at

0x00000c00 to 0x98000C4C:

mww 0x00000c00 0x98000C4C

mww 0x00000c04 0x98000C4C

mww 0x00000c08 0x98000C4C

mww 0x00000c0c 0x98000C4C
​

This ought to bring you into hboot 2005's fastboot mode... or crash spectacularly.. since nothing is committed to flash if it works first thing is to flash hboot and a rogers compatible recovery.. you can keep the radio unless you intend to switch to EBI0
[G1 Android Development] xaueious:
Someone please attempt the JTAG root.

So is this relevant only for 3.22.26.17 radio?
[G1 Android Development] ezterry:
Don't worry ill try soon this firmware is no fun... and has dropped me offline not less than 4 times at work today.

Its not tied to a radio, just each radio has its own offsets for the code in question.. and last I checked 3.22.26.17 is the version on the locked rogers phones
[G1 Android Development] jockyw2001:
Hi there,

Here is a suggestion I just gave to another brick owner. The idea is to either flash a radio matching a mistakenly flashed faulty SPL or a sec unlocked radio.

Steps are:

>setboot 1

>GO2AMSS

>at$qcdmg (to access qcdiaginterface)

> use qc diag 07 command to write radio.nb to memory (he can write to ram starting from address 0xC0000000)

Do some experiments to find the correct address and verify radio.nb integrity at the given address.

> send qc diag 3a to do a warm reboot (ram at 0xC0000000 is preserved).

> radata c0000000 length (length is size of radio.nb)

This will flash the radio. Be patient, I think it returns a status code T or F or something like that.

In my opinion chances are this will unbrick the device.

Deploying my FrankenKaiser tool isn't possible as it uses qc dload mode. Unfortunately dload mode support is crippled in models released after Kaiser.

Goodluck and please keep me informed.

Cheers

JockyW
[G1 Android Development] bart9984:
My python script posted some pages ago, edited properly, could work to try this in conjunction with mtty...

in my case is 0xc0000000 to find it I used psas qc diag function to retrieve info about the device

bart99
[G1 Android Development] G1Hope:
@jockyw2001

Wait, I thought radata didn't write to flash. Is this actually what it does? What is rwfactory for then?

The .nb needs to be signed, right?

I wonder if there's a security-unlocked radio image for the dream out there. =/
[G1 Android Development] jockyw2001:
radata flashes a full radio: mibib, qcsbl, oemsbl, amss

rwfactory is for flashing nand pages

btw, in FrankenKaiser I didn't use radata to flash, just used it to force the device in qc dload mode :D

each 512kB block must be SHA/RSA signed

Very likely not, but maybe I could generate an image

Found a dream g1 and now searching my cable boxes for a serial usb. Will do some experiments this weekend. Would be nice to find a sw-only unbricking method for these devices. With jtag it is trivial to unbrick, which is nice but not the challenge.
[G1 Android Development] ezterry:
Yes.. well it triggers some sort of dload mode (with logic in oemspl) on the dream when it reads from an unmapped address. Or so stepping in the debugger showed me the other day when I hit such a fault.

Yes with the jtag makeing the phone do what you want is very easy with access to modify ram.. inject code.. and if we poke a bit more update flash directly [fyi different versions of the G1 sometimes have different flash cards.. presumably the cheapest at the time.. but requires slightly different flash logic].

But the end state is hopefully to recover with just the serial wire.
[G1 Android Development] ezterry:
radata is a mess of logic.. I see 3 main code paths

1) related to radio flashes with full header

2) related to oemspl flashes (may be full radio img w/o header)

3) a mess of logic for non radio data.. not sure how it works.. and one reason I have a jtaged phone is to try and debug such things. :)

The de-brick is just a side bonus while I'm in there.

Similarly here: http://xdaforums.com/showthread.php?t=649431

I'm actually more interested in the fact the EBI1 radio/rom ran flawlessly on the T-Mobile (EBI0) hardware. Not the next step of using jtag to remove the perfected SPL .. that is just to prove the steps on the other page.

(The secret is I already did the prof of concept by loading the locked SPL in ram over the 2005 one.. but that isn't quite the steps to remove a rogers e911 patched rom)
[G1 Android Development] jockyw2001:
You only see sig fault handler triggering the dload. QC dload mode iitself is crippled unfortunately.

With jtag you only have to change 1 byte in oemsbl to unlock the secure cmds. Then use rwfactory, rwdata or pwrite to flash whatever you like (sec_flag, spl, ..) regardless what nand/nor is built.
[G1 Android Development] bart9984:
On my magic I have access only to a 12,5 Mb portion of ram to write data so there is no way to try to flash a 22 Mb radio image with radata.

Maybe its a stupid question:

But offset where to flash radio images are well-know to radata or it takes them from the image file?

In the second case maybe is possible to write a fake radio image that flash the spl instead...

Another thought:

if I have two radio images A and B, they have the same AMSS code, what about to write only mibib, qcsbl, oemsbl from A to a device with B installed?

Well theese are only thoughts from someone who have not other chances :)

Another thing, while I was trying memory offsets to write to I discovered this:

writing to c0f00000 via qmat with 070000f0c002ffffffffffffffff

then sending 44 command (retunr to amss AT interpreter)

then

at$qcpwrdn to power off the device cause a warm reboot insted

other commands work fine but at$qcpwrdn not, what kind of data is at c0f00000 then? :)

Can be used for a buffer overflow? :P

Sya,

bart99
[G1 Android Development] scholbert:
Aces united....

Sure for some it's easy, others don't have a clue what we're talking about here. Thoose would need a plug'n'play solution i guess...

Anyway, JTAG opened the door and saved some time to get on the right path :D

Indeed, a variety of different NAND flashes could be found inside Dream devices. Apart from different manufacturers, there are two different types of flash chips (don't know if there's also some difference in mainboard layout):

8Bit I/O (eg. Samsung)

16Bit I/O (e.g. Hynix)

If we would use JTAG BSDL mode to access the flashes this would need different drivers.

If we use bootcode functions as jockyw pointed out, there's no difference for the reads or writes because there's some software layer to handle low level NAND access.

Could someone explain in easy words why they are called EBI0 and EBI1?

Does this refer to the MSM EBI interface :confused:

Nice to have you aboard :)

Could you point out which byte to change?

This would mean to clone the devices setup... if i got it right.

AFAIK there's also some calibration data located in the hidden sectors (WIFI/GSM).

So if the devices components (RF-components, filters...) differ too much from each other, this could lead to bad reception or at least malfunction of WIFI/GSM.

In easy words:

Radio ROMs of a certain version are all the same, but after flashing them to the device the hidden sectors are unique.

Anyway nice thought.... and maybe it's possible though.

scholbert
[G1 Android Development] ezterry:
At least one of the options:

1.22.12.29: mww 0x00902EB4 0xea000013

2.22.19.26I: mww 0x009038F0 0xea000013

3.22.26.17: mww 0x0090379C 0xea000013

The red is actually all we change when swapping the instruction.. I write it as a word because it is less painful on the brain when dealing with the underling dis-assembly.
[G1 Android Development] bart9984:
Hi sholbert,

At least I don't care if the phone is not working because I would like to access the spl and then reflash all radio+spl+recovery...

Now i want to see if thereis somewhere a code in the radio that jumps to c0000000, seenthat writing to c0f00000 cause a warm rest I think at least at powerdown it should do something in that memory space no?

bart99
[G1 Android Development] scholbert:
Aaah sorry, you already pointed that out...

Was a bit confused which byte jockyw refered to...

@bart99:

O.K. don't mind... i thought i left a thought ;)

Thanks!

scholbert
[G1 Android Development] jockyw2001:
right, this is the patch i used in kaiser simunlocker and in frankenkaiser

now use rwfactory to flash another spl, best by using PSAS:

rwfactory 0 offset length (offset is byte offset; length multiple of 0x20000)
[G1 Android Development] bfikkert:
I'm out of this thread for some time. But after reading all posts, looks like... allmost there... or not !

How close are you all in debricking G1 with only serial connection ?

Bob
[G1 Android Development] ezterry:
I think the status is there are many ways (some not even mentioned but known by some of us to do it once we break a layer of security or two.. And there are a few people looking..

With at least scholbert and myself (perhaps some other people) with jtag set up for debugging purposes.. where the phone lets us debug anyway..

This is closer than we have been.. but who knows if we will work it out tomorrow or ages from now..
[G1 Android Development] gymmy:
just an update on the Jtag points on the Magic... Its not good news guys, while there are over 35 test points on the board there aren't any i can see which are organised even remotely into a testing interface. They have scattered them all over both sides of the board.

These are usually areas where they will be testing the function of a specific part of the board b4 they send it out for final assembly. I have taken a heap of high res 10Mp photographs of the main board and will upload them later tonight once i get back from having a coffee with some friends.

Sorry this couldn't have been better news, but the way i see it is ....

1: there is a reason, no jtag sites = no need for it

2: They connect another board to the phone though the ExtUSB port to do this

3: They subscribe to the throw away society and just replace it with another

Im hoping for 1: After all it wouldn't look good for google to be doing this ! :)

I think ill have to spend more time looking at the assembly and see if i can fool the phone into thinking all is fine and booting into the Arm11 so i can get to RUU or Fastboot.

G.

Pictures as requested, I can email the hi-res pictures to anyone who wants them, be warned they are 5meg each but you can zoom right in.
[G1 Android Development] naack:
i am not sure if this would help anyone in anyway but i am thinking it just might.

enter into blue led mode.

connect usb.

remove battery

reinsert battery

phone shows g1 screen with the blue light being lit.

it just might enter another mode
[G1 Android Development] bart9984:
hi gimmy,

same photos posted some time ago from my magic. I think to find Jtag it's necessary to desolder the chips. I'm still looking for a hard demaged board to do this... maybe you can try to found onother near you, we can also divide the costs if who have this board don't want to donate.

bart99
[G1 Android Development] G1Hope:
How many bits is the RSA key? You said you can roll your own -- is the keylength weak enough that the secret key has been factored?
[G1 Android Development] gymmy:
why would you want to unsolder a surface mounted chip ? its crazy, not only will you screw the phone but unless you have access to specific machinery you will just screw the chip too. What would you want access to under it ? Am i missing something ?

G
[G1 Android Development] ezterry:
The jtag adapter needs to attach to specific pins on the processor. Since the phone's circuit board doesn't put it into a standard arm jtag port (not surprising as it take up half the mother board) .. and further don't label them (you are not intended to use it)

you will need to find where those pins go to attach a jtag adapter. (hopefully somewhere partly accessible.)

If you have a damaged magic (say shorted out water damage will not even boot to blue light mode) its a good phone to dismantle and check the jtag+mode pins and where they go.. and if any resisters are on the mode pins forcing it to an unexpected mode.

This is how the dream points where found if I read the beginning of the thread correctly.. there are some other ways of doing it.. but its not easy on such a small device.
[G1 Android Development] igord:
It isnt that hard, you just need hot air gun/ IR soldering station, to remove chip. You cant trace pinouts if you dont un-solder cpu.

I have 2x HTC Magic 32a with this problem, http://xdaforums.com/showthread.php?t=557091except that mode which is shown when I turn on the phone it can also enter blue led mode.
[G1 Android Development] marxmarv:
Excellent! Since you have spare hardware to experiment, we look forward to hearing your report and annotated board photos.
[G1 Android Development] igord:
One magic is mine, other one is not. And dont have water damage so no way I will desolder perfectly working cpu.
[G1 Android Development] igord:
Few debricked G1 via ORT Link

Edit:

Omnia Repair Tools
[G1 Android Development] farhan_iffy:
help!

hi all!

me from pakistan is there anyone who help me to de-brciking my g1 because in our country no one is using jtag so . . . . .

if anyone can do it for me then tell me (pm).
[G1 Android Development] ezterry:
Hrm:

So their JTAG software is not just expensive but very slow.. good to know..

For the cost of that JTAG adapter I got a nice new soldering station + the arm-usb-ocd + some other materials ... with money to spare for a meal at a Toronto restaurant.

The clip to allow access w/o soldering is an interesting idea for a repair shop however.. I don't think its good for generic debugging (don't see how the LCD can be attached with it, that barely works with the wires tucked carefully under it).. but for simple recovery it is simpler than soldering/unsoldering.

The 8MB is SPL+MFG+Splash+recovery+some or all of boot; so if you switched your radio from EBI1 (3x) to EBI0 (2X) or EBI0 to EBI1 it probably fails to boot.. but may still let you into the SPL to flash via Fastboot

I do understand the use of the product for a phone repair shop. As a boxed solution to repair many phones.. Add in the clips intended for a nearly average person to operate. And only for the cost of the phone..

It is also noted that for someone who day job is fixing phones they are able to make flash code faster than us.
[G1 Android Development] igord:
I agree that is expensive. I already have soldering station :p

I posted link because of ORT software, maybe someone can try it with diy jtag adapter.
[G1 Android Development] scholbert:
ORT software needs special ORT hardware box (connected to USB) to work.

To make the software work with DIY adaptor, you'll need firmware from ORT box and you'll have to know the pinout of the controller they use indside the box (schematic).

Apart from this illegal task, i don't like the idea to reverse engineer a debug adaptor to run a certain software.

Regards,

scholbert
[G1 Android Development] ezterry:
Well been meaning to get one for a while... and I wasn't going to poke the .phone with the cheap iron given the option.
[G1 Android Development] adisa:
Hello Everyone! i have been following this thread all the way and i am happy a solution has finaly been found. Can someone compile ezerry's G1 unbricking method into a software with User interface so that those who are not comfortable with command line can also benefit from this success.

Also for those who do not solder or know how to solder, could it be possible to unbrick via usb connection and not serial.
[G1 Android Development] ezterry:
At current the only method is via JTAG.. this its self might be do-able without solder using Omnia's clip [link is many pages back...] (and if using my solution a cheaper non-Omnia jtag adapter) .. I think they are using a standard 20 pin port setup but that needs to be verified.

The current setup requires a command to be run from the phone (thus why we use the serial wire) .. I;m sure that could be injected code by jtag just needs a bit more work via a openocd config script.

Once that is done I'm not sure its worth the effort for a full graphical interface.. but a bat script or python script that only needs to be double clicked to run on windows is possible.

If you are stuck at the splash screen there is no way we can use only the USB wire.. as the usb drivers are not loaded.. or not running.. And if you can get into the SPL.. you ought to be able to flash something to get the device under control again. (well unless you are attempting to escape a walled garden rom)
[G1 Android Development] LeonardoFloripa:
15€ clip for G1

I've found this..

And, related, this...

Whatchaya think ?
[G1 Android Development] adisa:
I think the batch file will do just fine with instructions and pictures of the usb/serial cable to use and how to connect it to the phone etc. maybe all this and more can be put into a wiki.
[G1 Android Development] jockyw2001:
good catch :0
[G1 Android Development] igord:
You still need ORT.
[G1 Android Development] lbcoder:
Actually, no. That is just a set of spring-loaded pins to make wiring up easier. It would be perfectly compatible with what is going on in this thread.
[G1 Android Development] igord:
I know that, ort or any other 20pin cable compatible jtag.
[G1 Android Development] ezterry:
which ARM-USB-OCD (what I used in my hack) and ARM-USB-TINY (similar also runs on openocd)

Thus if the requirement is to unbrick/remove rogers rom w/o solder seems one of the tools;

For the other requirement; I believe it was to turn the following:

1) openocd terminal output

2) openocd telnet session

3) serial terminal to device

and if I am doing more testing than that

4) gdb connected to openocd

Into something more manageable for those who just want to softboot and SPL and run fastboot as usual. and optionally other common tasks.

Which I'm leaning to python controlling the openocd;
[G1 Android Development] lbcoder:
No, not any "20pin cable compatible".... ANY AT ALL.

It doesn't matter how many wires are on the thing.

Just follow the traces to see what connects to where.

If you can't manage to connect it, then you really shouldn't be messing with this kind of thing anyways. It is therefore universally compatible.
[G1 Android Development] LeonardoFloripa:
Well...

... the darn thing costs more to ship to here than to buy.

Is there anybody with skill/time/good will to do a how to construct something similar ?

Thank you.
[G1 Android Development] excogitation:
If someone has a beyond repair damaged 32A 32B board ... send it to me and I'll trace the jtag pins. (I have done it before for a Magician.)
[G1 Android Development] marxmarv:
If how to make one isn't obvious, then a) you probably don't already have the necessary tools and supplies to make it happen, and therefore b) it'll almost certainly be cheaper to order.

For ultimate low-cost JTAG, you could just solder wires onto the test points labeled in photos earlier in this thread like ezterry did.
[G1 Android Development] ulissescg:
x-ray

Hi guys, i have a bricked phone since long time ago, and i have being following this thread since there.

I just was watching what’s happened here and because I did not have time for it right now .... Anyway from now when I have time I will start helping as much as I can…

This time I’m just attaching some images I have taken from an X-Ray Machine to the Main Board of the HTC Dream Phone, then I was trying to figured out what was inside and see if I can route and see if there is something hide like a fuse that they intentionally burn to do not have access to the jtag or just curiosity, then the first impression that I get is that, in their SMT process there is a poor soldering quality, you can see the air bubbles under the ICs… anyway, with this X-RAY machine we can easily route the traces and see where are they connected (Easy way to find jtag pinst, but expensive), but sometimes we need to de-solder some parts, but also will be hard because I assume PCB is at least 4 layers… i have search for the QUALCOMM IC but i have not succeed in to find it out, did someone knows where to get it??

I have some tools for jtag

>> MAXIM MAXQJTAG-USB

>> SEGGER J-Link ARM Emulator for ARM and Cortex-M3 cores

I will see what I can do with those…

thats all for now.....

Regards

Ulisses
[G1 Android Development] lbcoder:
Great, so you fried your board with xrays before reading this thread to find out that we don't even care since we ALREADY HAVE enough physical information?

Note: Dreams have been successfully debricked. Read a few pages back for the procedure.
[G1 Android Development] scholbert:
What.....

Oh lord... we fight with x-rays already, that's what i call insights :p

Welcome ulissescg!!!

True... better read before x-ray your board.

That's crazy stuff, but sure this could help us to trace some signals.

Cheers,

scholbert
[G1 Android Development] marxmarv:
The fuse you're looking for is on the order of a micron in size and might merely be an electrical charge on a gate somewhere. X-ray may not be the right tool with which to visualize it, but it might be the tool with which to erase it... and the rest of your phone.

Qualcomm doesn't appear to deal on the open market. You sign a bunch of contracts and checks and they give you a bunch of (half-arsed) data and parts. If you search well and follow links, you can find a few leaked bits and pieces of interest.