Database Users

extract from raw rom image?

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.

[Solved] Unbricking: can't flash stock & can't get into recovery

EDIT:
Solved by flashing .tot from a Windows that is NOT a Virtual Machine.
---------------------------------------------------------------------------------------------
I need some help. I bricked my phone but this time I am unable to unbrick it.
I recently got a new F320L. I flashed it with CloudyG2 3.3 and it was working fine for a day, but I decided I don’t like lollipop so I wanted to downgrade to CloudyG2 2.2 KitKat.
Here’s what I did:
1.Installed and run AutoRec f320L apk. I figured that since this is KitKat recovery installer, it will downgrade the bootstack. By omission, I did not flash KitKat baseband linked the Cloudy 2.2 installation guide (which might be the cause of all this).
2.Rebooted into TWRP recovery, wiped System, Cache, Dalvik, Data.
3.Installed Cloudy 2.2
4.Rebooted.
Now, the phone gets stuck on the LG logo and does not go past it even when I leave it for an hour.
What I tried to do:
1.Return to stock with KDZ method (tried both KitKat and L KDZ files).
Result: Error at the beginning of flashing telling me to unplug the phone and plug it back again.
2.Return to stock with .TOT method.
Result: Error at the beginning of flashing.
Code:
[10:52: 1] CrossDL [] to [F320L]. SWversion[][10:52: 1] ¡Ú¡Ú ERROR REASON : LAF_ERROR_INVALID_INPUT_FILE
[10:52: 1] CComPort::ClosePort, Closed Port Successfully for COM 41
[10:52: 1] CBasicComControl::Close, the port(COM41) is closed successfully
[10:52: 1] [10:52: 1] CrossDL [] to [F320L]. SWversion[]
[10:52: 1] DoDownload() Exception
For some reason my phone lost its model name...?
2b. Hex-editing .tot file to replace “F320L” with zeros to get around the above error (but I don’t know if it would help at all with flashing higher stock roms because it would probably not restore the model name if I blanked it, would it?).
Result: at 6% process stops and I get this error:
Code:
[10:56:21] InitDiag is success.
[10:56:21] InitializeProcess() is success.
[10:56:21] CComPort::ClosePort, Closed Port Successfully for COM 41
[10:56:21] CBasicComControl::Close, the port(COM41) is closed successfully
[10:56:21] Start Download
[10:56:21] Port is already closed
[10:56:21] Port Open 41
[10:56:21] [T000032] 48 45 4C 4F 01 00 00 01 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 4C 3F 00 00 B7 BA B3 B0 HELO....................L?......
[10:56:22] RX Timeout : 1000 seconds
[10:56:22] LAF_Packet Error, Error reason is 0
[10:56:22] We can't communicate with Phone[HELO_Packet]
[10:56:22] Port Close
[10:56:22] Port Open 41
[10:56:22] Retry download 1 time(s)
[10:56:22] [T000032] 48 45 4C 4F 01 00 00 01 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 4C 3F 00 00 B7 BA B3 B0 HELO....................L?......
[10:56:23] RX Timeout : 1000 seconds
[10:56:23] LAF_Packet Error, Error reason is 0
[10:56:23] We can't communicate with Phone[HELO_Packet]
[10:56:23] Port Close
[10:56:23] Port Open 41
[10:56:23] Retry download 2 time(s)
[10:56:23] [T000032] 48 45 4C 4F 01 00 00 01 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 4C 3F 00 00 B7 BA B3 B0 HELO....................L?......
[10:56:24] RX Timeout : 1000 seconds
[10:56:24] LAF_Packet Error, Error reason is 0
[10:56:24] We can't communicate with Phone[HELO_Packet]
[10:56:27] [T000038] 45 58 45 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 00 00 00 F0 35 00 00 BA A7 BA BC EXEC.....................5......
64 6D 65 73 67 00 dmesg.
[10:56:57] RX Timeout : 30000 seconds
[10:56:57] LAF_Packet Error, Error reason is 0
[10:56:57] We can't communicate with Phone[EXEC_Packet]
[10:56:57] Port Close
[10:56:57] RefurbishProcess() Error.
[10:56:57] ¡Ú¡Ú ERROR REASON : LAF_ERROR_PACKET_TIMEOUT
[10:56:57] CBasicComControl::IsConnected, the port(COM41) connection is not detected
[10:56:57] RunProcess() is fail.
[10:56:57] CBasicComControl::IsConnected, the port(COM41) connection is not detected
[10:56:57] [10:56:57] We can't communicate with Phone[EXEC_Packet]
[10:56:57] DoDownload() Exception
Special notes:
My phone does not enter into Recovery mode when pressing Power+Vol Down, releasing on LG logo and pressing them again. It Never DID! I tried many times, when the phone was working fine on KitKat, JB and L stock roms, or on CloudyG2 3.3. And it doesn't work now.
This button combination never did anything. The phone powers on, the LG logo shows up, I release the buttons and press them again, the LG logo keeps showing up for some more seconds and the phone shutdown due to prolonged pressing of Power button.
So as far as I can tell, Download mode is all I have at the moment.
Is there anything left to try?

