Database Info

Extended ROM customization

Hi,
I'm trying to customize my extended rom before applying it to my Magician. I've downloaded latest WWE rom from FTP site, and extracted all files to a temp folder. I then used xda3nbftool -t -x ms_.nbf to decrypt the ExtRom file. After that, i used a HEX editor to cut the first 128 bytes and generate a "main" part to try and open it in Winimage, but so far without sucess (I'm using ITSME procedure).
Can someone help me trying to find out what i'm doing wrong?
Many thanks.

megalore said:
Hi,
I then used xda3nbftool -t -x ms_.nbf to decrypt the ExtRom file.
Can someone help me trying to find out what i'm doing wrong?
Click to expand...
Click to collapse
The most recent versions of the updates are in a different format:
check here...

Ok, thanks.
I've tried with the perl script you mentioned, but i can't seem to get a readable file on winimage. I used the following command line:
decode.pl ms_.nbf -f 0xEBFE904D
However, the header (.hdr) is perfectly readable in hexedit, so i assume the "encryption" key is correct.
Am i doing something wrong? :roll:

megalore said:
Ok, thanks.
However, the header (.hdr) is perfectly readable in hexedit, so i assume the "encryption" key is correct.
Click to expand...
Click to collapse
That's because the header is not XOR "encrypted".
Try with: decode.pl ms_.nbf -f 0x4D90FEEB

not a developer
hi, i am not a developer and i got to the point where i have the decode.pl from the link in wiki.xda-developers.com... i dont know if that is correct so far, but i dont know how to get this a) from my computer onto the phone and b) if i can then change the windows language from german to english!?

Hi iDG,
Thanks for your reply. I've tried with the key you sent, but still can't mount the FAT16 part in WinImage.
Where do you get those keys? Are they extracted from the encoded file, and from what position?
Thanks.

megalore said:
Hi iDG,
Thanks for your reply. I've tried with the key you sent, but still can't mount the FAT16 part in WinImage. Where do you get those keys? Are they extracted from the encoded file, and from what position?
Click to expand...
Click to collapse
The "key" is the first dword of the unencrypted file. It can be obtained from a SD dump. The value seem to be constant (I've tried several versions).
Can you tell me what version are you trying to decode, so I can do the same here to see what happens?

I'm using WWE_11200_550_11200 from shipped_ROMS on XDA ftp site.

megalore said:
I'm using WWE_11200_550_11200 from shipped_ROMS on XDA ftp site.
Click to expand...
Click to collapse
Works fine here. That's the hexdump of the beginning of the DECODED file:
Code:
00000000 eb fe 90 4d 53 57 49 4e 34 2e 31 00 02 04 01 00 |...MSWIN4.1.....|
00000010 01 00 02 00 98 f8 26 00 26 00 01 00 00 00 00 00 |......&.&.......|
00000020 00 00 00 00 80 00 29 2d 00 f1 07 20 20 20 20 20 |......)-... |
00000030 20 20 20 20 20 20 46 41 54 31 36 20 20 20 00 00 | FAT16 ..|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 |................|
000001c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 f8 ff ff ff 03 00 04 00 05 00 06 00 07 00 08 00 |................|
00000210 ff ff 0a 00 0b 00 ff ff 0d 00 0e 00 ff ff ff ff |................|
00000220 11 00 12 00 13 00 14 00 15 00 16 00 17 00 18 00 |................|
00000230 19 00 1a 00 1b 00 1c 00 1d 00 1e 00 1f 00 20 00 |.............. .|
00000240 21 00 22 00 23 00 24 00 25 00 26 00 27 00 28 00 |!.".#.$.%.&.'.(.|
00000250 29 00 2a 00 2b 00 2c 00 2d 00 2e 00 2f 00 30 00 |).*.+.,.-.../.0.|
00000260 31 00 32 00 33 00 34 00 35 00 36 00 37 00 38 00 |1.2.3.4.5.6.7.8.|
00000270 39 00 3a 00 3b 00 3c 00 3d 00 3e 00 3f 00 40 00 |9.:.;.<.=.>[email protected]|
00000280 41 00 42 00 43 00 44 00 45 00 46 00 47 00 48 00 |A.B.C.D.E.F.G.H.|
00000290 49 00 4a 00 4b 00 4c 00 4d 00 4e 00 4f 00 50 00 |I.J.K.L.M.N.O.P.|
Check with the results on your side, to see if there's something wrong with the perl script...

