Droid 1 custom bootloader logos to replace Motorola logo

[fish1552]

Well, first attempt at making one of the new ones bombed. I'm bringing Simply Stunning back up right now after a fresh install after I got an error 21 when attempting to restore my latest nandroid.

Oh well, just have to keep trying... Might have that multicolored image now to see.

And looking at the camo image I made, none of them have that color in the very corner of the image. It's getting interesting.

 

[MotoCache1]

Well, first attempt at making one of the new ones bombed. I'm bringing Simply Stunning back up right now after a fresh install after I got an error 21 when attempting to restore my latest nandroid.

Oh well, just have to keep trying... Might have that multicolored image now to see.

And looking at the camo image I made, none of them have that color in the very corner of the image. It's getting interesting.

I've got it almost completely isolated. No sense both of us repeatedly flashing (and risking) our phones. I've got lots of Droid 1's and am doing it on one that if it got bricked I'd be OK with it. Will have results soon.

 

[fish1552]

Ok, if you want to try the lined images feel free. I figure the vertical one might be the one you'll figure out the color on.

 

[MotoCache1]

OK, I actually got it narrowed down to a single pixel with only 2 flashes, plus 1 extra for confirmation. Not bad. Total elapsed time from start to finish, 52 minutes -- including writing the completely optional SMG building script, and not including writing it up in this post.

This is the first image:

Basically the top line is completely orange, the bottom line is completely pink, the left line is red, then green, then blue (top to bottom), but not including the topmost or bottom-most pixel, and the right line is gold, then aqua, then gold (oops, used the same color twice) not including the topmost or bottom-most pixel. The middle is of course yellow.

When I flashed this in, the background was orange. Yay - our pixel is on the top line.

This is the second image:

Now the whole image is yellow except the top line (since we only care about the top line). The upper left pixel is black, the upper right pixel is white, and then at about 80 pixels apiece the segments in between are red, orange, yellow, green, blue, and violet. Yeah, if the background had been yellow it would have been semi-ambiguous, but not really since the body seems not to matter.

Flashed it in, booted, background was white.

Voila -- the only thing white in that image is the upper right pixel.

Made this 3rd image just for confirmation:

The whole image is yellow except the upper right pixel is pink. Flashed it in, booted, background is pink. Mystery solved and confirmed.

Final answer -- the upper right corner of the image (as saved, after mirroring, before doing all the other manipulation to it in the hex editor) is the color that will be the background.

Also, I'm a programmer, so I got tired of hex editing files manually and dashed off a quick script to do all the hex manipulation of the BMP. Just save the BMP, feed it to this script (assuming you've got Perl on your machine) and it spits out a CG42.smg file.

#!/usr/local/bin/perl

# MotoCache1 - take 480 x 182, 24 bit BMP file and make it into a CG42 code group

use strict;

my $file = $ARGV[0];

die("Syntax: MakeCG42FromBMP.pl filename.bmp") unless (-e $file);

open (IN,$file) or die ("No in $file. Error: $!");
binmode IN;
open (OUT,">$file.CG42.smg") or die ("No out $file.CG42.smg");
binmode OUT;

my $junkData;
my $junkBytes = read(IN,$junkData,54);
die ("Failed to read the 54 junk bytes at the beginning.") unless $junkBytes == 54;

my $imageData;
my $imageBytes = read(IN,$imageData,262080);
die ("Failed to read the 262080 image bytes.") unless $imageBytes == 262080;
close IN;