[Qualcomm] Subsystem Interface Control

I'm looking for any information on the DMSS subsystem commands. I have a list of subsystem ids but none of the commands that correspond. My goal is to figure out how the Wireless Messaging Service (WMS) subsystem works. DCN 80-V1294-6 contains the information on building the payload packet but I can't find it anywhere. QXDM doesn't have any SMS controls as far as I know, so I can't spy on its communications. If anyone knows how to construct the proper packet request, I'd be very grateful.
Thanks

Doing some testing with the information I have, came up with the following responses. I spied on the Call Manager subsystem command and figured the structure would be similar to the rest of the subsystem payload markup.
STRUCTURE
Code:
4b 0e 01 ZEROED BUFFER df 80 7e
4b is DM command for subsystem
0e is subsystem id for Wireless Messaging System
Next is a sequence of 1 - 8 that I've sent. Anything after 8 results in response code of 13 which is an invalid command.
Zeroed buffer length of 258
The usual CRC high low
7e terminator
RESPONSES
Code:
4b 0e 01 00 bf 23 7e
4b 0e 02 00 d7 09 7e
4b 0e 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 74 44 7e
4b 0e 04 00 00 00 00 00 63 d7 7e
4b 0e 05 00 df 44 7e
4b 0e 06 00 00 00 00 00 35df7e
4b 0e 07 00 6f 77 7e
4b 0e 08 00 a7 f4 7e
Looks like subsys commands of 3, 4, and 6 are interesting. Need to figure out what else to pass in the payload.

Quick question --> How did you spy on the Call Manager?

Root method (Brainstorm)

Hey everyone. This is not tested but I would like input. On the LG G3, I could flash partitions in fastboot mode which allowed me to change the device from an AS990 to a US990 or LS990. Would it be possible to flash the H918/H830 bin files through the patched LGUP partition DL to change the device type? Again just a brainstorm thread. Please post below.

Reserved
reserved

