Related
Evening all,
I also have a brand new Orange(UK) branded TyTnII. I have dumped the ROM following the guide http://forum.xda-developers.com/showthread.php?t=334680, however the partition table looks a little different:
C:\Users\***\Desktop\ITS>pdocread -l
210.38M (0xd260000) FLASHDR
| 3.12M (0x31f000) Part00
| 3.50M (0x380000) Part01
| 69.63M (0x45a0000) Part02
| 134.13M (0x8620000) Part03
STRG handles:
handle e7489c1a134.13M (0x8620000)
handle 074970e6 69.63M (0x45a0000)
handle e74b0fda 3.50M (0x380000)
handle e74b0eee 3.12M (0x31f000)
disk e7489c1a
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk 074970e6
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk e74b0fda
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk e74b0eee
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
which meant that the dump commands were:
pdocread -w -d FLASHDR -b 0x800 -p Part00 0 0x31f000 Part00.raw
pdocread -w -d FLASHDR -b 0x800 -p Part01 0 0x380000 Part01.raw
pdocread -w -d FLASHDR -b 0x800 -p Part02 0 0x45a0000 Part02.raw
pdocread -w -d FLASHDR -b 0x800 -p Part03 0 0x8620000 Part03.raw
The reconstruction was then as per http://forum.xda-developers.com/showthread.php?t=337066,
using the Windows.nb from http://rapidshare.com/files/65254405/WindowsFRA1.56.406.5.rar
The ROM has been rebuilt with Dark Simpson ROM tool, 7zip'ped and is availiable :
http://rapidshare.com/files/66123403/1.81.61.2.WWE.Orange.UK.7z.html
If anyone wants the RAW files, please let me know and I will zip and up those too. Usual disclaimers about me not being responsible for your bricks apply.
Nicely done......
In your original post about this ROM, I asked if you could post the OS and Build numbers, but you never did (and still haven't!)
Go to Start | Settings | System tab | About - make a note of the line that starts "CE OS......" and post it back here please
Click to expand...
Click to collapse
This is the missing piece of the puzzle so to speak....when this information is available, then the cooks will know if the core of the O/S has been updated etc. before they waste time cooking with it.
Thanks in advance,
Mark.
Mark Crouch said:
Nicely done......
In your original post about this ROM, I asked if you could post the OS and Build numbers, but you never did (and still haven't!)
This is the missing piece of the puzzle so to speak....when this information is available, then the cooks will know if the core of the O/S has been updated etc. before they waste time cooking with it.
Thanks in advance,
Mark.
Click to expand...
Click to collapse
its an old os and build CE OS 5.2.1620 (Build 18125.0.4.2)
^^ yep, what he said!
Thanks Dutty/Rik - glad we've got that cleared up
Mark.
so now what? it is a lie? it doesnt looks like a big update from 1.56 ?
rom
the rom that has been uploaded is that the raw files or a reconstructed rom
many thanks
steven
this was my reconstruction from the raw dump
orange
so if i put one of the other roms on my orange tytn ii could i flash your reconstruction for warranty purposes
do i need any tools to flash the rom
many thanks
steven
Hi Steven,
I hope so! It's the reason I dumped and reconstructed this ROM - I have subsequently flashed the HTC shipped ROM to my Kaiser, and its running so much faster.
Although I have tested re-flashing this ROM to take me back to an Orange branding, I give no guarantees that it will return your Kaiser back to how it was when you bought it, or that it won't turn your Kaiser into the most expensive paper weight you ever bought.
As with everything on XDA-devs, its entirely at your own risk (but i'm glad I gave it a go!)
sirsyco has posted a guide http://forum.xda-developers.com/showthread.php?t=335568 on reverting back to the original ROM, while using POF's Hard-SPL http://forum.xda-developers.com/showthread.php?t=334679 and CustomRRU http://forum.xda-developers.com/showthread.php?t=334890 should provide everything you need to flash to the first HTC shipped ROM, which you will find links to in various places in this forum.
Please note that I only flashed the HTC OS, not the radio stack or the splashscreen.
I am afraid I am not going to provide a step-by-step - all of the guides linked above provide the details to do what you want to do, and I am afraid I am of the opinion that if you don't get what is being described in those tut's, you really should not be dumping and flashing ROM's yourself.
No offence intended, but im not going to lead you out of your depth - I don't want anyone to fry their beloved Kaiser on my instructions!
orange rom
hi rik
no offence taken
can i just ask you when you went from orange to htc did you hard spl then just run the htc shipped rom
how did you just instal the os and not the spl or radio stack
did you notice a difference with the htc rom
many thanks
steven
Rik
Can you tell me...when you flashed the OS only, did you get the SIMLOCK problem?
I think that was the mistake I did... I flashed the whole thing rather than the OS alone... i wasnt aware of this complication in changing other bit besides the OS...
My phone (originally Orange ROM) is still locked (24hrs now) but its usable if you put it on flight mode.. it seems to be faster..menus, keyboard opening response, applcation launch etc.. not sure how much having the phone part switched off effects the performance...
bigchemist said:
I think that was the mistake I did... I flashed the whole thing rather than the OS alone... i wasnt aware of this complication in changing other bit besides the OS...
My phone (originally Orange ROM) is still locked (24hrs now) but its usable if you put it on flight mode.. it seems to be faster..menus, keyboard opening response, applcation launch etc.. not sure how much having the phone part switched off effects the performance...
Click to expand...
Click to collapse
Could possibly be
Could you share radio or raw from this ROM?
Thanks.
Need the newest build for flash, anyone here has got this one?
STILL WAITING
How do you know these builds exist?
optiquest said:
Need the newest build for flash, anyone here has got this one?
Click to expand...
Click to collapse
Thank you for the answer
keep cool my friend
you gave him only 18 minutes to reply...
this is no chat, so it is quite possible that it will need some time before he realizes that a reply is needed.
cheers
Haha... I was only teasing a little
But I'm very curious about these new builds
ninja.rogue said:
keep cool my friend
you gave him only 18 minutes to reply...
this is no chat, so it is quite possible that it will need some time before he realizes that a reply is needed.
cheers
Click to expand...
Click to collapse
How much minutes now?
pffff....
Yep,
I'm still waithing to...
Build date is 28/03/08?
It's out there... org wm6.1 from HTC but where to grab.....
Problem with dumping
This may not be the place to post this but The how to dump thread is unfrequently visited since I have posted this yesterday and no one has posted anything after. I think whoever reads this thread can help me.
Flame suit on but here goes
Please help me... Anyone... I'm getting Access is denied the bottom line.
-- Is it working correctly or what? IDK. Please help!! Thanks in advance
C:\>pdocread -l
210.25M (0xd240000) FLASHDR
| 3.12M (0x31f000) Part00
| 3.50M (0x380000) Part01
| 79.13M (0x4f20000) Part02
| 124.50M (0x7c80000) Part03
STRG handles:
handle c7481c1a124.50M (0x7c80000)
handle 2748f0e6 79.13M (0x4f20000)
handle 274b0fda 3.50M (0x380000)
handle 074b0eee 3.12M (0x31f000)
disk c7481c1a
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk 2748f0e6
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk 274b0fda
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk 074b0eee
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C:\>pdocread -w -d FLASHDR -b 0x800 -p Part00 0 0x31f000 Part00.raw
CopyTFFSToFile(0x0, 0x31f000, Part00.raw)
ERROR: Unable to open host/destination file - Access is Denied
Laurentius26 said:
How do you know these builds exist?
Click to expand...
Click to collapse
what you think ? yes, there had 19400 build , where to find it , maybe you know that :cool
mwang said:
what you think ? yes, there had 19400 build , where to find it , maybe you know that :cool
Click to expand...
Click to collapse
I can't see that image
hi
here´s a link to 19400 kaiser rom in chs: http://rapidshare.com/files/109028458/Kaiser_DFT_V2_19400_CHS_Release.rar, but i can´t dump it to change the mui files, it´s from darkforces team.
cheers.
ark666 said:
hi
here´s a link to 19400 kaiser rom in chs: http://rapidshare.com/files/109028458/Kaiser_DFT_V2_19400_CHS_Release.rar, but i can´t dump it to change the mui files, it´s from darkforces team.
cheers.
Click to expand...
Click to collapse
Nice job my friend. Let's see if I can round up somebody who can dump this to change it up.
While i´m trying to dump it with kaiserkitchen, it gives me an error with RecMod.exe.
cheers
I just dumped the rom and it appears it is not an official ROM. I am assuming this as PCMKeyboard is in the SYS files already!!!!!
Is this a joke
Haven't really worked alot with other languages, but I'm seeing alot of errors while dumping the contents of the imgfs in the latter half of step 2a.
It's being really retarded and making modules out of all sorts of stuff, some of it being bitmaps. I'm gonna call it quits.
_Alex_ said:
Haven't really worked alot with other languages, but I'm seeing alot of errors while dumping the contents of the imgfs in the latter half of step 2a.
It's being really retarded and making modules out of all sorts of stuff, some of it being bitmaps. I'm gonna call it quits.
Click to expand...
Click to collapse
Well, thank you for trying anyways. Guess we will just have to wait for somebody to find a good source for this build.
ryncppr said:
I just dumped the rom and it appears it is not an official ROM. I am assuming this as PCMKeyboard is in the SYS files already!!!!!
Is this a joke
Click to expand...
Click to collapse
Can u share the method to dump the ROM?
Ok let me change the topic real quick where can i find the att tilt test rom 19209 dump.
correct me if i wrong.
Laurentius26 said:
How much minutes now?
pffff....
Click to expand...
Click to collapse
sorry for forgot to reply it!
Yes, 19400 released today, and the newest build i know is 1955x..
hope someday we can use it soon.
Hi
I have created the attachd word document with images on how to change page pool alongwith tools required
None of these tools are created by me and due respect and thanks to the creators of these tools.
Hope this is useful and request someone to upload to wiki site in html format
I am a newbie any modifications, suggestions let me know
Regards
rbalu72 said:
Hi
I have created the attachd word document with images on how to change page pool alongwith tools required
None of these tools are created by me and due respect and thanks to the creators of these tools.
Hope this is useful and request someone to upload to wiki site in html format
I am a newbie any modifications, suggestions let me know
Regards
Click to expand...
Click to collapse
NOPE!!!
The value must be reversed!
Example:
0x223500 - FF FF FF FF 00 00 00 00
Thanks Master Tomal for correction.
If I modify the document as below, would it convey the correct message?
In attached screen the values changed in blue rectangle should be changed as below
00 00 60 00 00 00 00 00 For 6MB Pagepool
00 00 56 00 00 00 00 00 For 5.6MB Pagepool
00 00 80 00 00 00 00 00 For 8MB Pagepool
FF FF FF FF 00 00 00 00 for 128MB devices
Attached is the revised document.
Let me know if there are any further modifications/suggestions..
Many thanks for your guidance.
why cannot download it??
PagePool changer
Thanks for the instructions!
I writed a little utility which are help to modify the NK.FAT file.
Place the PPSET.EXE with same directory with the NK.FAT file, and just run it. When the 64B0... signature found the can be selected the new settings.
Original NK.FAT saved as NK.BAK.
So guys in this post i'll show you how to remove ULDR partition from out ROMs to gain 3 MBs of space that was wasted in all of our earlier ROMs. But first, *SPECIAL* thanks to cmonex for helping me with this
Requirements:
1. A HEX editor
2. os.nb.payload (the one inside \ROM folder)
I've used the payload from our latest WM 6.1 ROM, so my base payload over here is 3.07.720.3 ROM. The removal of ULDR requires you to edit the MBR (master boot record) and MSFLSH50 regions in the payload. So be careful while editing otherwise there would problems in cooking or the deivce won't boot.
So, take HEX editor of your choice and open the payload. The MBR starts at offset 0x0 and ends at 0x1FF. You don't need to worry about whole of the MBR, just take a look at the following HEX strings:
Code:
[size="3"]
000001b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [COLOR="DarkRed"][b]00 02 [/b][/COLOR]
000001c0h: [COLOR="darkred"][b]01 00 20 7F 01 30 02 00 00 00 7E 18 00 00 [/b][/COLOR][COLOR="Red"][b]00 00 [/b][/COLOR]
000001d0h: [COLOR="red"][b]01 31 23 7F 01 65 80 18 00 00 80 1A 00 00 [/b][/COLOR][COLOR="Blue"][b]00 00 [/b][/COLOR]
000001e0h: [COLOR="blue"][b]01 66 25 7F 81 DF 00 33 00 00 00 3D 03 00[/b] [/COLOR]00 00
000001f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA[/size]
These 3 strings are actually 3 partitions, the first one is ULDR, 2nd one is XIP and 3rd one IMGFS. Now take a look at the following:
Code:
[SIZE="3"]00000200h: 4D 53 46 4C 53 48 35 30 00 00 00 00 38 00 00 00
00000210h: 00 00 00 00 00 00 00 00 00 00 00 00 [COLOR="DarkGreen"][b]66[/b][/COLOR] 00 00 00
00000220h: 80 00 00 00 00 00 01 00 00 00 00 00 01 00 00 00
00000230h: 00 00 00 00 00 00 00 00 7A 06 00 00 80 00 00 00
00000240h: 00 00 01 00 00 00 00 00 FF FF FF FF FF FF FF FF [/SIZE]
This is the MSFLSH50 region and the marked offset shows the logical block of IMGFS start. So, in order to remove the ULDR, we have to edit the MBR and MSLFSH50 regions in the marked areas.
The ULDR partition starts at 0x400 offset and ends at 0x30FFFF (XIP starts at 0x310000 in the shipped ROM for Elfins). Delete all the HEX bytes from 0x400 upto 0x30FFFF. Deletion of ULDR means start of logical blocks of XIP and IMGFS will go up. So the XIP will start at 0x400 instead of ULDR and IMGFS will start at 0x350000. Now you need to edit the MBR and MSFLSH50 regions to adjust for the new XIP and IMGFS start offsets. So using your HEX editor, change the MBR and FSFLSH50 regions as shown below:
Code:
[SIZE="3"]000001b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [COLOR="Red"][B]00 02 [/B][/COLOR]
000001c0h: [COLOR="red"][B]01 31 23 7F 01 65 02 00 00 00 7E 1A 00 00 [/B][/COLOR][B][COLOR="Blue"]00 00 [/COLOR][/B]
000001d0h: [COLOR="blue"][B]01 66 25 7F 81 DF 80 1A 00 00 00 3D 03 00 [/B][/COLOR][COLOR="DarkRed"][B]00 00 [/B][/COLOR]
000001e0h: [COLOR="darkred"][B]00 00 00 00 00 00 00 00 00 00 00 00 00 00 [/B][/COLOR]00 00
000001f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA [/size]
Code:
[SIZE="3"]
00000200h: 4D 53 46 4C 53 48 35 30 00 00 00 00 38 00 00 00
00000210h: 00 00 00 00 00 00 00 00 00 00 00 00 [B][COLOR="DarkGreen"]35[/COLOR][/B] 00 00 00
00000220h: 80 00 00 00 00 00 01 00 00 00 00 00 01 00 00 00
00000230h: 00 00 00 00 00 00 00 00 7A 06 00 00 80 00 00 00
00000240h: 00 00 01 00 00 00 00 00 FF FF FF FF FF FF FF FF [/SIZE]
Save the new os.nb.payload and copy into the \ROM folder of your kitchen replacing the original os.nb.payload. From now on use this payload as your template for cooking ROMs. Since, the XIP and IMGFS start offsets have changed, we need to make a few adjustments to the kitchen (Hybrid, Ervius' or bepe's kitchen) also. Note the following command in CreateROM.bat file inside the \Tools folder:
Code:
..\TOOLS\insert -i ..\ROM\out.bin -o OS.nb.payload -d 0x00310000 -s 0x00350000
This command inserts the new XIP (named out.bin) into the payload. Add REM before this command because insert.exe can't insert the xip at 0x400 for some reason. So there are 2 workarounds for this problem:
1. Use XIPPort.exe to insert the out.bin (created inside ROM folder) at 0x400
OR2. Use msflshtool.exe to insert the out.bin. For using this method, copy the msflshtool.exe to your \Tools folder and add the following command in your CreateROM.bat file in place of "insert.exe ..." command.
Code:
..\TOOLS\msflshtool OS.nb.payload -r ..\ROM\out.bin -p 0
After this step, you are ready to cook your new ROM with extra space of 3 MBs . Happy cooking
Hex Screenshots
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This is like a scratch note - an easy accessed "guide".
Its purpose is to help everyone understand what are the numbers - bytes - that we are editing according to AMAN's guide for ULDR Removal.
As the title says it is a "hex view" at the latest Official Elfin 3.10.710.00 ROM
to figure out how all those hex-strings are related
and
to be able to change them, knowing what is going on!
Regards!
ababrekar said:
Awesome job brother . Hoping to see this kind of documentation for Diamonds too very soon
Click to expand...
Click to collapse
i would love to, but then u need to send me your Diamond for testing purposes
htctouchp said:
i would love to, but then u need to send me your Diamond for testing purposes
Click to expand...
Click to collapse
Promise me you will also tell me about those imgfs values for the xip playing guide and i'll send it right now
ababrekar said:
Promise me you will also tell me about those imgfs values for the xip playing guide and i'll send it right now
Click to expand...
Click to collapse
yeah i promise once i get the ULDR removed from ur diamond , i'll tell u about the imgfs values also
Yes! ULDR Removal for Elf/Elfins - Work!!!
htctouchp,
Thank you very much!!!
vadyarik said:
Yes! ULDR Removal for Elf/Elfins - Work!!!
htctouchp,
Thank you very much!!!
Click to expand...
Click to collapse
welcome
Good work!!
htctouchp said:
After this step, you are ready to cook your new ROM with extra space of 3 MBs . Happy cooking
Click to expand...
Click to collapse
Whaaaou!
GOOD WORK.
htctouchp said:
After this step, you are ready to cook your new ROM with extra space of 3 MBs . Happy cooking
Click to expand...
Click to collapse
Thanks for this, that's so great! I managed to get 74.9 Mb free storage on my Elf with a cleaned ROM.
A little addon to your great tutorial: If you have the last hybrid with the pagepool patch at the end, comment it or modify the offsets to match the new ones. My first flash was stuck on mobility screen because of this (or was it bad luck ?).
letama said:
A little addon to your great tutorial: If you have the last hybrid with the pagepool patch at the end, comment it or modify the offsets to match the new ones.
Click to expand...
Click to collapse
sorry, i didn't get it
Thanx for this new finding Aman!
It's great!
I noticed that after this ULDR removal, there is only one address that we find the pp pattern(03 15 A0 ...)!
Is it normal or did I mess it up?
htctouchp said:
sorry, i didn't get it
Click to expand...
Click to collapse
The offsets for the pp have been changed, so the script I wrote for the 2.2 Rom was aiming(&hexediting) the wrong offsets, resulting in a non-bootable rom..
Regards!
kokotas said:
Thanx for this new finding Aman!
It's great!
I noticed that after this ULDR removal, there is only one address that we find the pp pattern(03 15 A0 ...)!
Is it normal or did I mess it up?
Click to expand...
Click to collapse
yes, its perfectly normal. if u check the PP offsets of the original payload of any ROM, the first HEX string is in the region of ULDR and the 2nd in the region of the XIP. So obviously u can see only one HEX string now. And as i said in PP changer thread a few days ago that only 2nd HEX string is responsible for the PP change, so even if u don't remove the ULDR, u don't have to edit the 1st HEX string.
The offsets for the pp have been changed, so the script I wrote for the 2.2 Rom was aiming(&hexediting) the wrong offsets, resulting in a non-bootable rom..
Click to expand...
Click to collapse
ok, now i get it.
htctouchp said:
yes, its perfectly normal. if u check the PP offsets of the original payload of any ROM, the first HEX string is in the region of ULDR and the 2nd in the region of the XIP. So obviously u can see only one HEX string now. And as i said in PP changer thread a few days ago that only 2nd HEX string is responsible for the PP change, so even if u don't remove the ULDR, u don't have to edit the 1st HEX string.
ok, now i get it.
Click to expand...
Click to collapse
Can you guys give the PP offset for a 2.2 ULDR ROM, as wel as a 3.xx ULDR ROM? I'll need to add more checks for the Universal PP changer
htctouchp said:
yes, its perfectly normal. if u check the PP offsets of the original payload of any ROM, the first HEX string is in the region of ULDR and the 2nd in the region of the XIP. So obviously u can see only one HEX string now. And as i said in PP changer thread a few days ago that only 2nd HEX string is responsible for the PP change, so even if u don't remove the ULDR, u don't have to edit the 1st HEX string.
Click to expand...
Click to collapse
Found it:
htctouchp said:
will have to change again, coz the 1st HEX string is going to disappear forever
Click to expand...
Click to collapse
lol
It sounds like you did some magic...hehe
Question:
When I followed your instructions and reached to the point of deleting ULDR section, imgfs start offset was 0x350400
and I had to delete some "FF" above to make that 0x350000.
Have you any idea about what went wrong?
kokotas said:
Question:
When I followed your instructions and reached to the point of deleting ULDR section, imgfs start offset was 0x350400
and I had to delete some "FF" above to make that 0x350000.
Have you any idea about what went wrong?
Click to expand...
Click to collapse
0x350400 ? impossible....u must have missed something...try again.
dsixda said:
Can you guys give the PP offset for a 2.2 ULDR ROM, as wel as a 3.xx ULDR ROM? I'll need to add more checks for the Universal PP changer
Click to expand...
Click to collapse
for the 3.XX based nk.exe ULDR removed ROM, the offset is 0x45210. didn't check the 2.XX ROM though.
htctouchp said:
for the 3.XX based nk.exe ULDR removed ROM, the offset is 0x45210. didn't check the 2.XX ROM though.
Click to expand...
Click to collapse
Ok, the Universal PP Changer has been updated and tested with your ULDR hack. All 3.xx ROMs are now supported. I haven't been able to check on 2.xx ROMs without ULDR, however.
Thanks htctouchp!!!!
dsixda said:
Ok, the Universal PP Changer has been updated and tested with your ULDR hack. All 3.xx ROMs are now supported. I haven't been able to check on 2.xx ROMs without ULDR, however.
Thanks htctouchp!!!!
Click to expand...
Click to collapse
welcome!!
i think we don't need to work with 2.2X ROMs now. all the ROMs from now onwards are going to be based on 3.3X ROMs anyway.
All i'm hoping at the moment is that i removed the Bytes correctly .
"Delete all the HEX bytes from 0x400 upto 0x30FFFF"
I took that as a Starting from the beginning of 400 to the end of 30ffff.
Not directly my favourite stuff to do but what is there to loose
Well IF It Boots It Works. (Should have noted storage before, but looks better)
On page 67 of the Service Manual, it mentions "Turn the device power off and insert Diagnostic SD card. Press and hold Capture button, then press Power button to enter Diagnostic mode."
I'm thinking that the camera + power button will make the G1 boot off the SD Card.. this may be a way to run a hacked rev 30 on a locked rev 30 phone...
I will try some stuff tonight...
-Nikropht
that does seem interesting... im going to try to flash JF's img after in finishes downloading... i'll post results... along with my attempt to flash a signed rc29 update... cross your fingers i dont brick the damned phone
The Artemis device had this so-called "Diagnostic SD" mentioned. Im asuming therefore we could dossibly create one and flash our device with whatever firmware, akin to the "Pandora Battery" for PSP.
Worth exploring, but difficult to pull of without bricking... If it is possibly to flash a signed RC30 at any point using the current SD method, then at least we know we cannot brick the phone
the SPL bootloader (engineering and original) look for NBH files on the SD card.
DREADIAG.nbh
and
DREAIMG.nbh
As you can see, their purpose is clear. One is for booting diagnostics and the other is for flashing the firmware.
^^^so are you saying flashing DREAIMG.nbh is possible with this method?
damien667 said:
the SPL bootloader (engineering and original) look for NBH files on the SD card.
DREADIAG.nbh
and
DREAIMG.nbh
As you can see, their purpose is clear. One is for booting diagnostics and the other is for flashing the firmware.
Click to expand...
Click to collapse
So could we create a dreadiag.nbh from RC29?
Yes indeedy. However, we don't know the format of said nbh files. We're working on it still.
richbayliss said:
The Artemis device had this so-called "Diagnostic SD" mentioned. Im asuming therefore we could dossibly create one and flash our device with whatever firmware, akin to the "Pandora Battery" for PSP.
Worth exploring, but difficult to pull of without bricking... If it is possibly to flash a signed RC30 at any point using the current SD method, then at least we know we cannot brick the phone
Click to expand...
Click to collapse
its possible to flash update.zip so we won't brick the phone... the issue is that each update checks for something on the one previously installed... like mentioned in one of my other posts its a endless loop... we can change whatit looks for but then loose the signature...
Can we not use the info here
http://wiki.xda-developers.com/index.php?pagename=Hermes_NBH
To go the other way!?
richbayliss said:
Can we not use the info here
http://wiki.xda-developers.com/index.php?pagename=Hermes_NBH
To go the other way!?
Click to expand...
Click to collapse
ok... HAs anyone tried to extract DREAIMG.NBH just to see how its formated or structured??? If so we could compare it to the data listed for the hermes nbh format just to compare differences(if any) to see how closely they match... just a thought
If I could get a copy of the file I would give it a whirl... but cannot find it anywhere.
Guys,
NBH files are a proprietary format. They are like the update.zip, but different. We don't know how, as this is embedded into the SPL code that is all in binary format at the time (it's not been disassembled). No one except HTC and/or T-Mo will have these original files anyway. This means we're going to have to build one from scratch with reverse engineering of the spl (at least that's what it looks like as of now). That being said, there is no NBH file that is "found" on any file system of the G1. The NBH file contains files within itself that are flashed onto the NAND flash of the phone, like update.zip. The difference is that NBH files are not signed (that we know of yet), and the format in which they have to be assembled.
richbayliss said:
If I could get a copy of the file I would give it a whirl... but cannot find it anywhere.
Click to expand...
Click to collapse
I cant find it either.... its out there though... too many people have posted their experiments with it... if any has it or know where it is is located please post... thank...
DREAIMG.nbh is nowhere. People are just creating empty files with that filename to see what the bootloader will do.
damien667 said:
DREAIMG.nbh is nowhere. People are just creating empty files with that filename to see what the bootloader will do.
Click to expand...
Click to collapse
Yup. Well to be correct there are probably true DREAIMG.NBH files somewhere out there (at a htc repair center most likely), but they have not yet made their way into the hands of the hacking community.
True.
I would rick messing if there was an update.zip of the OTA RC30 as is now. So I could rescue myself.
Looking at the WinMo phones, they have NBH for a few devices, and it is common for all of them to put the OS partition at header 0x0400, even on the latest Diamond device. So I would risk trying a file with this IF I knew I wouldnt be bricking for life.
richbayliss said:
True.
I would rick messing if there was an update.zip of the OTA RC30 as is now. So I could rescue myself.
Looking at the WinMo phones, they have NBH for a few devices, and it is common for all of them to put the OS partition at header 0x0400, even on the latest Diamond device. So I would risk trying a file with this IF I knew I wouldnt be bricking for life.
Click to expand...
Click to collapse
there is an official rc30 update.zip out... however it does not seem to alter the os... i re-flahed my rc30 with it and i didnt have to re log into google and nothing was missing... all of my text messages were even intact
When you flash with update.zip, it does not affect the data partition (where all your settings and installed apps are located). It only changes radio, system, and boot partitions.
formar of DREAIMG.nbh:
0x200 bytes header,
then N images one by one(radio, hboot, recovery, boot, splash, sysfs, userfs)
header:
000: 48 00 00 00 54 00 00 00 43 00 00 00 49 00 00 00 │H...T...C...I...
010: 4D 00 00 00 41 00 00 00 47 00 00 00 45 00 00 00 │M...A...G...E...
020: 44 52 45 41 31 30 30 30 30 00 00 00 00 00 00 00 │DREA10000.......
030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │................
seems like simple "magic"
+0x40: 32 DD's - IMHO type descriptor's (type of each image, 00 if not used)
+0xC0: 32 DD's - offset of images
+0x140: 32 DD's - size of each image
+0x1C0: version?
1C0: 31 31 31 31 31 31 31 31 00 00 00 00 00 00 00 00 │11111111........
1D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │................
1E0: 30 2E 30 35 2E 30 2E 30 00 00 00 00 00 00 00 00 │0.05.0.0........
1F0: 47 65 6E 65 72 69 63 00 00 00 00 00 00 00 00 00 │Generic.........
Booting from the SD card is probably how you enter the manufacturers test mode RE: FACTORY_TEST Run as a manufacturer test application, running as the root user. "android.permission.FACTORY_TEST"
http://code.google.com/android/reference/android/Manifest.permission.html