Yes, thats what i get too. But WinImage shows no files inside it. I don't think its WinImage problem, because if i use alpine_ext_rom_tool (yes, it works!) from the Alpine forum, i get a similar decoded file which opens right on WinImage. If only the encoding part worked fine...

megalore said:
Yes, thats what i get too. But WinImage shows no files inside it. I don't think its WinImage problem, because if i use alpine_ext_rom_tool (yes, it works!) from the Alpine forum, i get a similar decoded file which opens right on WinImage. If only the encoding part worked fine...
Click to expand...
Click to collapse
I've checked all the fields in the boot sector and everything matches corretcly. The decoded file is a prefectly valid FAT16 volume. The only quirck I can find is that the boot sector declares the disk to be 0x9800 blocks long whereas the file is actually 0xa000 blocks long.
The space for the Ext_ROM in the flash is really 0x9800 blocks long
You could try to cut the file to be 0x1300000 bytes long to see if winimage likes it.

megalore,
if you know the checksum generation for the magician ext_roms then I'd be quite happy to generate a tool similar to the alpine tool - most of the code will be the same.
Although I thought the magician ext roms could be decoded/encoded using itsme's tool?
Bal

Guys,
if it's anything like the alpine ext roms, then the last part consists of two splash screens (nb format).
hope that helps

The Ext_ROM image on the magician only contains the actual FAT16 filesystem. The boot splash image is in a separate space in the flash.
The only tool I know of is the xda3nbf which does not work with the newer (base64-like) rom headers.
The checksum algorithm is, as far as I can tell, unknown.

HI IDG,
hmmmm, that's interesting - maybe I'm confused .... but
If you take the ms_.nbf file from MA_DT_WWE_DutchRetail_11200_550_11200_Ship.exe and extract the header and fat16 image (well what I think is the fat16 part).
The I end up with an fat16 image of size 20,709,376bytes. If from this I extract 0x1300000 - 0x137FFFF and 0x1380000 - 0x13BFFFF and load these into nb_image_converter_859_418.exe as nb files ....
The first is a blank white image and the second is a "Qtek Keep the world in one" cityscape ....
Perhaps the tool you guys use to extract the fat16 image drops this part?

bal666 said:
hmmmm, that's interesting - maybe I'm confused .... but
If you take the ms_.nbf file from MA_DT_WWE_DutchRetail_11200_550_11200_Ship.exe and extract the header and fat16 image (well what I think is the fat16 part).
The I end up with an fat16 image of size 20,709,376bytes. If from this I extract 0x1300000 - 0x137FFFF and 0x1380000 - 0x13BFFFF and load these into nb_image_converter_859_418.exe as nb files ....
Click to expand...
Click to collapse
Yep You're right!
I've never noticed that but the same thing happens for every ms_.nba I have. When I first examined the fat16 part, I did notice the extra data, but being 0xff the content of an erased flash memory, I didn't bother to check further. This makes sense, because the bootsplash image is in fact right after the Ext_ROM, inside the flash.
I've never removed the "excess" data from the ms_.nba because MacOSX does not seem to care. Maybe WinImage does.

Magician ext rom tool
Hi iDG,
yeah weird isn't it? I've just recently noticed it myself - so will start extracting it out separately.
Anyway, Megalore ...
I've attached a tool for the magician similar to the alpine version which allows you to decode and encode extended roms.
It's a bit of a hack at the moment - you'll find some of the message still talk about the alpine, but the mechanics should be fine (I should have a disclaimer about how it could destroy your machine here ... but I'm sure you've already considered that!!!).
For instructions on usage, see the alpine post http://forum.xda-developers.com/viewtopic.php?t=31106&sid=e011e42bce14ded5bf594c1c0484b1bc
Have fun!
PS This retains the splash screens, but "Extra Drive Creator Pro" ignores them ... not sure about winimage - but I'll add that functionality if you have problems.

Thanks bal666!!
Don't worry about the disclaimer, i think we all know the risks, otherwise we wouldn't be here in this forum...
I'll give it a try as soon as i can, and let you know how it turn out.

Thanks guys!
It worked flawlessly. I can now customize my Magician ExtROM without any hassles.
Great Work!!!

Hi Megalore,
that's good news! I'm glad it worked - I'll try to fix the "alpine" messages when I have a chance.
Have fun
Bal