What could we gain from changing the device type? (Some have incompatible hardware if i'm right)
Also Aren't partitions checked by the bootloader( or kernel i dunno much) for any modification?
Sent from my LG-H860 using Tapatalk

abol_fa said:
What could we gain from changing the device type? (Some have incompatible hardware if i'm right)
Also Aren't partitions checked by the bootloader( or kernel i dunno much) for any modification?
Sent from my LG-H860 using Tapatalk
Click to expand...
Click to collapse
I'm not sure about the hardware but I think the RS998 might be close enough that a custom Rom would run

I'm interested in this. I have a us992 and it's the same hardware than rs998 but I can't root or unlock bootloader. It could be cool if there's a way to change it...

thjubeck said:
Hey everyone. This is not tested but I would like input. On the LG G3, I could flash partitions in fastboot mode which allowed me to change the device from an AS990 to a US990 or LS990. Would it be possible to flash the H918/H830 bin files through the patched LGUP partition DL to change the device type? Again just a brainstorm thread. Please post below.
Click to expand...
Click to collapse
By attaching a debugger to LGUP I found a couple of new commands
INFOSPRO is called 4 times which by reading is setting some sort of properties
SIGN
SIGN is called twice before anything begins to work such as the OPEN or WRTE command and the response should be something like success cmd SIGN
I think this is the missing link as after this all commands are given with 2 kilocent commands then 2 kilometr commands in that order so possibly the SIGN command is important but also the fact that the kilocent command is given twice then the 2 kilometr responses are sent but that's just speculation. Let me know what you guys think
also two other commands that were found are
OPCMCHEK
MISCWRTE
EDIT: I think CHCKCLER is our missing link. Disclaimer I am on the LG G5 but it has the same issue. Also the INFOSPRO may also need to be set [/B]
.
.
Debugged application message: [00:22:968] [T0002856] 49 4E 46 4F 47 50 52 4F 00 00 00 00 00 00 00 00 00 00 00 00 08 0B 00 00 43 D0 00 00 B6 B1 B9 B0 INFOGPRO................C.......
.
Debugged application message: [00:23:062] [R0000032] 49 4E 46 4F 47 50 52 4F 00 00 00 00 00 00 00 00 00 00 00 00 08 0B 00 00 00 00 00 00 B6 B1 B9 B0 INFOGPRO........................
.
Debugged application message: [00:23:062] [T0002856] 49 4E 46 4F 53 50 52 4F 00 00 00 00 00 00 00 00 00 00 00 00 08 0B 00 00 32 CF 00 00 B6 B1 B9 B0 INFOSPRO................2.......
.
Debugged application message: [00:23:187] [R0000032] 49 4E 46 4F 53 50 52 4F 00 00 00 00 00 00 00 00 00 00 00 00 08 0B 00 00 00 00 00 00 B6 B1 B9 B0 INFOSPRO........................
.
Debugged application message: [00:23:187] usb speed is high speed.
.
Debugged application message: [00:23:187] Not Support Fail Safe
.
Debugged application message: [00:23:187] Progress sleep for 1000 9 11
.
Debugged application message: [00:23:203] Set Progress 9
.
Debugged application message: [00:23:703] Set Progress 10
.
Debugged application message: [00:24:203] [T0000032] 43 48 43 4B 43 4C 45 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8C BA 00 00 BC B7 BC B4 CHCKCLER........................
.
Debugged application message: [00:24:203] [R0000032] 43 48 43 4B 43 4C 45 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 BC B7 BC B4 CHCKCLER........................
.
Debugged application message: [00:24:203] LAF_CMD_SUB_CLER.
.
Debugged application message: [00:24:203] DATA CHECK SUM ERROR device = 0 tool = 0
.
Debugged application message: [00:24:203] ==============Start Direct Download 2485MB ==============
.
Debugged application message: [00:24:218] umount system (/system)
.
Debugged application message: [00:24:218] [T0000032] 4B 49 4C 4F 43 45 4E 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E3 7B 00 00 B4 B6 B3 B0 KILOCENT.................{......
.
Debugged application message: [00:24:218] [R0000032] 4B 49 4C 4F 43 45 4E 54 90 A9 25 4A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B4 B6 B3 B0 KILOCENT..%J....................
.
Debugged application message: [00:24:218] [T0000048] 4B 49 4C 4F 4D 45 54 52 00 00 00 00 02 00 00 00 00 00 00 00 10 00 00 00 A3 07 00 00 B4 B6 B3 B0 KILOMETR........................
F4 7C 31 45 4C FF 58 73 0A D6 CB 7D 23 7B F0 17 .|1EL.Xs...}#{..
.
Debugged application message: [00:24:218] [R0000032] 4B 49 4C 4F 4D 45 54 52 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B4 B6 B3 B0 KILOMETR........................
.
Debugged application message: [00:24:218] [T0000047] 45 58 45 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F 00 00 00 57 EC 00 00 BA A7 BA BC EXEC....................W.......
75 6D 6F 75 6E 74 20 2F 73 79 73 74 65 6D 00 umount./system.
.
Debugged application message: [00:24:234] [R0000032] 45 58 45 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F 00 00 00 00 00 00 00 BA A7 BA BC EXEC............................
.
Debugged application message: [00:24:234] [T0000032] 4B 49 4C 4F 43 45 4E 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E3 7B 00 00 B4 B6 B3 B0 KILOCENT.................{......
.
Debugged application message: [00:24:234] [R0000032] 4B 49 4C 4F 43 45 4E 54 CA DB 0F 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B4 B6 B3 B0 KILOCENT...!....................
.
Debugged application message: [00:24:234] [T0000048] 4B 49 4C 4F 4D 45 54 52 00 00 00 00 02 00 00 00 00 00 00 00 10 00 00 00 6D 6D 00 00 B4 B6 B3 B0 KILOMETR................mm......
CB 74 3A 1A 43 2F 7D F9 DF 11 42 DC 7E 09 0A 8C .t:.C/}...B.....
.
Debugged application message: [00:24:234] [R0000032] 4B 49 4C 4F 4D 45 54 52 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B4 B6 B3 B0 KILOMETR........................
.
Debugged application message: [00:24:234] [T0000060] 45 58 45 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1C 00 00 00 17 2E 00 00 BA A7 BA BC EXEC............................
6D 6F 75 6E 74 20 2D 6F 20 72 65 6D 6F 75 6E 74 2C 72 6F 20 2F 73 79 73 74 65 6D 00 mount.-o.remount,ro./system.
.
Debugged application message: [00:24:234] [R0000032] 45 58 45 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 23 00 00 00 00 00 00 00 BA A7 BA BC EXEC................#...........
.
Debugged application message: [00:24:234] /system Unmount Success.
.
Debugged application message: [00:24:234] Erase Partition name : system, sector addr : 0xE886, size(sector count) : 0x120000

thjubeck said:
....
Click to expand...
Click to collapse
It's nice that you're looking into this, there is another guy in the V20 section, @runningnak3d who is also looking into making partition dl work.
BUT.... don't try to flash T-Mobile bootloader on any other variant phone. You will hard brick. T-Mobile uses a different key to sign it's files, and that key is programmed into the read-only-memory of a TMO phone.
Edit: Besides, he is looking into a different way of unlocking, by flashing a modified persistent partition with LGUP I believe.

askermk2000 said:
BUT.... don't try to flash T-Mobile bootloader on any other variant phone. You will hard brick. T-Mobile uses a different key to sign it's files, and that key is programmed into the read-only-memory of a TMO phone.
Click to expand...
Click to collapse
Don't worry I'm not an idiot I did my research like the thread says Brainstorm. Sometimes crazy ideas lead people to start thinking. Which reminds me.... Ooo look Squirrel. Be sure to post your ha's when you read that. Anyways in all seriousness checking with the other persons and who knows possibly sometime may have a solution.

thjubeck said:
Don't worry I'm not an idiot I did my research like the thread says Brainstorm. Sometimes crazy ideas lead people to start thinking. Which reminds me.... Ooo look Squirrel. Be sure to post your ha's when you read that. Anyways in all seriousness checking with the other persons and who knows possibly sometime may have a solution.
Click to expand...
Click to collapse
I see. So you where offended, and you're subtly calling me an idiot.
You must be a proud person.
And you couldn't have "done your research" at the time of posting, as why then would you ask about flashing TMO bootloader on a non-TMO device?
Would it be possible to flash the H918/H830 bin files through the patched LGUP partition DL to change the device type?
Click to expand...
Click to collapse
Also your reply reeks of utter nonsense.

askermk2000 said:
I see. So you where offended, and you're subtly calling me an idiot.
You must be a proud person.
And you couldn't have "done your research" at the time of posting, as why then would you ask about flashing TMO bootloader on a non-TMO device?
Also your reply reeks of utter nonsense.
Click to expand...
Click to collapse
Seriously man no harm intended and as for utter nonsense yes,yes it was.....partially. Also, like how you quoted me saying bootloader... wait you didn't. Missed that somewhere. Not necessarily pointing to that you could flash a system partition that was already rooted or something like that again emphasizing brainstorm thread here.

thjubeck said:
Seriously man no harm intended and as for utter nonsense yes,yes it was.....partially. Also, like how you quoted me saying bootloader... wait you didn't. Missed that somewhere. Not necessarily pointing to that you could flash a system partition that was already rooted or something like that again emphasizing brainstorm thread here.
Click to expand...
Click to collapse
Well how else would you change your "device type"?
Maybe I don't understand what you mean by that. I may have jumped to wrong conclusion, if so then I guess you where right to be slightly offended.
Anyway, persistent.bin seems to be where it's at. You should work with @runningnak3d he was looking earlier for some help.

SIMLOCK_S1

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.