my $pad64 = "\xFF" x 64;
$imageBytes = reverse(split(//,$imageData)) . $pad64;

print OUT $imageBytes;
close OUT;

I could make it do the mirror for you too, but that's a little tougher than the reverse and presumably everyone that has been making these is used to doing the mirror (and it takes like half a second), so I doubt I'd bother making changes at this point.

P.S. The attachments are PNG's just to make them small -- the ones actually used in the files were of course BMPs. For anybody that has never understood what hacking is, that's hacking. Modify, observe, hypothesize, test, repeat until solved. The better (or luckier) you are, the fewer "repeat" cycles you hopefully need.

 

[Jharmon12]

wow thats exactly what i was wanting to do but i havnt been able to edit your custom sbf files to try it out :/ but this will fix my boot logo thanks for the dedication to find out the answer.

 

[DF Smod]

Motocache1....you have scrambled my brains at 5:14 A.M. :wacko:

Dedication indeed, now I can go back and knock this out because I also had that one pixel background issue...Thanks Again :icon_wink:

 

[fish1552]

Don't have Perl already, but downloaded Strawberry Perl: Strawberry Perl for Windows. Probably could have just rebooted into Ubuntu though...

I'll play around with it. Just let us know what compiler you suggest for these files then if you would. I want to modify all the other ones I did to the new exploded versions so people don't need to reflash everything if they use any of them.

 

[fish1552]

Also, I'm a programmer, so I got tired of hex editing files manually and dashed off a quick script to do all the hex manipulation of the BMP. Just save the BMP, feed it to this script (assuming you've got Perl on your machine) and it spits out a CG42.smg file.

Ok, stupid question that I'm sure others will have. I type the following (after all the cd... of course) where c:\scripts is the folder I keep this perl script in and script name is MakeCG42FromBMP.pl (no hidden extensions either):

perl c:\scripts\MakeCG42FromBMP.pl

And I get the error about line 9:
"Syntax: MakeCG42FromBMP.pl filename.bmp at c:\scripts\MakeCG42FromBMP.pl line 9."

Maybe I'm not understanding how to "feed" the image to the script. I put it into the same folder as the script and renamed it to filename.bmp just to make this easier not having to modify the script. Also tried renaming BMP and changing the script to match the file name. Probably a Perl noob issue and I was gonna PM you but figured someone else would have the same issue so why not post it.

 

[czerdrill]

i want to do this but i'm a little confused...i dl'd one of the links in the OP and was hoping to just replace with my own image that I created, however, how do I do that? I'm unable to "edit" the SBF file, and I don't know how to throw the image into it. I'm using Ubuntu, fwiw.

 

[FastKatt]

I think this might turn into a MOD that a few of the members might be making files for the masses.
Like having a request topic, you post an image & a helpful member makes the file for your phone.
As it builds, people can "share" by downloading what others have requested in the past.

The reason I say this is because it's a step above...
(just about need a programing background to do it safely)

 

[MotoCache1]

Don't have Perl already, but downloaded Strawberry Perl: Strawberry Perl for Windows. Probably could have just rebooted into Ubuntu though...

I use ActiveState Perl on Windows -- specifically Perl 5.8 Build 827. It really doesn't matter though, especially for a script that simple.

I'll play around with it. Just let us know what compiler you suggest for these files then if you would. I want to modify all the other ones I did to the new exploded versions so people don't need to reflash everything if they use any of them.

I'd say everyone should start with UltraEdit or Frhed and when you can make them that way, then virtually any tool is going to be suitable -- or just keep doing them that way. That is a somewhat tongue-in-cheek response which I will elaborate on in a subsequent post.

Also, I'm a programmer, so I got tired of hex editing files manually and dashed off a quick script to do all the hex manipulation of the BMP. Just save the BMP, feed it to this script (assuming you've got Perl on your machine) and it spits out a CG42.smg file.

Ok, stupid question that I'm sure others will have. I type the following (after all the cd... of course) where c:\scripts is the folder I keep this perl script in and script name is MakeCG42FromBMP.pl (no hidden extensions either):

perl c:\scripts\MakeCG42FromBMP.pl

And I get the error about line 9:
"Syntax: MakeCG42FromBMP.pl filename.bmp at c:\scripts\MakeCG42FromBMP.pl line 9."

Maybe I'm not understanding how to "feed" the image to the script. I put it into the same folder as the script and renamed it to filename.bmp just to make this easier not having to modify the script. Also tried renaming BMP and changing the script to match the file name. Probably a Perl noob issue and I was gonna PM you but figured someone else would have the same issue so why not post it.

Actually, not a stupid question at all, my directions sucked. The script however is telling what you to do. Let's say your BMP file is monster.bmp. If you have ".PL" added to your PATHEXT environment variable on your machine, your command line would then be:

MakeCG42FromBMP.pl monster.bmp

Otherwise, your command line would be:

