Many Thanks to xda- developers esp helmi c xplod and mamaich for wm6.
We're luving it
Has anyone tried making a 32mb pagepool version of this yet ?
Actully，I make my BA‘s pagepool be 0M,Its speed is the same as that of 16M pagepool.If you like,you can change pagepool to any number as you wish.Following the list.
adrress:0x2565D3
00 00 00 00 =0M
00 00 80 00 =8M
00 00 C0 00 =12M
00 00 00 01 =16M
00 00 80 01 =24M
00 00 00 02 =32M
00 00 00 03 =48M
wongjam said:
Actully,I make my BA‘s pagepool be 0M,Its speed is the same as that of 16M pagepool.If you like,you can change pagepool to any number as you wish.Following the list.
adrress:0x2565D3
00 00 00 00 =0M
00 00 80 00 =8M
00 00 C0 00 =12M
00 00 00 01 =16M
00 00 80 01 =24M
00 00 00 02 =32M
00 00 00 03 =48M
Click to expand...
Click to collapse
is this a hex edit? and if so, which file do we need to make it to? thx in advance.
hi, koi_desi_pagal
Have you tried to perform search and what results you get? Is there anything you dont understand or causing problems in tutorial you've found?
unsuccessful
wongjam said:
Actully，I make my BA‘s pagepool be 0M,Its speed is the same as that of 16M pagepool.If you like,you can change pagepool to any number as you wish.Following the list.
addrress:0x2565D3
00 00 00 00 =0M
00 00 80 00 =8M
00 00 C0 00 =12M
00 00 00 01 =16M
00 00 80 01 =24M
00 00 00 02 =32M
00 00 00 03 =48M
Click to expand...
Click to collapse
I am using winhex and realize that it doesn't use hexadecimal but decimal address, so I changed 0x2565D3 into 2450899 but it seemed unable to work although I tried 4 choice of searching (from begin, from back...). I also tried to find the value 00000001 but unsuccessful.
All works were done in nk.nbf
Any ideas?
oradoe said:
I am using winhex and realize that it doesn't use hexadecimal but decimal address, so I changed 0x2565D3 into 2450899 but it seemed unable to work although I tried 4 choice of searching (from begin, from back...). I also tried to find the value 00000001 but unsuccessful.
All works were done in nk.nbf
Any ideas?
Click to expand...
Click to collapse
@oradoe
In order to successfully hex edit a rom, you first need to convert the nk.nbf into NK.nba. Then, you hex edit, and finally reconvert it to nk.nbf.
Since you might ask how to do that, you may want to go to the Blue Angel Upgrading forum and look for the thread called "the Reason for the BA slowdown". If I am not mistaken, you should look within the first 5 to 7 pages and you will see a post from Forza that explains how to do the whole thing. Just remember that the WM5 address for the page pool is different from that of WM6.
Happy Hexing
Did anybody test different pagepool?
i been searching for 8hrs at wiki n forum, downloading more than 50 files (typho5.exe, xda3nbftool.exe etc:..) but still nothing.
Still trying....
And the addresses for Wm6.1? Thanks.
Related
I was attempting to use dumprom on a PDA phone other than XDA... I extracted the memory address from 0x80000000 to 0x81FFFFFF using pmemdump, and ran it through dumprom. As it turns out only the bootloader and a small part of the kernel got extracted. Nothing of the OS or the application files came out. As it turns out, looking at the dumped file, the 'good part' is missing and seems to be located elsewhere in the memory.
But then I have a rom image that can be used to flash the device, so I tried to use the image with dumprom, but that gave me an error, obviously, as the image is not laid out like how it's mapped out in the memory.
So how should I go about in extracting the files? For example, what do I have to do to modify the rom image to work with dumprom? I'll upload the rom image in question or the memory dump if need be.
To dump ROM of any PocketPC, you should extract first 32 Mb of physical memory starting from 0 address. They contain bootloader and ROM image at least on PXA25x, 26x and 27x CPUs. For example you may use my program: http://mamaich.kasone.com/imate/ROMDump.rar
it comes with source code and dumps 64Mb of ROM to any directory on SD card. Later you can extract files from this dump with "dumprom.exe dump.bin -4 -d C:\dump"
I've tested this method on several devices and it worked. If device contains 32mb ROM, the second half of a dump would be identical to the first 32 mb.
The BIN/NBF files used to flash are sometimes stored in a format with unnecessary parts removed. Such files normally start with "B000FF" signature and their format is explained in PlatformBuilder documentation. You may try to write a program that would convert them to a "normal" dump that dumprom understands.
Unfortunately, that didn't go well. The CPU is PXA255 and the OS is WM2003, but whatever ROMDump pulled out, it wasn't of any relevance. The attached file is what it put out. It's 64MB, but as you can see from the size of the compressed result, there's not much useful information in it. It's just a repetitive garbage data that goes on for the whole 64MB. Maybe the program was accessing the wrong area? To be sure, I ran the file through dumprom, and the program hanged. This isn't even as good as pmemdump, sadly. What seems to be the problem?
Probably the problem is in wrong addresses to dump. You should modify my RomDump code so that it would check all 4Gb of adress space in 32-mb blocks to find a block that looks like a ROM start. Rom starts with someting like:
Code:
0000000000: FE 03 00 EA 00 00 00 00 │ 00 00 00 00 00 00 00 00 ъ
0000000010: FE 03 00 EA 00 00 00 00 │ 00 00 00 00 00 00 00 00 ъ
0000000020: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
0000000030: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
0000000040: 45 43 45 43 4C 4B 12 84 │ 00 00 00 00 00 00 00 00 ECECLKД
0000000050: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
I.e. XX XX XX EA bytes (it is a BL command opcode) followed with garbage (may be 00, may be FFs, may be other XX XX XX EA bytes), and "ECEC" string from offset 0x40 from the ROM start. "ECEC" is present at this offset in my device and several other. But this may be not in yours.
mamaich said:
Probably the problem is in wrong addresses to dump. You should modify my RomDump code so that it would check all 4Gb of adress space in 32-mb blocks to find a block that looks like a ROM start. Rom starts with someting like:
Code:
0000000000: FE 03 00 EA 00 00 00 00 │ 00 00 00 00 00 00 00 00 ъ
0000000010: FE 03 00 EA 00 00 00 00 │ 00 00 00 00 00 00 00 00 ъ
0000000020: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
0000000030: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
0000000040: 45 43 45 43 4C 4B 12 84 │ 00 00 00 00 00 00 00 00 ECECLKД
0000000050: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00
I.e. XX XX XX EA bytes (it is a BL command opcode) followed with garbage (may be 00, may be FFs, may be other XX XX XX EA bytes), and "ECEC" string from offset 0x40 from the ROM start. "ECEC" is present at this offset in my device and several other. But this may be not in yours.
Click to expand...
Click to collapse
I met this problem also. In my case, the BIN code of the ROM file that I ROMDumped from my device is looked like this
and the result of "dumprom.exe dump.bin -4 -d d:\111" is shown as following.
How can I solve this problem?
Thanks a lot.
Does anyone know what is the address for changing BA pagepool size on WM6?
Thanks in advance.
adrress:0x2565D3
00 00 00 00 =0M
00 00 80 00 =8M
00 00 C0 00 =12M
00 00 00 01 =16M
00 00 80 01 =24M
00 00 00 02 =32M
00 00 00 03 =48M
adotan said:
adrress:0x2565D3
00 00 00 00 =0M
00 00 80 00 =8M
00 00 C0 00 =12M
00 00 00 01 =16M
00 00 80 01 =24M
00 00 00 02 =32M
00 00 00 03 =48M
Click to expand...
Click to collapse
Thanks for the answer. But I don't think this is a correct address. Look at the attached image. Address pattern is now where close to what you have mentioned in your replay.
what does the pagepool do exactly? Increasing the pagepool would do what?
Try 2555d2
That's indeed the correct one... I've done so, changed this one from 16 to 32 mb's but must honestly say tat I don't find it be different that much...
Has anybody found the HTC official 6.0 rom so that i can downgrade my "Upgraded 6.1 " touch cruise?
basdaniel said:
Has anybody found the HTC official 6.0 rom so that i can downgrade my "Upgraded 6.1 " touch cruise?
Click to expand...
Click to collapse
The 6.1 upgrade sucks!... My headsets arnt working and everything else is working slower.....
Maybe here
basdaniel said:
Has anybody found the HTC official 6.0 rom so that i can downgrade my "Upgraded 6.1 " touch cruise?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=381600
need this rom
45 4C 46 30 31 30 30 35 30 00 00 00 00 00 00 00 ELF010050.......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
44 4F 50 4F 44 30 30 31 00 00 00 00 00 00 00 00 DOPOD001........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..............
need this rom please help
Good evening again peoples,
Last thing I'm sorting out on the phone after the rom upgrade it the camera. just spent the last two hours sorting out all the file names and order of my images and put them on the phone again.
However the camera's counter is set to 1. I found a tweak on the Polaris forum
schaggo said:
Ok guys, I got a tricky one: how to set the camera image counter to a custom value?
Everytime I hardreset my Polaris the damn application starts counting up from IMG0001.JPG again... HTF can I manually set that to the latest picture taken?
Edit: Was a tricky one but I solved it myself. Under [HKEY_CURRENT_USER\Software\HTC\Camera\5.04\Preferences] you'll find an entry VALUES. Change bit 0068 to the desired value in hex. Example: Mine was 06 and resulted in IMG0006.JPG, I now changed to 74 which equals 116 in hex, my next pic will be named IMG0116.JPG
Got it?
Click to expand...
Click to collapse
But there isn't 5.04 folder on my Nike. Is there anyone that could tell me what to do?!
I've managed to sort out the registry so that the phone saves to Storagecard/mydoc~/mypictures. And also has a prefix of Image_ I just need help with this one last thing!
Thanks in advance!
nowimboard said:
But there isn't 5.04 folder on my Nike.
Click to expand...
Click to collapse
The key will match the camera version in your ROM - for example, I've got a key 5.06. Just look inside whatever key you have.
Thanks!
I cant believe how dim I was! I know that I'm just starting out with flashing roms and editing registries.. but I had a "blonde" moment
"HKEY_CURRENT_USER" isn't listing on my phone, but HKCU is...
Thanks!!!!!
EDIT: Anyone know what the correct HEX for 402 is? On line calculators are telling me 192 however the phone is telling me that "192" isn't a valid string! Isn't it supposed to have letters in?
nowimboard said:
Thanks!
I cant believe how dim I was! I know that I'm just starting out with flashing roms and editing registries.. but I had a "blonde" moment
"HKEY_CURRENT_USER" isn't listing on my phone, but HKCU is...
Thanks!!!!!
EDIT: Anyone know what the correct HEX for 402 is? On line calculators are telling me 192 however the phone is telling me that "192" isn't a valid string! Isn't it supposed to have letters in?
Click to expand...
Click to collapse
I haven't looked at it but I would guess that the reg key is divided up into 2 character bits each of which will go up to a maximum of FF (255 in decimal).
So, yes 192 is hex for 402 but you can't set one bit that high.
Just what I expect to be the case.
randomelements said:
I haven't looked at it but I would guess that the reg key is divided up into 2 character bits each of which will go up to a maximum of FF (255 in decimal).
So, yes 192 is hex for 402 but you can't set one bit that high.
Just what I expect to be the case.
Click to expand...
Click to collapse
Thank you for your help RandomE,
I'll think I'll PM schaggo to see if he can offer any suggestions.
So do you think that you would split up the 192 Hex code to "FF" & "93"?
whoa guys, somebody actually called for my help, yay!
ok, I reflashed my polaris with the Syrius-ROM and didnt look at this issue any longer. I never got over like pic 200 or so, so it never really was an issue to me. But good question, what about numbers higher than 255...?
I'll recheck the registry values and see what I find out. It could very well be that itll turn FF00, ff01, ff02 and so on...
Ok, found out how it works:
Bit 68 is the pic number in hex. Once it reaches 255 eg FF, bit 69 turns one up. So bit 68 is the running number while bit 69 is the index for bit 68. Example:
Code:
Pic 68 69
220 DC 00
221 DD 00
223 DE 00
...
254 FE 00
255 FF 00
256 00 01 <--!
257 01 01
258 02 01
...
510 FF 01 (510 = 255+255 = FF+FF)
511 00 02
...
schaggo said:
Ok, found out how it works:
Bit 68 is the pic number in hex. Once it reaches 255 eg FF, bit 69 turns one up. So bit 68 is the running number while bit 69 is the index for bit 68. Example:
Code:
Pic 68 69
220 DC 00
221 DD 00
223 DE 00
...
254 FE 00
255 FF 00
256 00 01 <--!
257 01 01
258 02 01
...
510 FF 01 (510 = 255+255 = FF+FF)
511 00 02
...
Click to expand...
Click to collapse
You Genius!
So my reg value was:
00 00 00 00 05 00 00 00
05 00 00 00 05 00 00 00
03 00 00 00 03 00 00 00
03 00 00 00 01 00 00 00
03 00 00 00 05 00 00 00
03 00 00 00 03 00 00 00
03 00 00 00 01 00 00 00
03 00 00 00 00 00 00 00
03 00 00 00 03 00 00 00
03 00 00 00 00 00 00 00
90 01 00 00 40 1F 00 00
02 10 00 5A 01 02 01 01
11 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00
01 00 00 00 00 00 00 00
00 02 00 02 09 11 20 00
45 46 00 00 28 00 00 00
05 20 00 00 01 00 00 00
00 00 00 00 C0 27 09 00
01 00 00 00 00 00 00 00
And for the image value to be 415 to get the Hex values I did 415-225=190 which is BE in HEX so I did this:
00 00 00 00 05 00 00 00
05 00 00 00 05 00 00 00
03 00 00 00 03 00 00 00
03 00 00 00 01 00 00 00
03 00 00 00 05 00 00 00
03 00 00 00 03 00 00 00
03 00 00 00 01 00 00 00
03 00 00 00 00 00 00 00
03 00 00 00 03 00 00 00
03 00 00 00 00 00 00 00
90 01 00 00 40 1F 00 00
02 10 00 5A 01 02 01 01
BE 01 00 00 01 00 00 00
01 00 00 00 01 00 00 00
01 00 00 00 00 00 00 00
00 02 00 02 09 11 20 00
45 46 00 00 28 00 00 00
05 20 00 00 01 00 00 00
00 00 00 00 C0 27 09 00
01 00 00 00 00 00 00 00
!!! YAY !!!
EDIT: I set the vale to BD as when the valve was BE the picture came out as 416.
Thank you so much!!!
Damit, judging by the time of posts, it took me half an hour to find something that simple out AAAARRRGH...!
Have fun guys
Hope it helps some others as well...!
schaggo said:
Damit, judging by the time of posts, it took me half an hour to find something that simple out AAAARRRGH...!
Have fun guys
Hope it helps some others as well...!
Click to expand...
Click to collapse
Thank you again!
Help Please!
I have very little knowledge of hex. I was hoping someone here could give me a hand with changing my counter to 92.
Here is my hex for [HKEY_CURRENT_USER\Software\HTC\Camera\5.04\Preferences\Values] as i see it in phm regedit.
00 00 00 00 05 00 00 00 05 00 00
00 05 00 00 00 03 00 00 00 03 00
00 00 03 00 00 00 01 00 00 00 03
00 00 00 05 00 00 00 03 00 00 00
03 00 00 00 03 00 00 00 01 00 00
00 03 00 00 00 00 00 00 00 03 00
00 00 03 00 00 00 03 00 00 00 00
00 00 00 03 00 00 00 90 01 00 00
90 01 00 00 40 1F 00 00 02 10 00
55 04 02 01 01 3C 00 00 00 01 00
00 00 01 00 00 00 01 00 00 00 01
00 00 00 00 00 00 00 00 02 00 02
49 11 20 00 05 46 00 00 28 00 00
00 07 00 00 00 01 00 00 00 01 00
00 00 C0 27 09 00 01 00 00 00 00
00 00 00 01 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 00 00
00 00 00 00 00
Advance THANKS
With my Touch Pro2 I found out that byte 109 and 110 are the right ones for this solution.
thanks for this tip !
Hi! Searching my old hard disk I have found something interesting, have no idea where I got it, but seems its something related to sim (un)locking on xperia. Hope somebody find it interesting.
Looking further after some work on some trim area units trying to identify some new units I have found something interesting.
abyte0 array:
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 00 00 08 B3 00 00 00 04 A0 00 00 00 00 00 08 FD ...³....*......ý
00000010 00 00 00 10 00 00 08 00 05 00 00 00 0E 00 00 00 ................
00000020 08 00 00 00 00 00 09 61 00 00 00 04 FE FF FF FF .......a....þÿÿÿ
00000030 00 00 08 B3 00 00 00 04 AA 00 00 00 ...³....ª...
Array contain 4 trim area units which is writen using function tawrite:
Code:
--unit------size-------data------
000008B3 0004 A0 00 00 00
000008FD 0010 00 00 08 00 05 00 00 00 0E 00 00 00 08 00 00 00
00000961 0004 FE FF FF FF
000008B3 0004 AA 00 00 00
looking forward to my z1c trim area dump and searching for those 3 units I found only one unit with excatly the same size of 4 bytes:
000008B3 0004 50 00 00 00
I realy have no idea how it working and whats is consequence writing that to trim area but you must agree those 3 units is definitelly realted to sim (un)locking? Unit 0x8b3 is probably start-stop-idle sequence? Since my z1c was not sim locked probably 2 units is missing because of that. Or vice versa, if all 3 units exist device is sim locked? Somebody with sim lock please look and tell me here! I realy have no idea where I found tawrite.zip, tried google search no results.
Two files simlock.ta-1.6 and simlock.ta-2.1 is probably generated by readReply function?
@munjeni
Going through the ABL on the XZ1c, I've found that 0x7DA is, in fact the simlock unit.
Unfortunately, it looks like 0x851 is a simlock signature.
It appears that the simlock unit gets an SHA256 digest computed which is compared against the signature in 0x851.
You'll see the beginnings of it in j4nn's ABL PE file at loc_331CC.
It also looks like, immediately after reading 0x851, the code path grabs the IMEI.
Then it gets what it calls the "asahi signature", then starts calculating and validating digests up the certificate chain.