Related
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
in order to open up new rom options for apache, it seems that we will first need to find a way to do one of two things:
• find a way to make a bin dump of a DOC flash chip (apparently, tools like grab_it won't work on DOC flash).
• find a 'noID' update utility, or at least an update utility that allows a rom from one carrir to be installed on an apache from another carrier.
does anyone know if the bootloader can make a dump that can then be flashed to another device?
anyone have any ideas or knowledge to share?
lt seems as though a noID update utility that works on the apache will be a difficult tool to obtain, apparently due to the differences in rom structure in comparison to other phones.
Does anyone know how to use d2s to dump only the ce rom portion of the rom? Has anyone tried it on this phone? If so, any success flashing it back onto a phone?
does anyone have any information concerning the installation of roms from various carriers onto the apache.
anyone have any bin dumps from their apache that could be uploaded?
I can't be the only one with this phone who is interested in installing other roms.
I did some playing with itsutils pdocread and got some information out of the ROM, I have not had time to play further, however some commands I used:
Code:
C:\Temp\its\build>pdocread.exe -l
63.94M TrueFFS
| 3.06M Part00
| 3.19M Part01
| 41.75M Part02
44.21M TRUEFFS
| 3.06M Part00
| 3.19M Part01
| 41.75M Part02
9.99M TRUEFFS
| 3.06M Part00
| 3.19M Part01
| 41.75M Part02
968.75M DSK1:
| 968.50M Part00
STRG handles: b3105516
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (968.50M) b3e61036
3 partitions, 1 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ( 9.99M) 93f1610e
3 partitions, 1 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ( 44.21M) b3f71212
3 partitions, 1 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 1c 04 01 01 2e 13 0f 0b 10 0a 05 9b ( 41.75M) 53f71026
3 partitions, 1 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 1c 04 01 01 2e 13 0f 0b 10 0a 05 9b ( 3.19M) 13f71002
3 partitions, 1 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 1c 04 01 01 2e 13 0f 0b 10 0a 05 9b ( 3.06M)
I then extracted the first part (which looks like a bootloader when I ran strings on the file) with this command:
Code:
pdocread -n 0 0 0xf0000 docbdk0.raw
The reason I think it is a bootload is because of strings like this:
Code:
SDRAM Frequency = %d MHz
Memory Frequency = %d MHz
Turbo = %d MHz, Run = %d Mhz
Copyright (c) 1998-2005 High Tech Computer Corporation
12:04:54
Aug 31 2005
Built at:
1.00
The second part I tried to extract like this:
Code:
pdocread.exe -h 0xb3f71212 0 0x4000000 foo.rom
This part looks like the kernel...
Thats all I have time for right now, hope that helps.
Geoff
Hi,
I have a problem with an Asus TF700T. I had Clockworkmod Recovery installed and tried using it to flash Cyanogenmod. The flash failed and since then, CWM can't mount /data, /system or any other partition from the internal flash memory. I've then used fastboot to flash a new version of CWM, but also the new version (6.0.4.7) can't mount the partitions.
I fear the partition table of /dev/block/mmcblk0 may have been damaged, but recovery works fine. I have access to CWM, adb and fastboot.
Is there a way to fix the partition table or some other way of making the partitions mountable?
I used adb shell for some diagnostics:
cat /proc/partitions
major minor #blocks name
179 0 62087168 mmcblk0
179 32 4096 mmcblk0boot1
179 16 4096 mmcblk0boot0
179 48 15558144 mmcblk1
179 49 15554048 mmcblk1p1
After a reboot (with a half installed Cyanogenmod) somehow, the output is:~ # cat /proc/partitions, but CWM still can't mount /data, /system, etc...
major minor #blocks name
179 0 62087168 mmcblk0
179 1 786432 mmcblk0p1
179 2 438272 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 835584 mmcblk0p4
179 5 5120 mmcblk0p5
179 6 512 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 59976192 mmcblk0p8
179 9 8192 mmcblk0p9
179 10 8192 mmcblk0p10
179 32 4096 mmcblk0boot1
179 16 4096 mmcblk0boot0
179 48 15558144 mmcblk1
179 49 15554048 mmcblk1p1
Output of dmesg| grep mmc
Code:
dmesg|grep mmc
<5>[ 0.000000] Kernel command line: tegra_wdt.heartbeat=30 tegraid=30.1.3.0.0 [email protected] commchip_id=0 vmalloc=768M androidboot.serialno=015d29955e54260c androidboot.commchip_id=0 video=tegrafb no_console_suspend=1 console=ttyS0,115200n8 debug_uartport=lsport,0 usbcore.old_scheme_first=1 [email protected] [email protected] core_edp_mv=0 audio_codec=wm8903 board_info=245:0:fc:a6:29 tegraboot=sdmmc gpt gpt_sector=124174335 modem_id=0 android.kerneltype=recovery androidboot.productid=0x04 androidboot.carrier=wifi-only
<6>[ 0.805791] print_constraints: fixed_reg_en_3v3_emmc: 3300 mV normal standby
<6>[ 0.805974] set_supply: fixed_reg_en_3v3_emmc: supplied by fixed_reg_en_3v3_sys
<6>[ 3.640685] [mmc]:sdhci_tegra_probe:1152 mmc0: built_in 1
<4>[ 3.642707] mmc0: Invalid maximum block size, assuming 512 bytes
<6>[ 3.642994] mmc0: no vmmc regulator found
<7>[ 3.644267] Registered led device: mmc0::
<6>[ 3.646836] [mmc]:mmc_schedule_delayed_work:84 mmc0: delay 0
<6>[ 3.646987] mmc0: SDHCI controller on sdhci-tegra.3 [sdhci-tegra.3] using ADMA
<4>[ 3.648498] mmc1: Invalid maximum block size, assuming 512 bytes
<6>[ 3.648779] mmc1: no vmmc regulator found
<7>[ 3.650058] Registered led device: mmc1::
<6>[ 3.652575] [mmc]:mmc_schedule_delayed_work:84 mmc1: delay 0
<6>[ 3.652723] mmc1: SDHCI controller on sdhci-tegra.2 [sdhci-tegra.2] using ADMA
<6>[ 3.653397] [mmc]:sdhci_tegra_probe:1099 mmc2: non-built_in 0
<4>[ 3.656192] mmc2: Invalid maximum block size, assuming 512 bytes
<6>[ 3.656475] mmc2: no vmmc regulator found
<7>[ 3.657758] Registered led device: mmc2::
<6>[ 3.660210] [mmc]:mmc_schedule_delayed_work:84 mmc2: delay 0
<6>[ 3.660469] mmc2: SDHCI controller on sdhci-tegra.0 [sdhci-tegra.0] using ADMA
<6>[ 3.761658] [mmc]:mmc_decode_cid:118 prv: 0x6f, manfid: 0x90
<6>[ 3.773320] [mmc]:mmc_read_ext_csd:365 Boot Block Expose, boot size of mmc0 is 8388608
<6>[ 3.775552] mmc0: new high speed DDR MMC card at address 0001
<6>[ 3.776088] mmcblk mmc0:0001: Card claimed for testing.
<6>[ 3.776781] mmcblk0: mmc0:0001 HYNIX 59.2 GiB
<6>[ 3.777369] mmcblk0boot0: mmc0:0001 HYNIX partition 1 4.00 MiB
<6>[ 3.778074] mmcblk0boot1: mmc0:0001 HYNIX partition 2 4.00 MiB
<6>[ 3.794728] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10
<6>[ 3.808067] mmcblk0boot1: unknown partition table
<6>[ 3.812871] mmcblk0boot0: unknown partition table
<6>[ 3.815515] [mmc]:mmc_rescan_try_freq:2010 mmc0: eMMC completed
<4>[ 4.042757] mmc2: host does not support reading read-only switch. assuming write-enable.
<6>[ 4.046107] mmc2: new high speed SDHC card at address e624
<6>[ 4.046532] mmcblk mmc2:e624: Card claimed for testing.
<6>[ 4.047366] mmcblk1: mmc2:e624 SU16G 14.8 GiB
<6>[ 4.058056] mmcblk1: p1
<6>[ 4.058913] [mmc]:mmc_rescan_try_freq:2006 mmc2: SD completed
<6>[ 4.996531] [mmc]:mmc_schedule_delayed_work:84 mmc1: delay 0
<4>[ 5.052746] mmc1 clock request: 50000KHz. currently 48000KHz
<6>[ 5.054371] mmc1: new high speed SDIO card at address 0001
<6>[ 5.062845] [mmc]:mmc_rescan_try_freq:2002 mmc1: sdio completed
<6>[ 7.693501] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
<7>[ 7.693580] SELinux: initialized (dev mmcblk0p2, type ext4), uses xattr
Can someone please shed some light on this? Thank you very much!
giza1928 said:
major minor #blocks name
179 0 62087168 mmcblk0
179 1 786432 mmcblk0p1
179 2 438272 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 835584 mmcblk0p4
179 5 5120 mmcblk0p5
179 6 512 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 59976192 mmcblk0p8
179 9 8192 mmcblk0p9
179 10 8192 mmcblk0p10
179 32 4096 mmcblk0boot1
179 16 4096 mmcblk0boot0
179 48 15558144 mmcblk1
179 49 15554048 mmcblk1p1
...
<6>[ 3.794728] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10
Click to expand...
Click to collapse
That looks quite correct. What happens when you try to mount /data manually?
mount -t ext4 /dev/block/mmcblk0p8 /data
Click to expand...
Click to collapse
_that said:
That looks quite correct. What happens when you try to mount /data manually?
Click to expand...
Click to collapse
Thanks, good idea. But unfortunately, the error message isn't very detailed:
Code:
mount -t ext4 /dev/block/mmcblk0p8 /data
mount: mounting /dev/block/mmcblk0p8 on /data failed: Invalid argument
I also tried to check the filesystem with e2fsck:
Code:
~ # e2fsck /dev/block/mmcblk0p8
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/block/mmcblk0p8
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
giza1928 said:
Thanks, good idea. But unfortunately, the error message isn't very detailed:
Code:
mount -t ext4 /dev/block/mmcblk0p8 /data
mount: mounting /dev/block/mmcblk0p8 on /data failed: Invalid argument
Click to expand...
Click to collapse
Is there any message in dmesg after trying this?
What do you get from "hexdump -C -n 2048 /dev/block/mmcblk0p8"?
_that said:
Is there any message in dmesg after trying this?
What do you get from "hexdump -C -n 2048 /dev/block/mmcblk0p8"?
Click to expand...
Click to collapse
No, no messages in dmesg after the mount command, only updates like this:
Code:
<4>[ 81.890682] cpu ext_temperature=26
The output from the hexdump command:
Code:
~ # hexdump -C -n 2048 /dev/block/mmcblk0p8
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000800
giza1928 said:
The output from the hexdump command:
Code:
~ # hexdump -C -n 2048 /dev/block/mmcblk0p8
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000800
Click to expand...
Click to collapse
Funny. Normally the superblock should start at offset 0x400. Yours appears to have gotten wiped.
Try the same command on mmcblk0p1, mmcblk0p2, mmcblk0p3, mmcblk0p5 and post the results just to find out what's going on.
_that said:
Funny. Normally the superblock should start at offset 0x400. Yours appears to have gotten wiped.
Try the same command on mmcblk0p1, mmcblk0p2, mmcblk0p3, mmcblk0p5 and post the results just to find out what's going on.
Click to expand...
Click to collapse
p1:
Code:
hexdump -C -n 2048 /dev/block/mmcblk0p1
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 00 c0 00 00 00 00 03 00 00 00 00 00 95 ce 01 00 |................|
00000410 d2 b9 00 00 00 00 00 00 02 00 00 00 02 00 00 00 |................|
00000420 00 80 00 00 00 80 00 00 00 20 00 00 38 e3 78 53 |......... ..8.xS|
00000430 38 e3 78 53 05 00 ff ff 53 ef 01 00 02 00 00 00 |8.xS....S.......|
00000440 d2 aa 78 53 00 00 00 00 00 00 00 00 01 00 00 00 |..xS............|
00000450 00 00 00 00 0b 00 00 00 00 01 00 00 1c 00 00 00 |................|
00000460 42 00 00 00 13 00 00 00 57 f8 f4 bc ab f4 65 5f |B.......W.....e_|
00000470 bf 67 94 6f c0 f9 f2 5b 00 00 00 00 00 00 00 00 |.g.o...[........|
00000480 00 00 00 00 00 00 00 00 2f 73 79 73 74 65 6d 00 |......../system.|
00000490 e8 0a 29 c0 00 9c a6 c7 b0 ca b7 c6 00 00 00 00 |..).............|
000004a0 48 b4 54 c7 e0 a3 58 c6 fc fd e0 c6 c8 fd e0 c6 |H.T...X.........|
000004b0 fc 7e 12 c0 80 f3 1a c0 e4 fd e0 c6 74 f3 1a c0 |.~..........t...|
000004c0 bc c7 7c c0 00 9c a6 c7 00 00 00 00 00 00 2f 00 |..|.........../.|
000004d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000004e0 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000004f0 00 00 00 00 00 00 00 00 00 00 00 00 02 01 20 00 |.............. .|
00000500 00 00 00 00 00 00 00 00 00 00 00 00 0a f3 01 00 |................|
00000510 03 00 00 00 00 00 00 00 00 00 00 00 00 0c 00 00 |................|
00000520 33 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |3...............|
00000530 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000550 00 00 00 00 00 00 00 00 00 00 00 00 1c 00 1c 00 |................|
00000560 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000570 00 00 00 00 00 00 00 00 ec 83 04 00 00 00 00 00 |................|
00000580 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000800
p2:
Code:
~ # hexdump -C -n 2048 /dev/block/mmcblk0p2
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 00 6b 00 00 00 ac 01 00 00 00 00 00 86 86 01 00 |.k..............|
00000410 dc 6a 00 00 00 00 00 00 02 00 00 00 02 00 00 00 |.j..............|
00000420 00 80 00 00 00 80 00 00 c0 1a 00 00 f3 eb 78 53 |..............xS|
00000430 f3 eb 78 53 08 00 ff ff 53 ef 01 00 02 00 00 00 |..xS....S.......|
00000440 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 |................|
00000450 00 00 00 00 0b 00 00 00 00 01 00 00 1c 00 00 00 |................|
00000460 46 00 00 00 13 00 00 00 57 f8 f4 bc ab f4 65 5f |F.......W.....e_|
00000470 bf 67 94 6f c0 f9 f2 5b 00 00 00 00 00 00 00 00 |.g.o...[........|
00000480 00 00 00 00 00 00 00 00 2f 63 61 63 68 65 00 e8 |......../cache..|
00000490 0a 29 c0 c0 dd d6 c6 88 d3 b8 c6 00 00 00 00 b8 |.)..............|
000004a0 eb b8 c6 20 cb 81 c7 fc dd da c6 c8 dd da c6 fc |... ............|
000004b0 7e 12 c0 80 f3 1a c0 e4 dd da c6 74 f3 1a c0 bc |~..........t....|
000004c0 c7 7c c0 c0 dd d6 c6 d8 00 00 00 00 00 00 1f 00 |.|..............|
000004d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000004e0 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000004f0 00 00 00 00 00 00 00 00 00 00 00 00 02 01 20 00 |.............. .|
00000500 00 00 00 00 00 00 00 00 00 00 00 00 0a f3 01 00 |................|
00000510 03 00 00 00 00 00 00 00 00 00 00 00 b0 06 00 00 |................|
00000520 cf 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000530 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000550 00 00 00 00 00 00 00 00 00 00 00 00 1c 00 1c 00 |................|
00000560 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000570 00 00 00 00 00 00 00 00 ec 18 00 00 00 00 00 00 |................|
00000580 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000800
p3:
Code:
~ # hexdump -C -n 2048 /dev/block/mmcblk0p3
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000800
p5:
Code:
~ # hexdump -C -n 2048 /dev/block/mmcblk0p5
00000000 eb 58 90 42 53 44 20 20 34 2e 34 00 02 08 20 00 |.X.BSD 4.4... .|
00000010 02 00 00 00 28 f0 00 00 10 00 04 00 00 00 00 00 |....(...........|
00000020 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 00 00 |................|
00000030 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 29 d2 07 38 a4 4e 4f 20 4e 41 4d 45 20 20 |..)..8.NO NAME |
00000050 20 20 46 41 54 33 32 20 20 20 fa 31 c0 8e d0 bc | FAT32 .1....|
00000060 00 7c fb 8e d8 e8 00 00 5e 83 c6 19 bb 07 00 fc |.|......^.......|
00000070 ac 84 c0 74 06 b4 0e cd 10 eb f5 30 e4 cd 16 cd |...t.......0....|
00000080 19 0d 0a 4e 6f 6e 2d 73 79 73 74 65 6d 20 64 69 |...Non-system di|
00000090 73 6b 0d 0a 50 72 65 73 73 20 61 6e 79 20 6b 65 |sk..Press any ke|
000000a0 79 20 74 6f 20 72 65 62 6f 6f 74 0d 0a 00 00 00 |y to reboot.....|
000000b0 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 52 52 61 41 00 00 00 00 00 00 00 00 00 00 00 00 |RRaA............|
00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000003e0 00 00 00 00 72 72 41 61 ff ff ff ff 0d 00 00 00 |....rrAa........|
000003f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000400 eb 58 90 42 53 44 20 20 34 2e 34 00 02 08 20 00 |.X.BSD 4.4... .|
00000410 02 00 00 00 28 f0 00 00 10 00 04 00 00 00 00 00 |....(...........|
00000420 00 00 00 00 0a 00 00 00 00 00 00 00 02 00 00 00 |................|
00000430 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000440 00 00 29 d2 07 38 a4 4e 4f 20 4e 41 4d 45 20 20 |..)..8.NO NAME |
00000450 20 20 46 41 54 33 32 20 20 20 fa 31 c0 8e d0 bc | FAT32 .1....|
00000460 00 7c fb 8e d8 e8 00 00 5e 83 c6 19 bb 07 00 fc |.|......^.......|
00000470 ac 84 c0 74 06 b4 0e cd 10 eb f5 30 e4 cd 16 cd |...t.......0....|
00000480 19 0d 0a 4e 6f 6e 2d 73 79 73 74 65 6d 20 64 69 |...Non-system di|
00000490 73 6b 0d 0a 50 72 65 73 73 20 61 6e 79 20 6b 65 |sk..Press any ke|
000004a0 79 20 74 6f 20 72 65 62 6f 6f 74 0d 0a 00 00 00 |y to reboot.....|
000004b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000005f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000600 52 52 61 41 00 00 00 00 00 00 00 00 00 00 00 00 |RRaA............|
00000610 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000007e0 00 00 00 00 72 72 41 61 ff ff ff ff 02 00 00 00 |....rrAa........|
000007f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000800
Thanks already for your help, to be honest I have no clue what I'm looking at. Are those the first 2048 bits of each partition?
giza1928 said:
Thanks already for your help, to be honest I have no clue what I'm looking at. Are those the first 2048 bits of each partition?
Click to expand...
Click to collapse
Yes. All other partitions except /data look normal - p1 is /system, p2 is /cache, p3 is the bootloader command partition which is usually empty, p5 contains device configuration in a FAT32 filesystem.
Try formatting /data from the recovery, then reinstall your ROM (which will format and fill /system).
_that said:
Yes. All other partitions except /data look normal - p1 is /system, p2 is /cache, p3 is the bootloader command partition which is usually empty, p5 contains device configuration in a FAT32 filesystem.
Try formatting /data from the recovery, then reinstall your ROM (which will format and fill /system).
Click to expand...
Click to collapse
Ok, do you mean the format command I can select in recovery? Because it says:
Code:
Formatting /data...
Error mounting /data!
Skipping format...
Done.
But can I maybe use mke2fs or something similar to format /dev/mmcblk0p8? If so, could you tell me what options I should use?
Thanks
giza1928 said:
Ok, do you mean the format command I can select in recovery? Because it says:
Code:
Formatting /data...
Error mounting /data!
Skipping format...
Done.
Click to expand...
Click to collapse
I have no experience with CWM; apparently it sucks.
giza1928 said:
But can I maybe use mke2fs or something similar to format /dev/mmcblk0p8? If so, could you tell me what options I should use?
Click to expand...
Click to collapse
Code:
make_ext4fs /dev/block/mmcblk0p8
should do it. Assuming that CWM ships with a make_ext4fs binary.
_that said:
I have no experience with CWM; apparently it sucks.
Code:
make_ext4fs /dev/block/mmcblk0p8
should do it. Assuming that CWM ships with a make_ext4fs binary.
Click to expand...
Click to collapse
Thanks, that worked! CWM does ship with make_ext4fs, I flashed Cyanogenmod and it booted successfully! :victory:
I figured I would post my experience with a sudden bootloop. My tf700t was unlocked and rooted a very long time ago and I've used a few ROM's since doing that. First was CROMI-x then Cyanogenmod 11 nightlies then CROMBi-kk and then I switched to ZOMBI-x.
I installed Zombi-x using F2FS file system and never had any issues except for the usual mind numbing lag from the horrible IO issues.
So just last night (12/21/2014) my tablet froze with a light grey screen and about 10 seconds later it rebooted, but it kept rebooting over and over. I tried cold booting, but that didn't help, so I booted into CWM (ver. 6.0.4.7) and tried to do a wipe data/system reset, but the tablet would just reboot part way through. I tried formatting the /data partition directly but it caused the tablet to reboot as well. So a few other posts around the interwebs led me to the conclusion that I needed to get rid of clockworkmod and switch to TWRP.
Thankfully I was able to connect to the tablet using fastboot, but only in Linux. (my Win7 PC saw that something was there, but it wouldn't let me install the driver)(http://lifehacker.com/the-easiest-way-to-install-androids-adb-and-fastboot-to-1586992378) So I installed TWRP 2.8.3.0 and used it to do a complete wipe. It started the format but had several errors about not being able to mount /data and then it said it was formatting Data using ext4fs. I've read that it should only take 5 minutes or so, so you can imagine my worry when 5 minutes past and then 10 and so on until it finished up after a little over 30 minutes, so if it's just sitting there, there's a good chance it is actually doing something, so leave it be for awhile and don't forget to check your battery, you don't want your tab to shut off suddenly!
I reinstalled CROMBi-kk and let it boot. Much to my surprise it booted and the resulting performance was nothing short of shocking!
So far this thing is running like it NEVER has before! The lag so far is so much less than ever and things open and close very quickly!
So without any surprise here, I won't be using F2FS anymore for fear I'll have corruption on the internal storage again! Thankfully TWRP came through for me. So if your tf700 is bootlooping and you still have fastboot, try installing the latest TWRP, it may just make the difference between a functioning tablet and a brick!
Viking8 said:
So I installed TWRP 2.8.3.0 and used it to do a complete wipe. It started the format but had several errors about not being able to mount /data and then it said it was formatting Data using ext4fs. I've read that it should only take 5 minutes or so, so you can imagine my worry when 5 minutes past and then 10 and so on until it finished up after a little over 30 minutes, so if it's just sitting there, there's a good chance it is actually doing something, so leave it be for awhile and don't forget to check your battery, you don't want your tab to shut off suddenly!
I reinstalled CROMBi-kk and let it boot. Much to my surprise it booted and the resulting performance was nothing short of shocking!
So far this thing is running like it NEVER has before! The lag so far is so much less than ever and things open and close very quickly!
Click to expand...
Click to collapse
The long time it takes for formatting and the performance gains are actually related. Creating the filesystem takes probably less than 5 minutes, but then the recovery does a "trim" on the free blocks - telling the eMMC that it may discard the data in these blocks and erase them. Erasing flash memory is slow. But following write requests by the booted ROM will be much faster because they can be written directly without prior erasing and shuffling data around.
_that said:
The long time it takes for formatting and the performance gains are actually related. Creating the filesystem takes probably less than 5 minutes, but then the recovery does a "trim" on the free blocks - telling the eMMC that it may discard the data in these blocks and erase them. Erasing flash memory is slow. But following write requests by the booted ROM will be much faster because they can be written directly without prior erasing and shuffling data around.
Click to expand...
Click to collapse
So the performance boost after formatting /data is temporary until the emmc again has to shuffle data around when it gets write requests?
I thought f2fs was supposed to take care of that?
berndblb said:
So the performance boost after formatting /data is temporary until the emmc again has to shuffle data around when it gets write requests?
I thought f2fs was supposed to take care of that?
Click to expand...
Click to collapse
Using f2fs should increase the time until the eMMC has to shuffle data around because it does less random writes. But when all blocks have been written once, something must be erased to rewrite more. The permanent solution is to run fstrim regularly (I've seen some comments in the Android source code that runs it automatically from time to time) or to mount with the discard option, and to leave a reasonable amount of space free (10 to 15%).
_that said:
Using f2fs should increase the time until the eMMC has to shuffle data around because it does less random writes. But when all blocks have been written once, something must be erased to rewrite more. The permanent solution is to run fstrim regularly (I've seen some comments in the Android source code that runs it automatically from time to time) or to mount with the discard option, and to leave a reasonable amount of space free (10 to 15%).
Click to expand...
Click to collapse
Enlightening as always! Happy Holidays to you and your family!
[emoji319] [emoji319] [emoji318] [emoji319] [emoji319]
It doesn't seem that lagfix can trim /data formated to f2fs.
Sent from my TF700T using Tapatalk
Tutorial/Guide for Re-partitioning MTK6589/MTK65xx + Increase your System & Data Partitions + Flash through CWM/TWRP + no need to use SPFlashTool
Part 1 :- To Flash existing modified EBR files through CWM/TWRP
There are plenty of guides for re-partitioning mtk devices, so why this one?
Well almost all of them suggest to use SPFlashTool to flash the "EBR" Files.
But we can do that by using CWM/TWRP (Custom Recoveries) as well!!!!!
no need to use SPFlashTool!
no need to format the Internal SDCard through PC!!
Just take your modified "EBR" files and put them into a Flashable Zip.
Edit the "updater-script" file to include the following lines.
Code:
[FONT="Comic Sans MS"][SIZE="3"][COLOR="Red"]package_extract_file("EBR1", "/dev/ebr1");
#put the name of your EBR1 file in place of "EBR1"
package_extract_file("EBR2", "/dev/ebr2");
#put the name of your EBR2 file in place of "EBR2"[/COLOR][/SIZE][/FONT]
Note :- If your device uses both the files then add both the lines and If your device uses only "EBR1" then add only the line of "EBR1".
Now add the following lines to format your "/system" , "/cache" and "/data" partitions.
Code:
[FONT="Comic Sans MS"][SIZE="3"][COLOR="Red"]
format("ext4", "EMMC", "/[email protected]", "0", "/system");
format("ext4", "EMMC", "/[email protected]", "0", "/cache");
format("ext4", "EMMC", "/[email protected]", "0", "/data");
[/COLOR][/SIZE][/FONT]
Note :- If you are going to increase your "/system" partition then you'll have to format the 3 partitions,
and if you just want to increase the "/data" partition then just include the lines for formatting "/cache" and "/data".
now save the "updater-script" file and replace it in the Flashable zip!!
Or , you can use this sample flashable zip file.
download it and put your EBR files in it!!!!
edit the "updater-script" file according to your need and replace it in the Flashable zip!!
copy the Flashable zip file to your external SDCard
reboot to recovery
select install from zip file and choose the flashable zip file
Flash it.
Remember after flashing the EBR files do not restore your previous CWM/TWRP Backup.
Just Flash any CWM/TWRP Flashable ROM available for your device!!
Wipe Dalvik Cache if you haven't done it already!!
reboot and see for yourself!!!
Disclaimer :-
I will not be in anyway responsible for any damage this might cause to your phone.
if you'll follow the instructions correctly, then everything will be fine.
Part 2 :-
for understanding your MTK device's partitions, first read this excellent guide posted by @tirta.agung --> [Noob Guide] Understanding the Hex value of MTK's MBR/EBR1/EBR2
So How to Increase the system partition? or the data partition?
I'll tell you!!
I use MMX Canvas HD A116 (mt6589)
it has 4GB internal storage distributed as below:
/system = 650mb
/cache = 126mb
/data = 1gb
Internal SDcard = 1.77gb
i wanted to change it to this:- (and i've done it!!!)
/system = 900mb
/cache = 126mb
/data = 2gb
Internal SDCard = remaining space i.e around 536mb
Note :- First please read the above mentioned guide, otherwise you won't understand this!!
let me try to make it simple to you
this is the hex format of "EBR1" & "EBR2"
EBR1 of MMX A116 (mt6589) :-
00 00 00 00 83 00 00 00 00 08 02 00 00 50 14 00 --> Partition 5 /system 650MB
00 00 00 00 83 00 00 00 00 58 16 00 00 f0 03 00 --> Partition 6 /cache 126MB
00 00 00 00 83 00 00 00 00 48 1a 00 00 00 20 00 --> Partition 7 /data 1GB
00 00 00 00 05 00 00 00 00 b4 01 00 ff ff ff ff --> points to ebr2
EBR2 of MMX A116 (mt6589) :-
00 00 00 00 83 00 00 00 00 94 38 00 ff b7 c5 ff --> partition 8 Internal SDCard
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
Note :-
numbers in red --> Offset of partition
numbers in DarkOrange --> Size of Partition
Click to expand...
Click to collapse
Now if you notice carefully these partitions are continuous/contiguous.
133120 + 1331200 = 1464320
1464320 + 258048 = 1722368
i.e no.of sectors before partition + the length of the partition = no.of sectors before the next partition
// 133120 = no.of sectors before "/system" partition i.e "/system" starts from sector no. 133121
// 1331200 = the length of "/system" i.e "/system" is of 1331200 sectors.
// 1464320 = no.of sectors before "/cache" partition i.e "/cache" starts from sector no. 1464321
// and so on
The last line in EBR1 points to EBR2.
(This one --> 00 00 00 00 05 00 00 00 00 b4 01 00 ff ff ff ff )
and the First line in EBR2 is the one for the partition of Internal SDCard.
(This one --> 00 00 00 00 83 00 00 00 00 94 38 00 ff b7 c5 ff )
Even after reading many guides, I haven't found a proper explanation of this anywhere.
in one of them it states that,
D = (A + B) - C
where,
A = no.of sectors before "/data"
B = size of "/data"
C = offset of EBR2
D = offset part in EBR2
E = MaxValue - (A + B)
where,
MaxValue = FFFFFFFF (Hex) = 4294967295 (in decimal)
A = no.of sectors before "/data"
B = size of "/data"
E = Size part in EBR2
A = 00 48 1a 00 --> 001a4800 --> 1722368 //offset of "/data"
B = 00 00 20 00 --> 00200000 --> 2097152 //size of "/data"
C = 00 b4 01 00 --> 0001b400 --> 111616 //offset of ebr2
Max Value = FF FF FF FF --> ffffffff --> 4294967295 //?
Note :-
in Red --> Hex values in little endian
in Orange --> Hex values in big endian
in Blue --> Decimal values
Click to expand...
Click to collapse
D = (A+B) - C = (1722368 + 2097152) - 111616 = 3707904
E = MaxValue - (A+B) = 4294967295 - (1722368 + 2097152) = 4291147775
D = 3707904 = 00389400 = 00 94 38 00
E = 4291147775 = ffc5b7ff = ff b7 c5 ff
so now you've got a good idea of what the values in "EBR" files mean, haven't you!!
Now here comes the Important part i.e how to modify the partition sizes.
I wanted "/system" = 900mb , so
So we get "00 20 1C 00" as the value for 900mb
(note-down these new values as we'll need to use them later)
now as we've increased the size of system we need to change the offset of the next partition so that there won't be any overlapping/corruption of partitions.
and how do we do that --> "no.of sectors before partition + the length of the partition = no.of sectors before the next partition"
i.e 133120 + 1843200 = 1976320 //new offset of "/cache"
decimal value --> 1976320
Hex value in big endian --> 001E2800
Hex value in little endian --> 00 28 1E 00
So we get "00 28 1E 00" as the value for sectors before "/cache"
i don't want to change size of "/cache" so it remains same i.e "00 f0 03 00"
now we need to offset the "/data" partition
("no.of sectors before partition + the length of the partition = no.of sectors before the next partition")
1976320 + 258048 = 2234368 // the number of sectors before "/data" partition
decimal value --> 2234368
Hex value in big endian --> 00221800
Hex value in little endian --> 00 18 22 00
So we get "00 18 22 00" as the value for sectors before "/data"
now i want to make my "/data" to 2gb i.e 2048mb
So we get "00 00 40 00" as the value for 2048mb
The last line in EBR1 Points to EBR2 so don't make any changes to it!!!
So now our modified EBR1 Becomes like this:-
00 00 00 00 83 00 00 00 00 08 02 00 00 20 1c 00 --> Partition 5 /system 900MB
00 00 00 00 83 00 00 00 00 28 1E 00 00 f0 03 00 --> Partition 6 /cache 126MB
00 00 00 00 83 00 00 00 00 18 22 00 00 00 40 00 --> Partition 7 /data 2GB
00 00 00 00 05 00 00 00 00 b4 01 00 ff ff ff ff --> Link to ebr2
now we need to offset the Internal SDCard's partition which is in EBR2
calculate new D & E :-
D = (A+B) - C
where,
A = no.of sectors before "/data"
B = size of "/data"
C = offset of EBR2
E = MaxValue - (A+B)
where,
MaxValue = FFFFFFFF (Hex) = 4294967295 (Decimal)
A = no.of sectors before "/data"
B = size of "/data"
A = 00 18 22 00 --> 00221800 --> 2234368 //offset of "/data"
B = 00 00 40 00 --> 00400000 --> 4194304 //size of "/data"
C = 00 b4 01 00 --> 0001b400 --> 111616 //offset of ebr2
Max Value = FF FF FF FF --> ffffffff --> 4294967295 //?
D = (A+B) - C = (2234368 + 4194304) - 111616 = 6317056
E = MaxValue - (A+B) = 4294967295 - (2234368 + 4194304) = 4288538623
D = 6317056 = 00606400 = 00 64 60 00
E = 4288538623 = FF9DE7FF = ff e7 9d ff
That's it, now we've got all the values ,it's time to put them into the EBR Files.
So this is the result of our modification:-
Modified EBR1 :-
00 00 00 00 83 00 00 00 00 08 02 00 00 20 1c 00 --> Partition 5 /system 900MB
00 00 00 00 83 00 00 00 00 28 1E 00 00 f0 03 00 --> Partition 6 /cache 126MB
00 00 00 00 83 00 00 00 00 18 22 00 00 00 40 00 --> Partition 7 /data 2GB
00 00 00 00 05 00 00 00 00 b4 01 00 ff ff ff ff --> Link to ebr2
Modified EBR2 :-
00 00 00 00 83 00 00 00 00 64 60 00 ff e7 9d ff --> internal sdcard
To edit "EBR" files :-
Open your ERB1 & EBR2 files in hex editor and replace the respective values with our modified values.
save the files and put them into a flashable zip and flash through CWM/TWRP or whatever custom recovery that you use!!!!
Remember after flashing the EBR files do not restore your previous CWM/TWRP Backup.
Just Flash any CWM/TWRP Flashable ROM available for your device!!
Wipe Dalvik Cache if you haven't done it already!!
reboot and see for yourself!!!
Screenshots :-
Disclaimer :-
I will not be in anyway responsible for any damage this might cause to your phone.
if you'll follow the instructions correctly, then everything will be fine.
reserved for mods :-
If you want them resized according to your need then you can request it here or use this tutorial to do it yourself!!!
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