perl MakeCG42FromBMP.pl monster.bmp

The script would then output a file named monster.bmp.CG42.smg that would be a "code group 42" file that's ready to be used in your SBF.

Sure it's easy to do it by hand in a text editor, and if I had known I was going to solve this with only 2 images, I'd have done that. But I thought I was going to be making about 10 images and it only took about 10 minutes to write the script so it seemed like it was going to save time. At least now I have the script though.

 

[MotoCache1]

Regarding how to modify these SBF's with your own image, this is from the bottom of the OP of this topic:

Please note: The subject and purpose of this topic is the SBF packages contained herein. There are other topics on the forum that discuss how to make your own custom bootloader image and those topics are the appropriate place to support that activity. I do not wish or intend to support that process here in Droid Labs.

The pre-existing topic (not a topic I started) on customizing your own image is here. That said, the SBF compiler in there seems to have an issue with trying to make an SBF that contains only a single code group and RAM downloader. The checksums it is putting in the SBF are wrong and the flash fails. That is a very bad thing.

I made the SBF's in this topic so there would exist a set of properly made SBF's that contained only the bootloader image and not a full flash which wipes out the whole phone (since that is silly). Unfortunately, as I mentioned above, it does not appear that the tool that folks have been using to compile their SBF's is happy with compiling an SBF containing only a single code group, as it is putting the wrong checksums in the file. Presumably that tool works just fine creating full-flash SBF's (if people have been modifying them with it to date which seems to be the case). I don't know. Other than playing with SBF Codec when I was first learning how SBF's worked (and finding it unsatisfactory) I've not really used it.

Honestly, the idea of dozens of people (or more) trying to make their own SBF's is rather unnerving to me. Since there are precious few people that actually understand these files, everybody else has to depend 100% on tools with no published source code to compile the SBF's correctly, and the only way to know if the tool did it right is to flash it on your phone and cross your fingers. If the tool did do it right, awesome - if not, you end up with "Code Corrupted" in the bootloader of your phone. If you're lucky you still have "Ready to Program" and you can just flash a good SBF and be back in business. If you're not lucky you have "Cannot Program" and you now have a "parts phone".

Regarding SBF file creation, I have set a personal restriction on how involved I'm willing to be with assisting others in making SBF's (due to the hazards involved -- both to your own phone and to the phones of others you may share the SBF with). I am willing to do only the following:

• Create custom SBF's to solve specific problems in the least intrusive way possible. I fully regression test my SBF's on multiple OS's, multiple bootloaders, etc., so when I release an SBF, I'm confident it is correct and reliable. If others with the appropriate skill and knowledge use these SBF's to make derivative works, that's cool.
• Time permitting and necessity dictating - make tools that enable people to make relatively risk free changes to a canned SBF to customize a non-critical feature (such as a bootloader image). Were I to make such a thing to facilitate creating your own "bootloader image only" SBF's it would be a web based app where you use the app to upload your BMP, it shows you the BMP as it will look in the flash and has you confirm, and then it builds the SBF from a regression-tested master (with your image), zips it, and lets you download it. The issue with this would be that it would probably be too popular and without some sort of means to control demand the server would be swamped. This is not an insurmountable problem. Maybe this would be a good .apk to run on the phone itself. How cool would it be to have your phone build the SBF?

I'm generally opposed to going further than that for the reasons explained in question #5 of the FAQ toward the bottom of this topic among others.

Please understand that this is 180 degrees opposite my normal position on technology related matters. Ordinarily I want people to know as much as possible about everything they do and use. SBF's are different for two reasons: a) complexity, b) hazard.

Most technology is kind of like building a water pistol -- if you screw it up, maybe you get wet, maybe the wrong person gets wet, maybe it does nothing, but whatever happens, it's not permanent (you'll dry), and life goes on. Teaching people how to make SBF's is more like teaching someone how to make a real firearm. The level of complexity is orders of magnitude higher, and if they do it right, that's great (who doesn't need a good, reliable firearm?), but if they do it wrong they may inadvertently kill not only themselves but other people too (thinking of giving out a defective SBF you haven't tested, accidentally or otherwise).

