Making SBF file ?

Discussion in 'Android Hacks and Help' started by tujj99, Apr 22, 2010.

  1. MotoCache1

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    18
    Ratings:
    +1
    Thanks for reminding me to say something about this! Once I noticed that there were two code groups in the SPRecovery_for_ESE81.sbf file I set about figuring out what the second one was (obviously the one of primary interest at the outset was the recovery). The way I figured it out was kinda crafty, but it absolutely is the boot image which is the kernel. So, yes, if you flash SPRecovery_for_ESE81.sbf onto a non ESE81 phone, you're going to mess it up. If you flash SPRecovery_for_ESE81.sbf onto an ESE81 phone that has a custom kernel, they'll go back to stock kernel. Although my new packages have just recovery and no kernel, I would still want to use the package built specifically for the SBF that the phone was originally built from. I built an "ESE81 Clockwork recovery only" and a "FRG01B Clockwork recovery only" file, using the same image on both for the recovery part, but using the HMG and RDL files particular to that build (which are different) and as expected, the resulting SBFs are different. I haven't done testing to know if they are different in a way that matters or not. I'm not afraid of hurting my test phone, so I'll try cross-flashing them and see if it matters. Honestly it may be hard to know for sure if it matters because who knows what action would expose whatever problem might be introduced. Since we have the files and the ability to make a special recovery flash for any release that we have an original SBF for, there's not much reason not to unless we completely prove to ourselves that once the kernel is removed from the SBF it just doesn't matter (but I bet it does). :)
     
    Last edited: Aug 17, 2010
  2. christim

    christim DF Super Moderator Rescue Squad

    Joined:
    Jan 23, 2010
    Messages:
    5,100
    Likes Received:
    2
    Trophy Points:
    153
    Location:
    New England
    Ratings:
    +2
    See if this makes sense. I'm on a stock 2.2 phone and want to root.

    RSD Lite to get sprecovery on, and you get an oddball kernel. As long as you don't boot the phone there should be no issue. You boot into recovery or you boot into the phone (desktop, apps, browser, phone, contacts, etc). If your next step is to put the update.zip onto the root of your card, you can do so from SPRecovery, or if you did it first you also would be ok.

    I think maybe folks are putting on sprecovery then trying to boot up the phone to then mount the phone to get update.zip on their card. They have the wrong kernel for that OS so get stuck and can't mount their phone to get the update.zip onto the phone.

    So the solution is to put update.zip onto the card first, then get sprecovery on the phone and just boot-x into SPR and apply the update.zip file.

    They also could boot into SPRecovery and use the mount option in there to get the file on their card too, without booting the phone os up until after they have flashed a new rom.


    Of course....the real solution is to have multiple sbf files to choose from and to select the right one and/or nicely asking motocache1 for a kernel-free sprecovery sbf file. :)


    I do know there are some folks with mac's on here. Not sure how deep into this they can go. Thanks for the link to get them started MotoCache1

    of course, for the mac owners...

    If such a thing was easy, I'd think someone would have made it already, and for those trying such a thing, I wish you luck and the thanks of our community. ;)
     
  3. MotoCache1

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    18
    Ratings:
    +1
    For anybody who is keeping score, I figured out how to do this. I haven't had time to actually do it, but unless it turns out that the /system code group is signed or something, making a pre-rooted SBF of an entire release (or even a custom ROM for that matter) should be doable.
     
  4. jntdroid

    jntdroid DF Super Moderator Premium Member

    Joined:
    Nov 18, 2009
    Messages:
    6,436
    Likes Received:
    292
    Trophy Points:
    198
    Location:
    TX
    Ratings:
    +292
    Did I understand it correctly (I read this thread LATE last night) that flashing our old faithful ese81 sprecovery .sbf file puts an ese81 kernel on the phone? So, hypothetically, I install a FRG01B based ROM through CW/ROM Manager, then flash that sprecovery, don't flash any other kernel, and it could mess things up a bit?
     
  5. MotoCache1

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    18
    Ratings:
    +1
    I'm pretty tied up at the moment, so my apologies that this reply is so brief, but it is important that everyone is clear about this. The SPRecovery_ESE81.sbf contains the ESE81 kernel in the image. When you flash that SBF to your phone you will be flashing SPRecovery to the recovery partition, and you will also be flashing the ESE81 (Android 2.1) kernel to the boot partition. If "the rest of your phone" isn't on Android 2.1, it wouldn't be surprising if it didn't like that very much. The presence of ESE81 in the name should suggest that the SBF should only be applied to ESE81 phones, but I don't think (prior to now) anybody knew why, thought it was particularly important, or understood what happened if you used it on a phone running another build. Have to run for now.
     
  6. teddyearp

    teddyearp Senior Member

    Joined:
    Jan 13, 2010
    Messages:
    1,800
    Likes Received:
    3
    Trophy Points:
    68
    Location:
    Randle, WA
    Ratings:
    +3
    I've got a ton of info to post in this thread, but for now I will have to say and affirm that the SPRecovery_ESE81.sbf file should NEVER, EVER be attempted on any Droid A855 phone unless it is using ESE81/2.1 firmware already.

    And I just gotta say that this is the MOST intelligent thread I have read to date here @ DF and I have a ton more info that I will try to post in the morning in an attempt to dispell all the rumors so far posted.
     
    Last edited: Aug 19, 2010
  7. MotoCache1

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    18
    Ratings:
    +1
    OK, you've piqued my interest. :)

    Regarding the SPRecovery_ESE81.sbf file, honestly, unless you need to repair your ESE81 kernel, I see no reason for anybody to use it again at this point. As announced in the SBF to root / unroot topic, I've created and released a new SBF file that contains only the recovery partition with SPRecovery in it. You should be able to flash this onto any A855 phone.

    It is linked in the root/unroot OP, but for convenience, here is the link.

    I'm looking forward to the "ton more info" you've got to share. The only thing I fear is that you're going to tell me all the things I just spent the last 30 hours figuring out by brute force observation and reasoning. :) Of course I had a good time and learned a lot, so fire away.
     
  8. Bob Dammit

    Bob Dammit DF Super Moderator

    Joined:
    Dec 11, 2009
    Messages:
    1,709
    Likes Received:
    17
    Trophy Points:
    68
    Location:
    N 42° 05.183 W 079° 10.914
    Ratings:
    +17
    Moto, Im having troubles with SPRecovery on my phone getting nandroid code #!'s. I posted here: http://www.droidforums.net/forum/hacking-help/72279-nandroid-code-31-a.html

    I was planning on trying to manually flash SPRecovery again, and see if that took care of my problem. If I understand what I have read so far, I can take your SPRecovery only sbf file and flash it to my phone, and leave everything else intact?
     
  9. teddyearp

    teddyearp Senior Member

    Joined:
    Jan 13, 2010
    Messages:
    1,800
    Likes Received:
    3
    Trophy Points:
    68
    Location:
    Randle, WA
    Ratings:
    +3
    First off, Gr8 job on your work MotoCache1!. I guess I exagerated, it's not quite a 'ton' of info and not at all technical in nature. I DO hope that there was some testing of your .sbf file before you guys released it into the wild.

    Anyways, Yes Motorola is the ONLY one I know of that can make these .sbf (and .shx, etc.) files, but then with certain tools dedicated hackers can modifiy them as MotoCache1 and mbm have proven.

    Motorola has NOT NOR EVER WILL actually officially release any of these propietary files to the public. That's not to say that there is an employee or two that has leaked them. Yes it gets like a spy novel. The statement that P3Droid knows the most is almost true. He knows the same guy I do that gets these leaks and then removes all traces of the identity of the leaker before forwarding them down the line. This guy has been a giant in hacking Moto phones for years, but prefers not to have much fanfare and quietly hacks away in the background. I know P3Droid has mentioned one of his screen names. He was one of the ones who worked so hard to remove the 'watermarks' on the first .sbf files ever released for the droid at the old alldroid.org site. It was through another mutual bud that I first got pics and learned about the droid last May (i.e. 2009), it used to have a red d-pad and keys with a chrome bezel around the screen. It was also through this group that I was able to aquire an engineering phone, the A4500 "Napoleon" (one of the first [almost] truly unlocked smartphone from the factory); it and the hacking of similar moto 'Q' series phone led VZW to finally go ahead and unlock the internal GPS chip for third party apps, like google maps since it was done for the Nap and only a matter of time for the rest.

    So no, MotoCache1, you didn't waste your time at all, I just wish I had had the time to have been able to help. Now I'm off to read if your efforts were a success . . . .
     
  10. MotoCache1

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    18
    Ratings:
    +1
    Yep - I've installed every ESD56, ESE81, and FRG01B "official SBFs" and then followed them with my "recovery only" package and it has worked great. A few Rescue Squad guys beat on it until they were happy as well. Unfortunately there's only so many scenarios you can throw at it, so there are bound to be wrinkles to work out once a broader audience starts playing with it. We had a couple guys in the root/unroot thread that tried to put it on. At first it wasn't going on, and then it did, but then it spontaneously went away on them. The "not going on" part I think may just be their workstation setup (one is Vista 64 bit, don't know what the other is). The spontaneously reverting back to stock recovery is intriguing. I have some ideas about that that I'm investigating. One of the guys mentioned his bootloader version and it's newer than what's on either of my phones. I have read about certain phones having a copy of the recovery image stored elsewhere on the phone, and each time you boot the recovery image is rewritten. I'm wondering if their newer software has this feature. That could be interesting. In any event, working around that should be no trouble -- I just want to get a better idea about it first (and replicate it if I can). Fortunately the OTA updates can just be unzipped and you can read through the update from start to finish and see what all it is doing. That helps. :)

    Actually I am now able to make an sbf (and the smg files it contains) from scratch. Apparently shx files are another type of sbf-like file and the Droid doesn't use them. The SMG files really aren't that bad once you understand what they are. Catch is they aren't all the same thing.

    [Edit: On re-reading, my comment immediately above, it is misleading. I can't start with nothing and make an SBF out of thin air. I have to know what the SBF looks like for the target phone, what files should contain what, etc. The files that contain file systems and boot images and such can be remade from scratch. The files that contain things like RAM Downloaders and such have to be whatever the manufacturer made for that device. Even though you really are rebuilding the SBF from scratch (as opposed to just hex dumping blocks into the existing SBF) in some ways you're still just modifying the original -- replacing parts with new parts, and removing parts you don't need to update.]

    Thank goodness for the folks who leak stuff to us. Eventually all of these device manufacturers are going to require everything to be signed using strong encryption. At that point, unless someone leaks the encryption keys, we're in big trouble. We're already seeing a taste of that with the latest Moto Droids.
     
    Last edited: Aug 20, 2010
  11. teddyearp

    teddyearp Senior Member

    Joined:
    Jan 13, 2010
    Messages:
    1,800
    Likes Received:
    3
    Trophy Points:
    68
    Location:
    Randle, WA
    Ratings:
    +3
    I have it from my sources that the Moto A855 will NEVER bo locked down (even though the bootloader change got me wondering, as at one time therein was going to be the lockdown) as much as the newer devices; hence the 'rumor' posted in this thread that the A855 was released to be the hacker's choice may be fact.

    I took a look at the other thread this morning and afternoon and see what progress you've been making and again, good job. I MUST agree (and actually stress) with you there especailly when it comes to using the EXACT version of RSD Lite as posted in the OP/guide. We ran into that problem with the razr(s) and the Nap when people 'thought' they could use whatever version of RSD Lite they wanted and NOT the one posted. RSD Lite is VERY FINICKY!! So stick to the guns there and keep up the good work!

    For me, I tried to check out SBF-recalc 1.2 and your .sbf file and forget it. I don't have the time, glad for the community that you (and others) do.
     
  12. MotoCache1

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    18
    Ratings:
    +1
    I used to think it would be impossible for them to lock down the Droid 1. I figured that as long as we had RSD Lite and our trusty SBF files, no matter what they did we could just kick it back a notch and undo it. I know better now. You probably saw my discovery about the new feature in the 2.2 OTA that attempts (in a very weak way) to keep you from permanently changing the recovery partition (you change it and the OS changes it right back). In researching (and defeating) that "feature" one of the things that I was looking at was that the boot loader version on the phone changes from 2C.6C to 2C.7C during the 2.2 OTA as well (the same time the new Flash Recovery Service gets put on). At first I thought somehow the new 2C.7C boot loader was to blame (it's not), so my first effort was to pop on an ESE81 SBF and see if the boot loader went back to 2C.6C. It doesn't. So, the boot loader is not in the SBF file -- at least it's not in the SBF file in a way that puts it in place permanently. A copy of the boot loader is in fact in the SBF file, but it is only used temporarily during the load and then tossed. Believe it or not, even though the official SBF couldn't downgrade the boot loader, I did work out a way to do it. I'm not going to say what it is because there's no point letting "them" know how I do it, but as of right now it can be done. Anyway, if they slipped a boot loader to us in another OTA that was more locked down, and if we couldn't back it out, then that could be somewhat problematic. Now why they would bother at this point is another question entirely. Whether or not they will ever try to lock it down solid I don't know. Whatever they do would have to be in rewritable memory (unlike the D2 and DX) so I think the right person could always undo it, but they could make it a lot more difficult.

    Sadly I don't think most folks really understand or appreciate the sensitive nature of what they are doing when they are mucking about with the phone's brains. When you're replacing critical areas of the system on these phones it's basically trying to replace the brain while using the brain to help with the replacing. Brain surgery requires exacting tools and exacting methods. If you deviate from the tried and true norms and methods, then you're asking to be an "exception". Honestly, sometimes our methods haven't been so great either due to lack of understanding of what exactly the tool is that we are holding in our hands. Unfortunately we can't always help it if the tool is given to us via a leak and we don't have anybody to ask questions of. The ESE81_SPRecovery.sbf is a good example. It had gotten to the point where folks routinely ignored the "ESE81" part of that and just applied it to any old OS version (and ended up in a bad situation immediately thereafter). We now know (kind of by luck that I stumbled across it when doing my psycho absorption of all things SBF) that the ESE81_SPRecovery contains (and installs) the ESE81 kernel. That's a pretty important thing to know if you're going to use the tool effectively. Again, unfortunately all of our tools don't necessarily come with manuals and we do the best we can with what we've got.

    Heck, now that I know how the update.zip files and SBF files work inside and out, I take apart every single one of them before doing anything with it just to see what's in there and what it's going to do to my phone.

    Yeah - I don't even know if I could readily enumerate all of the technological concepts that must be completely understood to play with those SBF files, but whatever the list is, you're right, it can consume a massive amount of time. I was missing the piece about how the yaffs2 file system, and the Linux boot image/ramdisk files were constructed, torn apart, and put back together. Fortunately in an open source environment, those aren't really secrets so I could learn everything I needed about it pretty quickly. At this point I think the only files I can't slice and dice apart, modify, and put back together are things like the RAM downloader which is binary code that runs right in the CPU. I'm guessing that I won't ever need to write a new RAM downloader, so that's a limitation I can live with.

    A lot of the SBF stuff is more intuition than intellect. There are lots of little clues and tests you can use to try to answer the question "what the heck is this code group for, what format is it in, and how do I play with its guts?". Once you know what it is and how it's constructed, you can rework it to make it do something new and wonderful, or stop doing something old and horrible. :)

    Anyway, thanks for the various updates of info. from your sources. It is always interesting.
     
    Last edited: Aug 22, 2010
  13. teddyearp

    teddyearp Senior Member

    Joined:
    Jan 13, 2010
    Messages:
    1,800
    Likes Received:
    3
    Trophy Points:
    68
    Location:
    Randle, WA
    Ratings:
    +3
    Hmmm, yes as I said above, it is the bootloader where the D2 and DX are locked and they may still try doing it on the D1. Sources of inside information are not always privy to ALL the information in every part of the engineering department. Keep fighting the good fight.
     
  14. MotoCache1

    MotoCache1 Chief Droid Scientist

    Joined:
    Jun 30, 2010
    Messages:
    530
    Likes Received:
    1
    Trophy Points:
    18
    Ratings:
    +1
    Well, they can try all they want, but they'll lock down my Droid when they pry it from my cold, dead fingers. :)

    I'm never taking an OTA from them (especially not without dissecting it first), so that should keep my device safely out of Skynet's reach.

    I should also say, that I will never buy a product from them that is locked down such that we can't, at a minimum, apply our own bug fixes, etc. I don't necessarily need to run full custom ROMs and such, but when they do an "upgrade" and it breaks something really important to me (like they did with Pandora), if I can't go in and edit a single line in a stupid text file to implement the fix, that just won't work for me. I'll buy a developer Nexus One (even if it costs $600) before I'll buy something I'm locked out of. If Motorola is going to stick to their guns and keep all their consumer products locked down tight from now on, then they should at least offer a single model that is open for developers, and sold to registered developers at full price (like the Nexus One is).
     
  15. P3Droid

    P3Droid Member

    Joined:
    Oct 30, 2009
    Messages:
    134
    Likes Received:
    0
    Trophy Points:
    16
    Ratings:
    +0
     
    Last edited: Aug 23, 2010
Search tags for this page

create sbf file

,
droid a855 .sbf file
,
how to create a file from my files on droid
,

how to create a sbf file

,

how to create an sbf file

,
how to make a sbf file
,
how to make sbf file
,
make sbf file
,
sbf smg
,
sbf-recalc