Related
All right... GOOD NEWS story for today!!!
There is no doubt, that our gods are helping us...
Here's what happened to me yesterday.
Yesterday I was dreaming about editing the ROM of Universal/Exec but as you may know, 'd2s' command doesn't work. It just quits with "Not allow operation".
But suddenly, my china god of wisdom whispered to me:
GOD: "hey buzz, you wanna dump the thing? why do you use that old fashioned 'd2s' command to dump it?"
me: "well, that always worked... so what else should i use?"
GOD: "OK, here's a little present for you ) just try 'task 32' )) "
Code:
USB>task 32
SD:Waiting for card insert.........
CMD3 for SD, it's OK, ready to get RCA from response.
SD:Detected one card
SD:ready for transfer OK
d.total_lba=1DC00
d.block_size=200
d.RCA=EC7E
d.drv_type=40000000
d.busWidth=1
Total card size=3B80000
So here it is !!!!
... and LET THE FUN BEGIN!!!
The above story is 100% true, i've made up maybe two words myself...
BTW, this might also work on other "password protected" devices.
THANX
buzz
Buzz, that's great, where the heck did you find that command?
But now that bal666 has that decrypt/encrypt utility of the original NBK files, what would be the benefit of dumping the ROM to the SD card?
Can you restore back to the device from the SD card?
Going by the way of the SD card to dump, extract, modify, write back, then flash may be safer than the Upgrade Utility that keeps my device stuck in Bootloader mode until I go through the whole NK/MS, then Radio upgrade.
So, what's the opposite of 'task 32?'
Thanks!
i'm dumping at the moment, but i would say, that it would be enough to insert the SD card back into the slot and reboot into bootloader mode.
Then you have to wait few seconds till "press power to flash" message appears.
But so far i didn't test it, yet...
Testing right now...
))
buzz
buzz_lightyear said:
i'm dumping at the moment, but i would say, that it would be enough to insert the SD card back into the slot and reboot into bootloader mode.
Then you have to wait few seconds till "press power to flash" message appears.
But so far i didn't test it, yet...
Testing right now...
))
buzz
Click to expand...
Click to collapse
Buzz, it is really good news. At this moment some of Universal (e.g. T-mobile) providers have not released an update yet. So if people can dump their roms on a SD, we at least have a fall back. In case of repairs the Universal will need to be updated again with a rom from the provider.
That is really a fantastic news!
If the restore test is successful, please just let all of us know.
Oh, and look forward to a complete dump backup/restore guide. :wink:
BeyondtheTech said:
But now that bal666 has that decrypt/encrypt utility of the original NBK files, what would be the benefit of dumping the ROM to the SD card?
Click to expand...
Click to collapse
From what I've seen his tool incorrectly decrypts NBF, some blocks are mixed.
hmmm.....
i think that the "task 32' commande needs a little bit more tweaking...
Till now it was just saying OK... ready.. etc., but actually did not the dump... (
Code:
USB>task 32
SD:Waiting for card insert.........
CMD3 for SD, it's OK, ready to get RCA from response.
SD:Detected one card
SD:ready for transfer OK
d.total_lba=F1F00
d.block_size=200
d.RCA=80CA
d.drv_type=40000000
d.busWidth=1
Total card size=1E3E0000
Level = FF
USB>
Well, "Level = FF" sounds like an error to me....
hmmm....
buzz
Another very interesting command and it's output:
Code:
USB>info 2
SD:Waiting for card insert.........
CMD3 for SD, it's OK, ready to get RCA from response.
SD:Detected one card
SD:ready for transfer OK
d.total_lba=F1F00
d.block_size=200
d.RCA=80CA
d.drv_type=40000000
d.busWidth=1
Total card size=1E3E0000
HTCSDOPOD601 «Jú½HTCE
USB>
Code:
USB>info 7
HTC Integrated Re-Flash Utility for bootloader Version : 1.40h, UNIVERSAL HW Version : 1.00
Built at: Sep 2 2005 15:14:29
Copyright (c) 1998-2005 High Tech Computer Corporation
Turbo=312, Run=208
Memory Frequency = 208 MHz
SDRAM Frequency = 104 MHz
Board ID is: 5
USB>
buzz
buzz_lightyear said:
Code:
Board ID is: 5
Click to expand...
Click to collapse
Hi Buzz,
is it possible to make memory dumps
in the bootloader without entering a password ?
cr2 said:
buzz_lightyear said:
Code:
Board ID is: 5
Click to expand...
Click to collapse
Hi Buzz,
is it possible to make memory dumps
in the bootloader without entering a password ?
Click to expand...
Click to collapse
not in bootloader...
but i'm able to dump DOC and memory using RapiEnabler and itsutils.
buzz
buzz_lightyear said:
but i'm able to dump DOC and memory using RapiEnabler and itsutils.
Click to expand...
Click to collapse
Hmm. What part of the DoC ? All 128 MB ?
There is also OTP and other stuff.
As you can guess, i'd like to dump the whole 64MB RAM (or as much as possible) while the bootloader is running, not
in wince.
Maybe you should try 'r2sd' ?
mamaich said:
BeyondtheTech said:
But now that bal666 has that decrypt/encrypt utility of the original NBK files, what would be the benefit of dumping the ROM to the SD card?
Click to expand...
Click to collapse
From what I've seen his tool incorrectly decrypts NBF, some blocks are mixed.
Click to expand...
Click to collapse
He stated that as long as you don't change the header information, it will encrypt and decrypt properly.
As a precaution, I took the NK.NBF, decrypted it to NK.FAT, then reencrypted it and did a successful byte-comparison.
I did the same with my modified NK.FAT file with my injected custom splash image and it encrypted and decrypted properly.
The biggest test was flashing it, and man, I was sweating buckets during the process. But, the flash came through successful for me and now I have the first custom splash screen on the Universal.
It's fun to break news or be the first guinea pig to try it out, just as long as it comes out successful! :lol:
The password doesn't seem do do anything.
The level of access is determined by your CID.
If your CID is 11111111 you have a SuperCID, which enables all the operations. I'm trying to track down where the CID is stored.
Bye,
Ricardo
go beyoundthetech !!!!
now only if you could post a step by step for all us goofs out here...
also im wondering with your genius if you could use the recently posted tools here to make custom universal rom (minus the ie explorer, file explorer etc) and teach us how to do that aswell!!!!
buzz_lightyear said:
i'm dumping at the moment, but i would say, that it would be enough to insert the SD card back into the slot and reboot into bootloader mode.
Then you have to wait few seconds till "press power to flash" message appears.
But so far i didn't test it, yet...
Testing right now...
))
buzz
Click to expand...
Click to collapse
My 9000 has a SuperCID. I managed to dump and flash the rom using these techniques.
Bye,
Ricardo
BeyondtheTech said:
He stated that as long as you don't change the header information, it will encrypt and decrypt properly.
As a precaution, I took the NK.NBF, decrypted it to NK.FAT, then reencrypted it and did a successful byte-comparison.
I did the same with my modified NK.FAT file with my injected custom splash image and it encrypted and decrypted properly.
Click to expand...
Click to collapse
I decrypted nk.nbf to nba with his tool, and decrypted the same file with alpinenbfdecode.pl script. Files are different after some offset. So there should be a bug in his util, because alpinenbfdecode.pl is known to produce working files. I had no time for more tests.
buzz_lightyear said:
Another very interesting command and it's output:
Click to expand...
Click to collapse
Hi buzz,
i can run "rbmc", but don't get where is this c:\test\mem.nb located.
Is it used by the mtty download protocol ?
I can't test it because mtty is not working
for me in windowz
cr2 said:
buzz_lightyear said:
Another very interesting command and it's output:
Click to expand...
Click to collapse
Hi buzz,
i can run "rbmc", but don't get where is this c:\test\mem.nb located.
Is it used by the mtty download protocol ?
I can't test it because mtty is not working
for me in windowz
Click to expand...
Click to collapse
looks like rbmc is running up to the point, where it should start saving the dump (
same as task 32
(
buzz
OK, so here is, how it should be:
Dump Bootloader:
Code:
USB>task 32
USB>d2s 70000000 80000
OS ROM + splash:
Code:
USB>d2s 70100000 3FA0000
XtendedROM:
Code:
USB>d2s 74100000 A00000
Radio ROM:
Code:
USB>d2s 60000000 a24200
If you want to have them all on single SD card, you must add "sd a" at the end of each command except the first one.
Example to dump/backup OS + XtendedROM + Radio:
Code:
USB>d2s 70100000 3FA0000
USB>d2s 74100000 A00000 sd a
USB>d2s 60000000 a24200 sd a
buzz
After banging my head with the update utility and a bootsplash stuck universal for like hours, I did decrypt the bootloader 1.0... Will do some reverse engineering and post what I find... :lol:
Update: decrypted Bootloader 1.0 is attached...
ady,
if this is true... congratulations!!!
you may want to share your knowledge with buzz and the other specialists ;-)
have a good success
peter
hi ady,
GREAT!
could you please tell me how you did it?
thanx
buzz
By hacking the ruu.dll and running the upgradeut. I'm away at the moment. Will post it later
ady said:
By hacking the ruu.dll and running the upgradeut. I'm away at the moment. Will post it later
Click to expand...
Click to collapse
very interesting approach... )))
buzz
Thanx buzz.
something which I observed earlier while looking at the string table:
It has multilevel password protection and the password for each level i.e update, erase, dump, debug is calculated at runtime.
Moreover the access level resets to lowest after a certain time which makes it almost unhackable
There are strings related to CID meaning there might be a method to change CID
updated first post to attach the decrypted bootloader 1.0 for those who are interested.
Also I succesfully flashed the 1.0 bootloader on a device which was previously updated with 1.01...
Of course if was after hacking the RUU.dll. By default it doesn't let you update to an older bootloader
ady I have been looking at the bootloader of the prophet and the interaction between the romupdate utility and the phone with a software logic analyzer which has revealed a lot of information including the commands that romupdate runs while upgrading the rom.
I am in the process of compiling a list of bootloader commands which may be usefull.
Did you dump the commands while downgrading the bootloader.
Pete
you can find a list of commands very easily. just look at the string table. however not all commands are allowed and that is the callenge
Some commands do not appear to be secured correctly.
For example the rbmc command.
If I run it without a password it says no pemission enter any password and then it will run fine.
The password issued by the romupdate tool seem to be based partly upon the results of the info 2 command as far as I can tell.
The main command I am struggling to figure out is the r2sd command which reads a key/password from the SD Card.
Rymez2K said:
The main command I am struggling to figure out is the r2sd command which reads a key/password from the SD Card.
Click to expand...
Click to collapse
hi,
did you mean d2s command?
buzz
r2sd command runs well when u hv CID unlocked..works for Prohet,wizard and charmer..typhoon
hdubli said:
r2sd command runs well when u hv CID unlocked..works for Prohet,wizard and charmer..typhoon
Click to expand...
Click to collapse
;o))) I thought, this is about Universal 1.00 bootloader...
buzz
According to some source of information there are 2 types of Universal. One with G3 and another with G4 chips. G3 bootroms have string "HW Version : 1.40h" in bootloader and its version is 1.xx, G4: "1.40j" and version numbers are 2.xx. Your ROM is for G3.
And bootrom can be decoded from nk.nbf with alpinenbfdecode.pl script
ady said:
By hacking the ruu.dll and running the upgradeut. I'm away at the moment. Will post it later
Click to expand...
Click to collapse
If this is correct , i hope, ...the nk.nbf of JASJAR bootloader can be decoded from bal66 tool and one can get.nba file.But I was not able to decode further with imgfs tools...it simply fails to do that....
@hdubli
bootloader image - nk.nba - is not an imgfs. you cannot use mamaich's imgfs_tools on it.
bal66's tool cannot decode bootloader nk.nbf to nk.nba either.
buzz
Attached is the file...pls check
hdubli said:
Attached is the file...pls check
Click to expand...
Click to collapse
yes, that file looks to be OK...
buzz
another thing:
lnb command doesn't work on 1.0 or 1.01. Another command wdata is used instead to update.
the difference between the two commands is that lnb needs to have an nb image i.e. lnb lnbtemp.nb whereas wdata transfers the image directly from host computer memory (more hack safe)
I have searched the forum but could not find something of relevance.
It might sound stupid and maybe there is an easy explanation, but what I just don't understand is the following:
TyTN specs say 128meg ROM, 64meg RAM.
Looking at Start->Settings->Storage it tells me (translating from German):
File storage total: 56.22 megs
Program storage total: 48.80 megs
Then the usual stuff like 'used' and 'available'.
Of course there is the ExtendedROM which shows a total of 9.57 megs.
Where's the 128 megs gone or what am I missing here??? :roll:
Thanks for your help.
Cheers,
StonyA
the operating system basically. a perfectly intact copy is held in rom so that you can reinstall at any point using hard reset, this image is what you flash when you update your phone (same goes for your radio protocol).
hope this helps
herman3101 said:
the operating system basically. a perfectly intact copy is held in rom so that you can reinstall at any point using hard reset, this image is what you flash when you update your phone (same goes for your radio protocol).
hope this helps
Click to expand...
Click to collapse
Hello herman3101,
Thanks for your reply! Still a bit confused though. I understood the files stored in the "ExtendedROM" to be those who are used for reinstall.... ???
Even though, why doesn't it show Total ROM 128megs and xxx used???
I guess, I am still something missing :?
Cheers,
StonyA
The extended rom contains the customizations and patches that your carrier decides to put on, this is the way that different roms vary between carriers. The extended rom does NOT contain the operating system, this in a seperate hidden region of your rom (note that rom in this case has two variations of a meaning, one refers to the physical memory on your phone, the other refers to the image that is placed into that memory)
Think of that part of your memory as being an image of your windows xp cd rom, for normal day to day running its not needed as all the files it needs recide on your hard disk but when you come to reinstall you need to work of the cd. Same principle applies to that part of the rom. apologies if my analogy only makes sense to me, I have a habit of doing that.
Hey herman3101,
Many thanks for your explanation. Yes it does make a lot of sense what you are saying. Still don't understand why HTC does not openly show that, i.e. 128 megs rom, xxx megs used, xxx megs available.
Cheers & great weekend,
StonyA
The SMT5600 is app unlocked and, I think, Super CID (via lokiwiz02_173 but how verify?) but no ROM changes as of yet as I want to make a backup of the original ROM before proceeding further.
After problems getting a term program to work (now using nueTTYConsole on Vista) I am able to get what appear to be complete ROM backups.
Procedure summary:
WinHex zero fill 64MB SD
USB bootloader SMT5600 with 64MB SD
r2sd all (via nueTTYConsole-12-v0.1-spackr)
SD back to PC [no to format query]
psdread E: 0 31328768 ipl.bin (using itsutl050119)
Status messages from the r2sd all command appear to be good and complete but no two backups, using the exact same procedure, are ever identical when binary compared with WinMerge. Size is, of course, the same but WinMerge always reports 'two' differences in what seems to be the same general area of the images: The first is very near the front of the image (WinMerge reports as 'lines', line 3) and the other at the very tail end.
Is that normal (maybe because TIME, or some other dynamic variable, changes or scratch storage?), is there a better backup procedure, and how can I verify the backups are good before I flash a new one and forever lose the original?
Thanks in advance for any enlightenment offered.
To check if it works - just restore the backups before doing anything else.
Follow the whole procedure (including psdread and - after reformatting the card - psdwrite again) to restore your device via the card. As a first try leave out the device external activities and restore immediately afterwards from the card just written.
For me it works well (on the SDA 2 - where no official update exists, a Hurricane device - but this generic handling is identical afaik) and the difference in the backups are normal.
Mind that the size of the read/write to card includes the bootsector, so don't miss the last 512 bytes. As far I remember there were two different size readings with two methods to verify the image size. The r2sd size is smaller than the size of bytes different to null on card.
To check for SuperCID enter "info 2" in the terminalprogram, it should report HTCSuperCID at the end.
tobbbie said:
To check if it works - just restore the backups before doing anything else.
Follow the whole procedure (including psdread and - after reformatting the card - psdwrite again) to restore your device via the card. As a first try leave out the device external activities and restore immediately afterwards from the card just written.
Click to expand...
Click to collapse
Thanks for the reply
Yes, I thought about doing a test restore, but, considering the problems I'd already had, wasn't sure if it might do something like not mention there being a 'problem' till it was half way through, leaving me with a scrambled ROM.
I take it you're saying it'll checksum first and no even start if things don't look good?
tobbbie said:
For me it works well (on the SDA 2 - where no official update exists, a Hurricane device - but this generic handling is identical afaik) and the difference in the backups are normal.
Mind that the size of the read/write to card includes the bootsector, so don't miss the last 512 bytes. As far I remember there were two different size readings with two methods to verify the image size. The r2sd size is smaller than the size of bytes different to null on card.
Click to expand...
Click to collapse
Hmm. I saw the confusion about SMT5600 image size but I'm not sure what you're saying here about the bootsector and "different to null."
Speaking of which, what would be wrong with just making a 64M save and, ok, you've save a pile of extraneous 0's along with it but, so what? Might be irritating if I were putting it on rapidshare but for a personal backup is there any down side to it?
tobbbie said:
To check for SuperCID enter "info 2" in the terminalprogram, it should report HTCSuperCID at the end.
Click to expand...
Click to collapse
Thanks. Good to know.
Something apparently went wrong somewhere because I didn't get that report but I'll try again.
The r2sd is a command that HTC has implemented in the SPL (Secondary Program Loader). I am not aware of checksums or other safety measures - it will as I noticed following the procedure detect if there is an image on the card, which type of image and if you want to restore.
The difference in size is that r2sd reports one size "x" after the image was taken, but if you count the bytes until when the card shows the zeros you will notice that this offset on card is 512 bytes larger than the r2sd reported size. So when using psdread you have to take the larger size. Indeed it is no problem to write more to the file and restore more as well with psdwrite. The restore procedure in the SPL will anyway know how much to restore - it just needs to find ALL bytes, including the last 512
I think there is no risk attached to the procedure, go ahead!
The only danger is if something goes wrong with the IPL (Initial Program Loader) or SPL because they open the door to the device handling.
Sadly you MUST deal with SPL to upgrade to WM5+ afaik, so be very sure to select the right IPL and SPL that matches your device HW (OMAP 730, 750 or 850) and intended OS Version. Also take care not to enter any command in the SPL except the ones you are supposed to enter - it may kill your device as well. Do never use "format all" or "doctest" - you have a brick then.
tobbbie said:
The r2sd is a command that HTC has implemented in the SPL (Secondary Program Loader). I am not aware of checksums or other safety measures - it will as I noticed following the procedure detect if there is an image on the card, which type of image and if you want to restore.
Click to expand...
Click to collapse
Well, I am certainly no expert on this thing but r2sd spits out a wealth of information, including checksums, and I was sort of guessing based on what I'd do if I'd made it. Just that, if you're going to calculate them, it seems a shame to not use them. But, hey, I've seen stranger things done.
tobbbie said:
The difference in size is that r2sd reports one size "x" after the image was taken, but if you count the bytes until when the card shows the zeros you will notice that this offset on card is 512 bytes larger than the r2sd reported size. So when using psdread you have to take the larger size. Indeed it is no problem to write more to the file and restore more as well with psdwrite. The restore procedure in the SPL will anyway know how much to restore - it just needs to find ALL bytes, including the last 512
Click to expand...
Click to collapse
Oh, OK. I wasn't going by r2sd. I opened it up in WinHex, found the end of data, and compared that to the size mentioned on "Backup your Typhoon ROM - WinMo @ MoDaCo." The 'corrected' number there matched well enough.
But now that I think of it, I did that because I *did* look at r2sd and it seemed too small. So you've explained it. Good.
tobbbie said:
I think there is no risk attached to the procedure, go ahead!
Click to expand...
Click to collapse
How can there be no risk if it doesn't check anything?
tobbbie said:
The only danger is if something goes wrong with the IPL (Initial Program Loader) or SPL because they open the door to the device handling.
Click to expand...
Click to collapse
Oh, I think I see what you mean. You're suggesting that if I've cut the ROM image short then only that part will fail but the loader should still be good so I could recover by burning another (good) ROM image.
Well, perhaps, but that would mean I don't have a valid backup and couldn't make one since it would be trashed in the bad flash. Or so it seems to me.
tobbbie said:
Sadly you MUST deal with SPL to upgrade to WM5+ afaik, so be very sure to select the right IPL and SPL that matches your device HW (OMAP 730, 750 or 850) and intended OS Version. Also take care not to enter any command in the SPL except the ones you are supposed to enter - it may kill your device as well. Do never use "format all" or "doctest" - you have a brick then.
Click to expand...
Click to collapse
I was thinking of going straight to WM6.x per
karhoe.net/guide-upgrading-htc-feelertyphoonamadeus-to-windows-mobile-6-update-september-06-2008.html
which involves changing the loader first via Patched_RUU
Do you think going to WM5 first is a safer procedure?
I said I was not aware of any checking - but as I have not written the SPL, I simply do not know it. You are right that reporting stuff like this makes it highly probable that upon restore a check on the image should be done before restoring. Try it out, if you like
WM5 or WM6 does not make a difference what the SPL is concerned. Afaik you have to use the same anyway. The device is tight in memory anyway, so don't expect miracles.
Go ahead, either dare it or leave it...
tobbbie said:
I said I was not aware of any checking - but as I have not written the SPL, I simply do not know it. You are right that reporting stuff like this makes it highly probable that upon restore a check on the image should be done before restoring. Try it out, if you like
Click to expand...
Click to collapse
Hehe. Yeah.
I was sort of hoping someone else had already stepped off that cliff and could tell me what the ground was like before I dove in
tobbbie said:
WM5 or WM6 does not make a difference what the SPL is concerned. Afaik you have to use the same anyway. The device is tight in memory anyway, so don't expect miracles.
Go ahead, either dare it or leave it...
Click to expand...
Click to collapse
The primary aim was to get bluetooth a2dp but the incentive may have diminshed, depending on how another project works out.
Thanks again for the help.
I would not bet on A2DP - I have it in the Tornado and the CPU use is much higher due to additional compression on the BT interface. Player + BT overhead is getting to average above 80% CPU (depending no the settings, but for good quality is like this) - it will also drain your battery much faster.
The Typhoon, Hurricane and Tornado have identical good analog Audio capabilities (I measured them with RMAA - see www.rightmark.org) and make a perfect music player as they are.
If your device is SuperCID you can take any other Typhoon ROM - you must just be sure that r2sd will save your bootloader + OS if you want to go back to WM2k3. I have done this already on my Amadeus (and went back to WM2k3) and this can still serve as a nice musicplayer.
tobbbie said:
I would not bet on A2DP - I have it in the Tornado and the CPU use is much higher due to additional compression on the BT interface. Player + BT overhead is getting to average above 80% CPU (depending no the settings, but for good quality is like this) - it will also drain your battery much faster.
The Typhoon, Hurricane and Tornado have identical good analog Audio capabilities (I measured them with RMAA - see www.rightmark.org) and make a perfect music player as they are.
If your device is SuperCID you can take any other Typhoon ROM - you must just be sure that r2sd will save your bootloader + OS if you want to go back to WM2k3. I have done this already on my Amadeus (and went back to WM2k3) and this can still serve as a nice musicplayer.
Click to expand...
Click to collapse
I admire people who can make these flash things work because it never does for me. I've now got an SMT5600 that will do nothing but display a rainbow boot screen and error out regardless of what ROM I try.
That's why I didn't try this till I had a new phone.
Hey that thread has a long history - what happened in the meantime?
3 colour screen does not mean the device is dead yet. You still have a bootloader that works and this is the thing to start from in any case.
What do the lines tell in the 3 color bars?
Did you already upload the changed SPL (I think it was 1.09) that allows to flash ROMs of WM5 or WM6 on that original WM2k3 device? If so, the you need to revert back to old SPL first before you can upload the original ROMs again.
tobbbie said:
Hey that thread has a long history - what happened in the meantime?
Click to expand...
Click to collapse
I put it on hold pending a new phone and other things cropped up.
Frankly, I had 2003 pretty well tricked out with SmartToolkit and gStart.
tobbbie said:
3 colour screen does not mean the device is dead yet. You still have a bootloader that works and this is the thing to start from in any case. What do the lines tell in the 3 color bars?
Click to expand...
Click to collapse
I swear it wasn't a troll but no sooner than I posted it wouldn't flash I managed a flash and I'm not sure why this worked when the others failed.
I was trying to verify the hard spl, getting info, etc. To make that easier I turned 'ui' on during boot and, just for chuckles expecting nothing, I tried flash again. You know, the definition of 'insanity'. Low and hold the dern thing flew.
As far as I know nothing was different other than 'ui' on. Same tools, same wm6.5 bin file, etc.
tobbbie said:
Did you already upload the changed SPL (I think it was 1.09) that allows to flash ROMs of WM5 or WM6 on that original WM2k3 device? If so, the you need to revert back to old SPL first before you can upload the original ROMs again.
Click to expand...
Click to collapse
You have no idea how helpful mentioning "1.09" is. The SPL flash program opines something like changing to v 5.000 but that number shows up no where and no where does it tell you to look for '1.09'. There are other confusions, like saying the existing device was 'Orlando' (I think it was), but I guess that's moot now.
Anyway, it's now running WM6.5 and I have a new toy to fiddle with inbetween playing with Android on my Tilt 2.
Thank you for the help.
Glad it worked now
The older (wm2k3) devices could only be updated with a binary transfer protocol (the .BIN file - which can be confused with other ".bin" in the scope of cooking in general). To enable the reception of the MTTY command "l" (for Load) and the execution of the related actions, the SPL must be in "UI" (User Interface) mode - this is the key for further flashing - and it must be mentioned in all such upgrade manuals. Also mind that other terminal programs (like TerraTerm) have not implemented that protocol. So only MTTY works for that purpose! As I am struggling currently with porting a Tornado ROM to the Hurricane I have come quite deep into that topic recently.
Are you having the WM65 from aleut now on the device? I think it is very tight on RAM now, so what are the memory key-data from settings->about after a reboot? You should repeat that with the standard home screen (Windows default) which is less memory greedy.
The way back to WM2k3 is not so easy as you must replace the SPL with the original one first before you can get back to the original OS. Whenever you mess with SPL it is a potentially dangerous action as failure doing that right will result in a bricked device.
tobbbie said:
Glad it worked now
The older (wm2k3) devices could only be updated with a binary transfer protocol (the .BIN file - which can be confused with other ".bin" in the scope of cooking in general). To enable the reception of the MTTY command "l" (for Load) and the execution of the related actions, the SPL must be in "UI" (User Interface) mode - this is the key for further flashing - and it must be mentioned in all such upgrade manuals. Also mind that other terminal programs (like TerraTerm) have not implemented that protocol. So only MTTY works for that purpose! As I am struggling currently with porting a Tornado ROM to the Hurricane I have come quite deep into that topic recently.
Click to expand...
Click to collapse
So I discovered after missing the little '0' in the instructions.
tobbbie said:
Are you having the WM65 from aleut now on the device? I think it is very tight on RAM now, so what are the memory key-data from settings->about after a reboot? You should repeat that with the standard home screen (Windows default) which is less memory greedy.
Click to expand...
Click to collapse
Yes, I originally flashed Aleuts 6.5 but I've since reflashed with his 6.1.
tobbbie said:
The way back to WM2k3 is not so easy as you must replace the SPL with the original one first before you can get back to the original OS. Whenever you mess with SPL it is a potentially dangerous action as failure doing that right will result in a bricked device.
Click to expand...
Click to collapse
Yep, flashing SPL is the most vulnerable but I don't think I'll be going back to 2003. Although, I might try WM5 if that has more free memory.
With most things I plan on using installed there's 8.5Meg free at boot and while that sounds laughable by today's standards there's only 22Meg total for a more impressive sounding '38% free' Although, as soon as you touch the thing almost half of that is gone.
" PWNED " :-D
As you know, Archos bootloaders check digital signatures of init and recovery kernels, so you need to install SDE to use custom kernels, and it somehow "watermarks" the device.
Good news everyone! I've disassembled both bootloaders, found the code which checks signature, and replaced it (first instructions of verify_hash function) with "return 0" which is "mov r0, #0; bx lr" in ARM assembly. It's much the same hack as on Archos 5, thanks EiNSTeiN from archos.g3nius.org for reverse engineering previous generation.
Archos gen8 boots using OMAP boot ROM from internal eMMC card. Primary bootloader ("boot0") is in 0x20000 bytes after the first sector of internal flash (i.e. at 0x200) and secondary bootloader is written into rawfs, /mnt/rawfs/avboot. boot0 contains image size and loading address in first 8 bytes.
So, here is the patch:
1) boot0: replace 8 bytes at 0x7520 from the beginning of mmcblk0 from 7F402DE9003091E5 to 0000A0E31EFF2FE1.
2) avboot: replace 8 bytes at 0x14424 in avboot from 7F402DE9003091E5 to 0000A0E31EFF2FE1 (same patch). 0x14424 from avboot beginning is usually 0x14824 from the beginning of mmcblk0p1 (avboot comes first in rawfs, just after 2 blocks of header).
Of course you need root to do it. I've done it on my Archos 101, then changed 1 byte in recovery image - it boots into recovery without problem (before the hack it didn't boot into this 1-byte changed recovery).
And of course do it with caution and at your own risk DO NOT replace the bytes if you find other original data at these offsets! Bad boot0 or avboot means bricked Archos. There must be some sort of test point (something connected to OMAP SYS_BOOT5 pin) to boot from USB, or a boot UART interface, so debricking the device must be possible, but it would require some effort to find it, find a proper bootloader and use it.
If someone wants to see IDA database, I'll send my.
P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.
Great work! With this base, can yout get something like CW to run?
I'm so waiting for him to come back and say April fools.
I'm gonna screw him up if this was an april fool
First, if this is an April fools, I will find you and hurt you.
Second, what does all that mean anyway? Does that mean Cyanogen on Gen8 is near? Does it have anything to do with roms?
vitalif said:
P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.
Click to expand...
Click to collapse
Maybe you should increase that number of post by explaining how you did this.
)))) No it isn't an April fool, my device now really has a modified recovery. Ridiculously modified (1 byte changed), but that's the proof!
Check the patch by yourself )) all you need to write to mmcblk0 is a standard linux dd tool... which is included into standard Archos busybox...
wdl1908 said:
Maybe you should increase that number of post by explaining how you did this.
Click to expand...
Click to collapse
In fact, it was not hard, and if I knew ARM assembly language before, it would be even easier... All I had to do is to find bootloader on the flash (boot0 is obviously in its beginning, and avboot is on /mnt/rawfs), copy it to computer, download IDA, feed bootloader to it and find functions similar to ones described on archos.g3nius.org (BigInteger_ModulusEnter, RSADecipher, etc). It also could be simpler, as BigInteger_ModulusEnter is mentioned inside an ASCII string inside data section... But I've found them by text search also there is a magic "ZMfX" in first 4 bytes of avboot and some other magic inside init and recovery... One also could use them to find interesting points in bootloader.
At first I've started disassembling with the wrong base address, but bootloader has code which copies itself to the correct one in the very beginning, so I've changed it and started over. In fact, it has size and address in first 8 bytes, so this also could be simpler...
So the hack is done, what needs to be done by now - utilize it and create some custom ROM or simply flash urukdroid without SDE...
chulri said:
Great work! With this base, can you get something like CW to run?
Click to expand...
Click to collapse
CW == ClockWorkMod recovery? I don't have any experience with CWM porting yet, but in theory yes, the hack gives us the ability to run custom recovery images.
Don't know alot about the bootloader, but what advantage does this have?
SWFlyerUK said:
Don't know alot about the bootloader, but what advantage does this have?
Click to expand...
Click to collapse
Hm. I'll explain... Bootloader is the program which starts up the device, similar to bootloader on your PC signature check in bootloader prevents us installing modified Linux kernel, initial ramdisk and recovery images. So, for example, we can't have netfilter in kernel without installing SDE, we can't have ClockWorkMod recovery on Archos at all, and we can't, for example, change MMC card splitting into 512M mmcblk0 for system + remaining for "internal SD" with data.
With signature check removed, all this is possible.
The underlying idea of all this signature checking is probably protecting f**king DRM... I HATE IT !!!!!! And hate companies promoting it =) When you install SDE on previous generation archos (5it), it removes drm keys from device memory (this is the "watermarking" mentioned on Archos site). It makes device unable to play the content buyed for it anymore... Not a big deal, but unpleasant. I don't know if this is the same on gen8.
In detail: Archos 101 has OMAP3630 processor. The "0-stage" (very-very first stage) bootloader, i.e. program which gains control after processor power-up, is hard-coded into one-time programmable area on the processor itself and is named "OMAP boot ROM" (similar to PC BIOS). The boot ROM can continue device booting process from different devices including SD/MMC card, NAND flash, UART (serial port) or USB interfaces. The boot sequence is determined from physical pin connection configuration. Our Archos boots from internal eMMC card.
So, OMAP boot ROM loads primary Archos bootloader, without checking any signatures or checksums, and simply transmits control to it. Primary bootloader sets up some processor configuration and then reads secondary bootloader (avboot) from flash. Then, it checks its MD5-RSA digital signature using Archos public key. If signature is incorrect, it hangs the device (goes to infinite loop). So if we modify avboot without removing signature check from boot0, device would be bricked. If signature is correct, control is transmitted to avboot. Avboot determines what system we want to start by pressing different keys, loads it, checks signature if system is init (normal system) or recovery, sets up configuration for Linux kernel and transmit control to Linux.
Interesting facts:
* According to the code, boot0 can use rawfs or FAT filesystems for boot partition.
* During boot process, various messages are printed to serial console. avboot even has some code for receiving commands over serial connections.
* OMAP processor boot sequence can be configured via special memory area which remains unchanged after soft reset, and this configuration will override one determined by physical pin configuration. This does not give us much profit, but is also interesting...
Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?
SWFlyerUK said:
Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?
Click to expand...
Click to collapse
Whats being done will have no affect on performance of the device. It will however, allow a lot of work that can contribute to better performance on the device. That is assuming that we can put on a modified clockworkmod recovery on these devices without bricking them.
He says the only way to do this is with root but in order to have root with r/w access at this point is SDE....right? Don't get me wrong custom recovery with the ability to make backups would be awesome but it seems SDE will still be necessary unless a new rooting option comes along.
*on a side note about root has anyone tried using psneuter to gain temp root through ADB? I really am not super knowledgeable about this stuff but this was used on the thunderbolt to aid in getting full root and s-off.
Sent from my ADR6400L using XDA App
JBO1018 said:
He says the only way to do this is with root but in order to have root with r/w access at this point is SDE....right? Don't get me wrong custom recovery with the ability to make backups would be awesome but it seems SDE will still be necessary unless a new rooting option comes along.
*on a side note about root has anyone tried using psneuter to gain temp root through ADB? I really am not super knowledgeable about this stuff but this was used on the thunderbolt to aid in getting full root and s-off.
Sent from my ADR6400L using XDA App
Click to expand...
Click to collapse
Archangel will give you temp root without using SDE.
He said root with r/w access. Archangel won't do that, the file system is still protected.
pbarrett said:
He said root with r/w access. Archangel won't do that, the file system is still protected.
Click to expand...
Click to collapse
Nope r/w access is not needed the only changes to be made are on /dev/mmcblk0p1 which is mounted on /mnt/rawfs the read-only is on the root file system so they are seperate. Archangel will do just fine for this.
wdl1908 said:
Nope r/w access is not needed the only changes to be made are on /dev/mmcblk0p1 which is mounted on /mnt/rawfs the read-only is on the root file system so they are seperate. Archangel will do just fine for this.
Click to expand...
Click to collapse
To be correct, there is no write protection on internal MMC at all, there is readonly rootfs which is mounted from a squashfs archive (squashfs is compressed readonly filesystem commonly used on Linux Live CDs), so you can't modify _files_ on it while it is mounted. But, nothing stops you from updating it as a whole.
Urukdroid
Someone should give a shout out ro $auron, creator of the Urukdroid project about this, he might find it useful.
So, if your hack is confirmed, that would give us the possibility to port CW recovery and Cyanogen to Gen8 devices... am I right ?
shrewdlove said:
Someone should give a shout out ro $auron, creator of the Urukdroid project about this, he might find it useful.
Click to expand...
Click to collapse
I think he has already seen this thread but you can ask him
lechuckthepirate said:
So, if your hack is confirmed, that would give us the possibility to port CW recovery and Cyanogen to Gen8 devices... am I right ?
Click to expand...
Click to collapse
Yes you are^^ but the thing is you have to port cyanogen to our gen8^^ and this must be done by a or more devs
i heard the biggest problem is that our touchscreen is connected by an usb controller inside the archos thats why the honeycomb port by luisivan is not recognize our touchscreen ( but when the source code is released, finally, we will get a hc port )
Lennb said:
i heard the biggest problem is that our touchscreen is connected by an usb controller inside the archos thats why the honeycomb port by luisivan is not recognize our touchscreen ( but when the source code is released, finally, we will get a hc port )
Click to expand...
Click to collapse
this isn't a problem for cyanogen (v7 = Android 2.3.3) because we have the source.