Strange SD card problem in Bootloader (SOLVED)

This is wat I have done:
With romupdate I made a backup on 512MB SD Card
Put SD card away
Installed TMob rom, all ok.
Tmobile is too pink for me so I wanted to install my old rom
Put in SD card and immediatedly bootloader says SD card, update blabla and it worked.
----
Now I want to have that bigstorage. I ntrw'd the SDcard to a file, opened it with hexeditor, changed the 2 020008000 thingies, saved it and ntrw'd it back onto the SDcard.
Sow, when inserted in bootloader, it just sais
SERIAL
V1.02
When I remove the card very sometimes it THEN IMMEDIATELDY askes to install, but than sections=1 and read card is fail. Somtimes when removing and reinserting it sais ROM size not enough.
What should I do? I tried everything. Should I keep my old rom and forget the big storage?

I tried leaving the phone for 1 night in the bootloader, hoping next morning it would say SD update.
It left me with a drained battery (0%!) it wouldn't reset anymore until I plugged the device in te loader, I had it fully recharged. Strange.

Ok. I think this could be a problem.
My SD image looks like this (first somewhat 500 bytes
Code:
4d 41 47 49 43 49 41 4e 20 20 20 20 20 20 20 20 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 31 2e 30 32 20 20 20 20 20 20 20 20 20 20 20 20 25 8e f4 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9e 8a c5 37 53 41 30 30 d8 00 45 07 00 06 7d 77 57 00 3c 27 bf 22 e7 00 07 b4 2e 0b 19 96 d8 bb 88 ef c3 dd 49 c6 26 3a 50 e6 00 1c b8 2f 59 e0 27 ec 45 f2 af 00 00 f9 ab 7a ca 4e 5a 9d 0f b3 cc 00 00 00 00 9d a8 a3 51 99 3f 82 07 ba 4d 40 51 00 ff e9 5c 9a 8b 67 bb 3a b9 f5 09 a9 a3 d6 69 74 71 4f 17 46 a3 2e 4e ee 8e 61 e8 f3 b0 a5 cc cb d6 1c b5 59 d0 47 1a ea 9f 29 4f 84 2e cc b3 d0 b1 a5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 f0 48 cd 47 ab 32 f5 57 1e 36 1a 99 8c 93 4c 67 35 9d 60 d3 34 10 f3 99 a8 a4 ab 53 12 e1 c0 ec fe 35 bb 57 e6 44 7e 81 53 7f 85 84 45 f8 6b 1d d5 74 b0 60 19 c2 b9 aa 48 4c 18 d8 1e ec 0e b6 82 01 4e ba 67 c1 04 f3 f0 d1 16 3c d7 13 aa b5 0f bf e8 74 a8 b5 01 77 f4 11 70 dd e8 00 80 56 c4 d3 0e d9 f7 52 90 95 3c 53 56 29 0a 8b 10 48 54 43 53 41 30 30 34 30 30 30 30 30 33 46 43 30 30 30 30 30 43 46 34 38 45 32 35 fe 03 00 ea 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 45 43 45 43 34 ec 0d 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 56 4f 44 41 50 30 30
cant get the text copied, but when I encode it to a /nbf file, with good romdumps it shows the operator and things, now it shows garbage:
Code:
Good one:
deviceId=PM10A
cellOpName=T-MOB005
language=WWE
firmwareVersion=1.13.00
deviceModelName=Magician
address0=0
address1=0
address2=0
crc32=6448ae5b
File crc32: dd221a2f
Code:
My own:
deviceId=MAGICIAN
cellOpName=0000000000000000
language=1.02
firmwareVersion= %Ķ♀
deviceModelName=
address0=
address1=
address2=
crc32=
File crc32: 148cd320
Where dit it go wrong???
ntrw, romupdate.exe? It's a bit scrambled.

It wás the problem.
What I did:
FOrmat SD card
Get rom on SD card with romupdate
ntrw it to disk
used hexedit to remove the 400meg of zero's (512mb sdcard)
ran mksBigStoragerENG.exe from ftp site for patch it bigstorage and so,
format SD card again
ntrw new patched file to SD
put it in Magician, start bootloader, and in 10 sec SD UPDATE and off it goes, now 51%...
Wish me luck!

Yes, done it.
Now have Dutch Vodafone 1.12 ROM with 1.12 Radio, extended rom is on my harddisk and bigstorage.
If someone wants this ROM please let me know, have no fast connection but then I will upload it at night.

Thanks for your thoughtfulness but I believe ROM 1.12 with Radio 1.12 is already in the ftp. In fact, the latest ROM version is 1.13 with Radio 1.12, but there's a stand alone Radio 1.13.

Well I'm happy it worked this way. There were some people struggling to get the SD card to update, this should do the trick then. I tried everything else
And I had some problems with pushmanager + bluesoleil in 1.13 (no vodafone?) which I dont have now. Maybe it was not the 1.13 fault, but ey, what's the difference?

mission impossible - editing nk.exe

cross posting from universal upgrading ... can someone kill the other thread ?
can someone assist me in changing the nk.exe in a way that allows me to change the deviceid from PU10 to HERM100
i succeded in hexediting the hk.nba from PU10 to HERM with the confirmation that Getdevice data recognize it as HERM
http://wiki.xda-developers.com/index...=GetDeviceData
there are 2 places in the nk.nba where the device type is found
00007074h: 48 00 45 00 52 00 4D ; H.E.R.M
00316c74h: 48 00 45 00 52 00 4D ; H.E.R.M
i need to get H.E.R.M.1.0.0 instead (6 bytes to insert)
00007050h: 2C 00 25 00 64 00 2C 00 20 00 4E 00 61 00 6D 00 ; ,.%.d.,. .N.a.m.
00007060h: 65 00 20 00 69 00 73 00 20 00 25 00 73 00 0D 00 ; e. .i.s. .%.s...
00007070h: 0A 00 00 00 48 00 45 00 52 00 4D 00 00 00 00 00 ; ....H.E.R.M.....
00007080h: 4F 45 4D 47 65 74 43 50 4C 44 5F 47 50 49 4F 28 ; OEMGetCPLD_GPIO(
after dumping the rom including the boot XIP i found that the nk.exe contains this data.
the reason to do it is to "help" bbconnect to recognize it as a hermes
anyone can assist me ?

Hi,
Just a thought - wouldn't it be easier to patch BB Connect to recognise the PU10. I would have thought it tricky to "insert" any bytes, and for nk.exe to work, but to shorten a string in a file might work by either terminating the shorter string with a 00 null byte, leaving it's full length intact, or if it's got a preceeding length attribute, then simply amend that to the shorter value, i.e. from 7 to 4?
Cheers,
Steve.

Goldcard Example for G1

Hi,
I'm an Australian user of the Optus Dream / G1.
I've searched on here as well as Google in general to try and find an example of a goldcard. Whenever I make mine, windows *****es that it cannot read the device to load the dreaming file on. I just want to find out if i'm on the right track.
Ok, so here's the CID straight from terminal emulator:
Code:
0353445355303147801060c16d009198
and now, reversed with 00 at the start:
Code:
0091006dc16010804731305553445303
I load this into qmat and generate this goldcard:
Code:
6F E9 DB F4 62 CF 43 51 09 60 42 63 C6 5E 17 A8
39 68 F0 67 A8 40 85 41 4D BE 7D 74 2E 28 81 02
FB 98 90 61 C8 DD 02 A0 46 12 FF AB 02 F6 E9 0A
C3 37 09 00 7D 62 10 4C 3F 66 F2 F2 D5 D2 F8 0E
67 FD DC 18 4E D8 B3 49 74 AA 58 B9 06 9E 57 E8
79 A8 30 A7 E8 80 C5 81 8D FE BD B4 6E 68 C1 42
3B D8 D0 A1 08 0D 2B 96 97 30 4F 19 52 54 F9 4A
03 77 49 40 BD A2 50 8C 7F A6 32 32 92 ED AB F4
53 41 30 30 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 5F 00 9E 00 00 00 00 00 00
75 00 00 00 00 A5 7E 00 00 00 00 00 00 00 00 00
00 D8 2D 00 00 00 00 00 00 00 00 00 00 8F CD 07
42 00 00 00 00 00 00 00 00 00 00 00 00 82 00 00
00 00 00 00 00 00 00 00 00 00 00 00 52 28 7D 3C
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 FF FF FF FF FF FF FF FF 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(the goldcard is x180 long)
This is what the first x180 of my SD card looks like when it is freshly formatted to FAT32 and opened in hxD:
Code:
EB 58 90 4D 53 44 4F 53 35 2E 30 00 02 08 0C 11
02 00 00 00 00 F8 00 00 3F 00 FF 00 00 20 00 00
BB 06 1E 00 7A 07 00 00 00 00 00 00 02 00 00 00
01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00
80 00 29 C6 28 D5 F6 4E 4F 20 4E 41 4D 45 20 20
20 20 46 41 54 33 32 20 20 20 33 C9 8E D1 BC F4
7B 8E C1 8E D9 BD 00 7C 88 4E 02 8A 56 40 B4 41
BB AA 55 CD 13 72 10 81 FB 55 AA 75 0A F6 C1 01
74 05 FE 46 02 EB 2D 8A 56 40 B4 08 CD 13 73 05
B9 FF FF 8A F1 66 0F B6 C6 40 66 0F B6 D1 80 E2
3F F7 E2 86 CD C0 ED 06 41 66 0F B7 C9 66 F7 E1
66 89 46 F8 83 7E 16 00 75 38 83 7E 2A 00 77 32
66 8B 46 1C 66 83 C0 0C BB 00 80 B9 01 00 E8 2B
00 E9 2C 03 A0 FA 7D B4 7D 8B F0 AC 84 C0 74 17
3C FF 74 09 B4 0E BB 07 00 CD 10 EB EE A0 FB 7D
EB E5 A0 F9 7D EB E0 98 CD 16 CD 19 66 60 80 7E
02 00 0F 84 20 00 66 6A 00 66 50 06 53 66 68 10
00 01 00 B4 42 8A 56 40 8B F4 CD 13 66 58 66 58
66 58 66 58 EB 33 66 3B 46 F8 72 03 F9 EB 2A 66
33 D2 66 0F B7 4E 18 66 F7 F1 FE C2 8A CA 66 8B
D0 66 C1 EA 10 F7 76 1A 86 D6 8A 56 40 8A E8 C0
E4 06 0A CC B8 01 02 CD 13 66 61 0F 82 75 FF 81
C3 00 02 66 40 49 75 94 C3 42 4F 4F 54 4D 47 52
20 20 20 20 00 00 00 00 00 00 00 00 00 00 00 00
Now, various instructions (that I cannot link to being a new user) I have seen say to copy the first x170 of the goldcard to the sdcard. But the goldcard is x180 long???
Anyway, I've tried both (copying x180 and x170), and that doesn't work. I've tried adding replacing the first byte of the reversed CID with "00", and not replacing it, and neither work.
TL;DR: Does the above goldcard and unmodified SD card look like yours?

can't you just flash that nbh img from bootloader?
not sure how much different australian g1s from US. but I didn't use gold card in rooting my g1.

Did you try this?

xtenpeben said:
can't you just flash that nbh img from bootloader?
not sure how much different australian g1s from US. but I didn't use gold card in rooting my g1.
Click to expand...
Click to collapse
I tried that, but when I reboot and hold the camera button it comes up and says "Not allowed"
nk111 said:
Did you try this?
Click to expand...
Click to collapse
Yes I tried the online goldcard generator, same results on all fronts.
I have also tried different SD Cards, a 2gb Kingston and a 1gb sandisk

The best this is to use qmat to do the reverse string thingie.
I had done it a lot of times manually, but failed every time.
After using qmat I got it to work.

Hello,
I can not check your goldcard right now because I am on my phone, but I think this is not your problem. If windows complains about beeing not able to read the drive, you most likely copied your goldcard to the wrong part of the disk.
You have to overwrite the first 170 Byte of your sd Card. It is important that you do not choose the logical drive (say drive letter e: for example) but the actual physical drive with your sdcard (should not have a drive letter)
I just assume this is your problem. Maybe you could pos the first bytes of your selected drive and tell us what you did.
edit: ah you did post that. The first bytes should be a bunch of 0s. Check what I stated above and tell us if you still have problems.

Please try my software: http://www.mediafire.com/download.php?mzqdyrtmimj

I bet its wether a mistake in the transcription of the CID or you havent used the physical drive. If the sd card has to be formated, it wont work.

I just got mine to work. My problem was same as yours, my mistake was using "logical disk" instead of physical in HxD. I also switched my sd card to older 1gb that I formatted first in a camera (fat16) then formatted in vista to fat32 right before writing the 170 bytes (length: 180). Save after you copy paste the hex but dont close. put the DREAIMG.nhb on it first then close HxD, then "safely remove"
This worked for me but I struggled until I got here, made so many mistakes. Good Luck.

goldcard is really x180 long just
copy all 00 00 00 00 ... from x170 to x180 and save
thanks man you are the best

you have an extra 3 at the end in the reversed code.. lol

SamSung I9300 (S3 GSM) baseband analysis

I am not sure if this is the right place, mostly because I dont know how someone else would categorize this info. Mods exist for a reason, today that reason might be to move this to the correct place
According to google some is new info some is old.
I dumped /dev/block/mmcblk0p7 which appears to be the baseband firmware. It is not compressed or encrypted but rather appears to be a filesystem of some sort.
I have identified that they are using RTOS.com's threadX and traceX.
I identified a zip file which indicates the authors used IBM Rational ClearCase
I identified another zip file which is a process trace, attached here for convenience.
There is a file that appears to be a DES encrypted with mcrypt 2.2 (not compatible with 2.4). 56 bit key so it should not take terribly long to brute force. As I still do not have a firm grasp on the structure of the 32M disk dump I do not know where the key might be. I also do not have an idle system with sufficient capacity to deal with this in a timely fashion. Anyone got some FPGAs from the old bitcoin days?
There are probably some additional things I will eventually find. I have to go away for a few days so I wont be able to work on this until I return. I am going to look through threadX to see if that sheds light on the file format (they have a free demo download). The only other thing I can think of off the top of my head is that maybe the chip itself expects a specific filesystem.
Maybe this post will spur some people to start looking into it more (or publish what they have if they have looked into it).

I have done further digging.
Firmware header - first 512 bytes
Name ... about 0xD is the offset for that section ... about 0x15 is the size of that section
PSI - start at 0x1000 length 0xE000
EBL - start at 0xF000 length 0x019000
MAIN - start at 0x28000 length 0x9D7800
SECPAC - start at 0x9FF800 length 0x800
NV - starts at 0 length 200000 (its from /efs/nv_data.bin)
It becomes easy to see where the start and size offsets are in the header as well. This also tells me the chip is set to little endian mode (arm 11 based). There is still some data I do not know what it does.
I got a bunch of false positives from binwalk suggesting there is LZMA compressed data. None of it validated.
Baseband file XXELLA
Target File MD5 Checksum
ebl e68042d611aef558dc525009e03d2e50
main 99e7aa119c684b1b569dcc1ec867112a
nv_data.bin 5707f4f934b4ad2a4ee4a7530b92073d
psiram 7e3fe83c24c7e1a6b9110cd68e7564e6
secpac 91cb74b48e35f0f6d61f298d841af59a
MAIN is the only one that had anything at all.
gzip compressed data, was "config_spec.txt", from NTFS filesystem (NT), last modified: Fri Dec 21 21:02:29 2012
mcrypt 2.2 encrypted data, algorithm: DES, mode: CBC, keymode: MD5 hash
Zip archive data, at least v2.0 to extract, compressed size: 37806, uncompressed size: 200962, name: "trace.dec"
config_spec.txt just says "No ClearCase Config Spec available"
trace_dec.zip is attached above
the mcrypted file is being brute forced, slowly ... very slowly. 1 core on a busy system. I will likely abort it because it is not going to finish in a reasonable time.
512 bytes of the disk image
Code:
00000000 50 53 49 52 41 4d 00 00 00 00 00 00 00 10 00 00 |PSIRAM..........|
00000010 00 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 |................|
00000020 45 42 4c 00 00 00 00 00 00 00 00 00 00 f0 00 00 |EBL.............|
00000030 00 00 00 60 00 90 01 00 00 00 00 00 00 00 00 00 |...`............|
00000040 4d 41 49 4e 00 00 00 00 00 00 00 00 00 80 02 00 |MAIN............|
00000050 00 00 30 60 00 78 9d 00 00 00 00 00 00 00 00 00 |..0`.x..........|
00000060 53 45 43 50 41 43 4b 00 00 00 00 00 00 f8 9f 00 |SECPACK.........|
00000070 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 |................|
00000080 4e 56 00 00 00 00 00 00 00 00 00 00 00 00 a0 00 |NV..............|
00000090 00 00 e8 60 00 00 20 00 00 00 00 00 00 00 00 00 |...`.. .........|
[rest is null]
00000200

reserved