[INFO] The Atrix sbf thread

[NFHimself]

Single Binary Format

Hi,

I thought I would start this thread so that all info about sbf utilities and formats specific to the Motorola Atrix could be in one place. (Kenneth Penn's idea) I don't know everything, not a lot, barely anything really, but I will share what I do. Feel free to chime in and correct anything I say.

First off, the software I have found:

• Welcome to 2008, Portable SBF Tool / desbf
• Motorola android SBF [de]Packer
• SBF recalc (waiting for 1.3 edition)

Of these utilities, the one that has done anything worthwhile for me is Desbf. SBF recalc keeps saying wait for version 1.3, and while sbf depacker has been updated for the Atrix, I haven't managed to sucessfully flash anything with it, it has the most promise though and hope for the future.

First, trying these utils is like walking into a shop in chinatown looking to buy a cheeseburger. Where am I? What do I do? How do you say "do something!"?

Desbf, I don't know the history behind this or what it has been used for in the past, it was on a list of google hits for the obscure motorola sbf format. You run it, select a sbf file, and it automatically creates a folder with all the files contained in the sbf extracted. You can delete files and then save an sbf that can be flashed. It has a parse CG button, don't know what it's for. It has been used to flash the Telstra radio onto Att and Bell. I have yet to use it to flash something using RDL3, just the radio using RDL1.

SBF Recalc, shows a lot of information, to use you split the file to a folder to start, do your thing with the files in that folder, and then open the folder to recalc checksum and save an sbf. Only problem is that is doesn't work (yet).

Motorola Android [De]packer is obviously the most in depth util, it shows even more information than SBF recalc. It does do things, not sure what, or if it's my lack of understanding of the format, but I haven't sucessfully done anything with it, it creates files, displays information, but complains about RDL files not being needed for the content, even if you delete all the RDL files.

Speaking of files, here is what I understand about them:

The utilities spit out SMG files, it's a motorola format, not sure of the acronym.

RDL1:
RDL3:

Ram downloader 1 is used for the radio, it is flashed after everything else, changing mode to do so, everything else is flashed using Ram downloader 3. I don't know what happened to RDL2.

CG2 22KB
CG3 512KB, CDT.bin

CG5 is the radio, plus other things apparently. In [De]Packer it's a virtual collection of mbn files, partition.mbn, amas_sec.mbn (the radio), osb1_sec.mbn, cefs.mbn, db1_sec.mbn. I have no idea what they are about. I know they are from CG5 because an sbf with just RDL1, RDL3, and CG5 spits out RDL1, RDL3, and the above without a CG5.

CG42 3072KB mostly zeros, ends at 0xff0
CG44 3072KB Bootloader
CG47 262144 Microboot (Engine and Slot for hashing in microboot priv.c) (ref to rdl1.bin, ptable, CDT.BIN, BCT.bin, PT.bin, EBT.bin, MBR.bin, EBB.bin)
CG50 is 2KB of 0xFF, no content, probably used to clear a partition
CG52 same as above, (sent to mmcblk0p7 to clear misc? -optionally used to pass commands to recovery, it fed with command line for example to flash an update -)
CG53 1014KB begins with SOL: logo.bin (mmcblk0p8)
CG54 2KB of 0xFF (possibly sent to mmcblk0p9, Kernel Panic Data)
CG55 recovery (header, ramdisk, kernel) (mmcblk0p10)
CG56 boot (header, ramdisk (/), kernel) (mmcblk0p11)
CG57 is the system image in ext3 linux format. (mmcblk0p12)
CG58 osh (webtop) system image in ext3 (mmcblk0p13)
CG59 20MB HFS, CDROM (Motorola Helper) (mmcblk0p14)
CG60 2KB of 0xFF (possibly sent to mmcblk0p15 to clear cache image)
CG61 2KB of 0xFF (sent to mmcblk0p16 to clear userdata image, tested)
CG62 preinstall image in ext3 (mmcblk0p17)

This is a work in progress.

New for Gingerbread 2.3.4:

CG39 looks like fs, pds update?
CG42 bootloader
CG47 same as before, just full partition size
CG56 boot logo
CG58 Recovery emmc image (kernel, ramdisk.gz)
CG59 Boot emmc image
CG60 system image APP
CG61 webtop image OSH
CG62 cdrom image motohelper
CG65 preinstall image

cat /proc/partitions
major minor  #blocks  name

   7        0       7308 loop0
   7        1       4190 loop1
 179        0   15668736 mmcblk0
 179        1       3584 mmcblk0p1
 179        2        512 mmcblk0p2
 179        3       2048 mmcblk0p3
 179        4          1 mmcblk0p4
 179        5       1024 mmcblk0p5
 179        6        512 mmcblk0p6
 179        7        512 mmcblk0p7
 179        8       1024 mmcblk0p8
 179        9       2048 mmcblk0p9
 179       10       8192 mmcblk0p10
 179       11       8192 mmcblk0p11
 179       12     327680 mmcblk0p12
 179       13     786432 mmcblk0p13
 179       14      20480 mmcblk0p14
 179       15     655360 mmcblk0p15
 179       16    2097152 mmcblk0p16
 179       17     353280 mmcblk0p17
 179       18   11233792 mmcblk0p18
 179       32    1931264 mmcblk1 (external sd card, 2 GB)
 179       33    1930680 mmcblk1p1 (external sd card, 2 GB)
 254        0       7308 dm-0
 254        1       4189 dm-1

LINKS: (to be integrated)

• http://forum.xda-developers.com/show...&postcount=502
• http://and-developers.com/partitions:cdt
• https://www.droid-developers.org/wiki/BootRecoverySignature

Cheers!

 

[brandon15811]

Heres a detailed list of the partitions:
http://forum.xda-developers.com/showpost.php?p=12687720&postcount=502

 

[kennethpenn]

This is awesome. Thanks for the details.

 

[NFHimself]

Thanks,

I am thinking it might be possible to create an sbf from a dump of the partitions on a active phone. It would certainly be nice to have one for Bell. My idea is to replace all the active bits in an sbf file with versions from a dd dump of each partition. [De]Packer could possibly be used to compile a CG5 from all the bits, take that file and use Desbf to create the rest of it.

So if someone with a stock Bell Atrix could run this and post a link back with the resulting 7zip file it would help. Mediafire or some other file hosting service.

backup creator script

What it does is dump all the "other" partitions, not system or data, or webtop, but all the little ones up to 11 and 14


Cheers!

 

[kennethpenn]

Thanks,

I am thinking it might be possible to create an sbf from a dump of the partitions on a active phone. It would certainly be nice to have one for Bell. My idea is to replace all the active bits in an sbf file with versions from a dd dump of each partition. [De]Packer could possibly be used to compile a CG5 from all the bits, take that file and use Desbf to create the rest of it.

So if someone with a stock Bell Atrix could run this and post a link back with the resulting 7zip file it would help. Mediafire or some other file hosting service.

backup creator script

What it does is dump all the "other" partitions, not system or data, or webtop, but all the little ones up to 11 and 14 15 16.

Cheers!

That would be a massive development for Bell users.

 

[NFHimself]

I have confirmed that removing CG61 causes a flash to not erase your userdata partition.

Cheers!

 

[kennethpenn]

Great news! Keep us updated.

 

[UncleCemka]

I have confirmed that removing CG61 causes a flash to not erase your userdata partition.

Cheers!

hey, how hard do you think it would be to modify the 1.2.6 SBF to also not wipe the user partition? Would it act like the 1.8.3 SBF which preserves all user settings and apps? Conversely, could we modify the 1.8.3 SBF to act like the 1.2.6 SBF by clearing all the settings out and returning completely back to stock? Sorry for all of the questions, but I just found the 1.8.3 SBF very cool, that it let me keep all my settings and apps, and thus cut down on the time I needed to spend on restoring things after the flash.

 

[eval-]

hey, how hard do you think it would be to modify the 1.2.6 SBF to also not wipe the user partition?

Probably as easy as pulling CG61 out, if I recall correctly (pretty easy...)

EDIT: haha I see NFHimself confirmed this... that's the one .8.3 is missing (besides CG51 --ideas?)

 

[NFHimself]

That's all I did, selected CG61, hit delete, save in desbf, and run rsdlite.

Only thing about it is that Gingerbreak will still wipe your internal memory so you still have to backup that.

 

[NFHimself]

The error in [de]packer, where it says source not found, seems to be limited to cg3.smb, remove that and it compiles the folder.

Cheers!

 

[NFHimself]

Update on creating a Bell sbf:

Of the partitions 1-11, and 14, the ones with unique content are 3, 5, 9, 10, 11. Of these, 10 and 11 are straight dumps in the sbf file, the recovery and boot partitions, the partitions 3, 5, and 9 have no direct correlation to a CG that I can see so far.

However, I have managed to go from a Telstra firmware to a stock Bell firmware, just not using a sbf. I simply did a dd of all Bell partitions from sdcard to the phone, leaving mmcblk0p12 for last since it's the system partition. Well most of the partitions, I didn't dd internal memory or data, I just did a data wipe. So, you can go back to stock, you just can't recover from a bricked situation, using this method.

Cheers!

 

[raybond25]

Update on creating a Bell sbf:

Of the partitions 1-11, and 14, the ones with unique content are 3, 5, 9, 10, 11. Of these, 10 and 11 are straight dumps in the sbf file, the recovery and boot partitions, the partitions 3, 5, and 9 have no direct correlation to a CG that I can see so far.

However, I have managed to go from a Telstra firmware to a stock Bell firmware, just not using a sbf. I simply did a dd of all Bell partitions from sdcard to the phone, leaving mmcblk0p12 for last since it's the system partition. Well most of the partitions, I didn't dd internal memory or data, I just did a data wipe. So, you can go back to stock, you just can't recover from a bricked situation, using this method.

Cheers!

that's great news and I hope that if an update comes out and Bell users aren't necessarily able to update that you might refine this method into an automated process or at least detail it for the rest of the community's benefit.

 

[GibMcFragger]

Wow. Great work NFHimself! That's the only reason I haven't taken Telstra for a spin. There's no going back......yet.

Sent from my rooted and frozen Motorola Olympus.

 

[NFHimself]

Well it was literally "dd if=sdcard/mmcblk0p1 of=/dev/block/mmcblk0p1" skipping 12 and continuing on, then doing 12. I did run setprop tcmd.suspend 2 first, and I was rooted, have to pull the battery to reboot since I overwrote the system partition and had no commands in my path, but that's it.

Just would need some online hosting space and do up a simple script, really.

Cheers!

 

[eval-]

Well it was literally "dd if=sdcard/mmcblk0p1 of=/dev/block/mmcblk0p1" skipping 12 and continuing on, then doing 12. I did run setprop tcmd.suspend 2 first, and I was rooted, have to pull the battery to reboot since I overwrote the system partition and had no commands in my path, but that's it.

Just would need some online hosting space and do up a simple script, really.

Cheers!

That is really ballsy. I will not write to my mmcblk0p1 because if there is the slightest error I believe I'd have a have a hard brick. All the options seen when holding power + volume-down (or up) can be found in that block device.

But this is not the case for Bell/Telstra?! Fascinating that your devices are different! Where *DOES* your bootloader live?

Actually, I now see that most the Telstra CG img files are signed by two keys, but almost all of the AT&T ones are signed by 3, and the keys differ between the two .sbfs (but are consistent within each.) How very strange. Our CG44s are very similar, but also different (for example do a diff on their strings):

Only in Telstra (1.4.2):

< UpdateBootBct
< BL size:%d
< MB size:%d
< NvMotBlReSign
< NvMotBctReSign End

 

[NFHimself]

I went through each one with hexedit, and nothing really struck me as being the bootloader, in fact, on my archos tablet, the bootloader was not stored in the mtd list at all, it was somewhere else, probably in the SOC somewhere.

Our partition 1 is all 0xFF, no danger there, either it's protected and can't be read or written to, or it really is 0xFF.

Cheers!

 

[NFHimself]

Oh, a dump of all the important Bell mtd partitions is available.

Bell_Full_Partition_Backup.tar.gz

Cheers!

 

[eval-]

Thanks! Yes, I suspect now that the OTA writes the mmcblk0p1 and that this is the location the new bootloader is updated from (on next boot?) and that RSD can simply skip this step and update directly. Just got an mmcblk0p1 from someone who never had an OTA (on ATT) and it is like yours "FF 00 00 00 FF: and then 3.5mb of FFs =) So, you were probably safe to overwrite it!

Will be interesting to confirm once you have your first OTA =) As for "SE" (Secured Engineering?) I don't know the difference to NS yet. Perhaps its related to the bootloader and certificate differences too.

 

[bongd]

Does anyone have much experience tinkering around with the PDS.bin file? There's reason to suspect that corruption in the mmcblk0p3 block occurs when the Internal SD is formatted and partitioned erroneously via custom recovery. this could be what causes the bottom of the touchscreen to become unresponsive for the bottom half inch of the screen (causes "ghosting" or misaligned touch response above the impacted area)

Tenfar advised me to properly format and partition mmcblk0p18 with the following command (#newfs_msdos -F 32 -S 512 -L MB860 -c 64 -u 16 /dev/block/mmcblk0p18) which did everything okay, but didn't make an impact unfortunately. Still tinkering around with this buggered AT&T Atrix for the last few weeks. Determined to fix this bish instead of sending it in lol