By way of contrast, an update.zip type file is something completely different. Compared to an SBF, update.zip files are relatively harmless -- they are water pistols. While it is possible to create an update.zip that will brick a Droid 1, you'd have to really really really know what you were doing and do it on purpose, and there is pretty much no way you could do it accidentally. Generally the worst an update.zip can do is trash your OS and baseband and you can always recover with a full flash SBF. I'll teach anybody everything and anything they want to know about making update.zip packages (except how to try to make one that bricks a phone of course).

The issue with SBF Codec producing bad SBF's here (that result in "corrupt code" in the bootloader of the phone) is one excellent example of why I have this policy. I've linked to another in the FAQ question #5 I referenced earlier.

 

[MotoCache1]

I think this might turn into a MOD that a few of the members might be making files for the masses.
Like having a request topic, you post an image & a helpful member makes the file for your phone.
As it builds, people can "share" by downloading what others have requested in the past.

The reason I say this is because it's a step above...
(just about need a programing background to do it safely)

If a couple members get the process worked out so they can reliably produce good SBF's, I'd rather see what you describe than having everybody going and making SBF's and flooding Rescue Squad with "Help, I'm stuck at Code Corrupt in my bootloader" issues. I don't have the cycles (or interest) to volunteer for the task, but perhaps someone would be willing.

 

[Jharmon12]

So basically the best way to do it is the tried and true way of completely reflashing your phone and restoring it from a back up? I have made plenty of these and never had a problem. It only takes like 10 mins and from what i have seen is relativity safe.

Edit: But Im not going to give up on learning how to make these because im board and am always up for learning and the challenge

 

[MotoCache1]

So basically the best way to do it is the tried and true way of completely reflashing your phone and restoring it from a back up? I have made plenty of these and never had a problem. It only takes like 10 mins and from what i have seen is relativity safe.

Edit: But Im not going to give up on learning how to make these because im board and am always up for learning and the challenge

I'm sure you'd expect that I would not agree with that. I would say the best way is to build a proper CG42-only SBF. That may not be the easiest way (at the moment), but it is the best way.

When I think of doing a full nandroid backup, then applying a full flash SBF where I don't want any of the code groups in it except CG42, and then doing a full nandroid restore, the only thing that comes to mind is this (which I said in a PM to someone already which is why I'm quoting):

I think it is kind of like having a wall that's painted up just the way you like it, but you want to hang a picture on it and you need to drive in a nail so you can hang the picture. But the only tool you have is a sledge hammer. So you take a picture of the wall as it is now, and then take the sledgehammer and bash the wall out. Then you plaster up the hole you made, being sure that you install the new nail in the plaster when you do. Then you take the picture of the original wall and repaint the wall the way it was before - except now you've also got your nail with your new picture hanging on it. Sure, it works, and you end up with the nail and the picture, but it would have been a lot better to just put the nail in with the right tool, right?

I realize that in this case, right off the bat the right tool doesn't seem readily available, but that's where hacking comes in. You have in your possession an SBF of your monster bootloader image that works (the one I built) and you have one that doesn't work. You also have your RSD Lite log that tells you the wrong checksum that your SBF claimed, and what the checksum was that was found in the phone after putting the file in. That's a better head start than you usually have on most hacking endeavors. You've already got Frhed (hex editor) for the other steps, so you've got the tools you need to do some pretty cool low level self-educating through experimentation. Personally, that kind of stuff is the good part. Seeing the little picture on the screen after is just a bonus for me.

Like the background color thing earlier. I don't actually care a single bit if I can ever set the background of a bootloader image -- chances are pretty good that I won't be making any more (I'm not a graphics guy). What was interesting however was that obviously something set it, and obviously that something was in the bitmap data of the image because it changes with different images -- so it's like a treasure hunt of sorts. It was challenging and fun, and I learned something -- maybe something not previously known (unlikely in this case). It's kind of like being a binary Indiana Jones. OK, that might be a little much, but that's how it makes me feel.

Honestly, at this point, you are so close to success it's not even funny. You're probably only a checksum value away. That is so close. If you decide you want to tackle it, and don't know where to start, shoot me and PM and I'll mentor you. I'll even test your work in my phone so you're not risking a phone. You won't get a better offer than that.