DroidForums.net is the original Verizon Android Forum! Registered Users do not see these ads. Please Register - It's Free!
Page 2 of 11 FirstFirst 1234 ... LastLast
Results 11 to 20 of 102

Thread: Hacking erroneous output of SBF Codec

  1. Chief Droid Scientist
    MotoCache1's Avatar
    Member #
    83203
    Join Date
    Jun 2010
    Posts
    530
    Liked
    6 times
    Phone
    A855 / MB810
    #11
    Oh, and while you guys were pondering I rewrote my Perl script that makes a proper CG42 out of a BMP file. The previous one you had to do the "mirror" in your image software before saving the file. In this one it does everything for you. You just feed it a 480 x 182, 24-bit BMP, and it spits out a CG42 for you. A super simple way to flash just CG42 on without even making an SBF also dawned on me, but it requires Linux, so I'll save that for a later time.
    Droid 1 - the "unbrickable" droid.
    FRG22D - stock, rooted, ChevyNo1 LV 1.1GHz kernel, SetCPU 2.0.2, Superuser 2.3.6.1

    Droid X, Droid 2, Droid 2 Global (Band Unlocked), Droid Pro Global (Band Unlocked)

    Recommended reading for newbies: How to ask questions the smart way
  2. Chief Droid Scientist
    MotoCache1's Avatar
    Member #
    83203
    Join Date
    Jun 2010
    Posts
    530
    Liked
    6 times
    Phone
    A855 / MB810
    #12
    OK, so we figured out that the first 4 non-matching bytes were in the timestamp from when the SBF was compiled. If we wouldn't have both compiled our files so close together (time wise) even more bytes would have been different, but as it was, only the minute and seconds were different, so only 4 bytes.

    So we have 6 more non-matching bytes. Honestly that should be a little exciting. We only need to figure out how to determine what the value of 6 little bytes should be and we'll know how to manually fix SBF Codec's bad file.

    The remaining bytes are:

    Code:
    0000033E: 87 BB
    0000033F: 7C 18
    0004D355: A1 9F
    0004D356: 1C 75
    0008D372: 7D 7C
    0008D373: A6 87
    Now, honestly, if you've got a real hacker brain, and you've really absorbed everything so far, plus have an idea of what we're after here (I've said it in previous posts, just not emphasized it), some of those numbers should be screaming at you right now. Of those 6 bytes, which ones do we already know one method for figuring out what they should be (if we didn't already have a "good" SBF with right values)?

    That's question 2. We'll stop here until someone gets it.
    Droid 1 - the "unbrickable" droid.
    FRG22D - stock, rooted, ChevyNo1 LV 1.1GHz kernel, SetCPU 2.0.2, Superuser 2.3.6.1

    Droid X, Droid 2, Droid 2 Global (Band Unlocked), Droid Pro Global (Band Unlocked)

    Recommended reading for newbies: How to ask questions the smart way
  3. Master Droid
    Jharmon12's Avatar
    Member #
    65059
    Join Date
    May 2010
    Posts
    257
    Phone
    Moto Droid
    #13
    It looks like some of the bytes are inverted
    Last edited by Jharmon12; 09-08-2010 at 11:11 PM.
    Moto Droid <--Best Phone Ever Made)
    TUD 1.0 Rom
    Slayher's 1.2 ghz
    Check This Out To Change Your Boot Logo (The M) <--- Warning this will put your phone back to 2.0.1 And Is For Educational And Proof of Concept Purposes Only!!

    If you want a quick fix Check out Shibby's Boot Logo Generator.

    If You Like My Work And Wanna Buy Me A Beer (I Like Guinness) PM me!
  4. XOOM RS Team Lead
    fish1552's Avatar
    Member #
    47771
    Join Date
    Mar 2010
    Location
    Savannah area of Coastal Georgia, USA
    Posts
    652
    Liked
    36 times
    Twitter
    fish1552
    Phone
    MOTO X + Nexus 7
    Premium Member
    #14
    Quote Originally Posted by Jharmon12 View Post
    Quote Originally Posted by fish1552 View Post
    My vote for the reason we don't care much is the offsets are relatively close? A total of 4 bytes?

    Not sure my left-brain is letting me see anything else....
    No those bytes are the time stamp and will be different on every file. Use HxD and compare the files ctrl k and open them both and it will be very obvious
    Facepalm! Too easy.



  5. Chief Droid Scientist
    MotoCache1's Avatar
    Member #
    83203
    Join Date
    Jun 2010
    Posts
    530
    Liked
    6 times
    Phone
    A855 / MB810
    #15
    Quote Originally Posted by Jharmon12 View Post
    It looks like some of the bytes are inverted
    Good guess. Not it. Somewhere we know exactly what to replace some of these bytes with (and the data happens to match the "known good" file).
    Droid 1 - the "unbrickable" droid.
    FRG22D - stock, rooted, ChevyNo1 LV 1.1GHz kernel, SetCPU 2.0.2, Superuser 2.3.6.1

    Droid X, Droid 2, Droid 2 Global (Band Unlocked), Droid Pro Global (Band Unlocked)

    Recommended reading for newbies: How to ask questions the smart way
  6. XOOM RS Team Lead
    fish1552's Avatar
    Member #
    47771
    Join Date
    Mar 2010
    Location
    Savannah area of Coastal Georgia, USA
    Posts
    652
    Liked
    36 times
    Twitter
    fish1552
    Phone
    MOTO X + Nexus 7
    Premium Member
    #16

    W.a.g.

    Ok, you said jumping right out at us, soooo......

    I can see the 2 at the end and it looks like it says "=xx". I tried looking at the characters using the number substitution for them, but it didn't really tell me much.

    7C & 7D = 7+12 7+13
    A6 & 87 = 10+6 8+7

    Other than the last 2 offsets are nearly the same much like the time stamp ones. So it looks like the 4 in the middle are the ones that throw us off so much?

    Or am I WAAAYYYY off base and not getting any of it.



  7. XOOM RS Team Lead
    fish1552's Avatar
    Member #
    47771
    Join Date
    Mar 2010
    Location
    Savannah area of Coastal Georgia, USA
    Posts
    652
    Liked
    36 times
    Twitter
    fish1552
    Phone
    MOTO X + Nexus 7
    Premium Member
    #17
    Quote Originally Posted by MotoCache1 View Post
    Quote Originally Posted by Jharmon12 View Post
    It looks like some of the bytes are inverted
    Good guess. Not it. Somewhere we know exactly what to replace some of these bytes with (and the data happens to match the "known good" file).
    I see all the FF FF FF just like we had in the BMP file and CG files when we had to delete the portions.



  8. Chief Droid Scientist
    MotoCache1's Avatar
    Member #
    83203
    Join Date
    Jun 2010
    Posts
    530
    Liked
    6 times
    Phone
    A855 / MB810
    #18
    Quote Originally Posted by fish1552 View Post
    Ok, you said jumping right out at us, soooo......

    I can see the 2 at the end and it looks like it says "=xx". I tried looking at the characters using the number substitution for them, but it didn't really tell me much.

    7C & 7D = 7+12 7+13
    A6 & 87 = 10+6 8+7

    Other than the last 2 offsets are nearly the same much like the time stamp ones. So it looks like the 4 in the middle are the ones that throw us off so much?

    Or am I WAAAYYYY off base and not getting any of it.
    I can see you searching for patterns. This is kind of a side note, but let me tell you about "hex" math.

    If you have the number 7C, you're right that the first digit is obviously 7, and the second digit is "worth" 12, but there's something missing there.

    A quick delve back into base 10 since we're all familiar with it.

    If have have the number 9 it's value is "9". But if I have the number "94", it's not worth 9 + 4 (13). It is actually worth 9x10 + 4*1 because the first column is our "tens" column and the second column is our "ones" column. Most people don't remember (or never knew) but the way we know how much each column is worth is to start at the rightmost column and work to the left.

    The right most column is worth 10^0 (read that as 10 with an exponent of zero). The next column is worth 10^1, then 10^2, 10^3 and so on, forever. Well, any number raised to the zero power is equal to 1. It's one of those "identity" laws or something. Then 10^1 = 10, 10^2 = 100, 10^3 = 1000, and so on.

    So it is in hexadecimal. The rightmost column is worth 16 ^ 0 (which equals 1), then 16 ^ 1 (16), then 16 ^ 2 (256), and so on.

    So, 7C isn't 7+12 (19), it's 7*16 + 12*1 = (112 + 12) = 124.

    OK, now that we've been through all that, I'll go ahead and tell you it has nothing to do with what we're solving. But now you understand hex math a little more.

    OK, how about a hint and then I'm headed to bed and we can pick up tomorrow. Some of those bytes match something in the OP.

    Have a good night!
    Droid 1 - the "unbrickable" droid.
    FRG22D - stock, rooted, ChevyNo1 LV 1.1GHz kernel, SetCPU 2.0.2, Superuser 2.3.6.1

    Droid X, Droid 2, Droid 2 Global (Band Unlocked), Droid Pro Global (Band Unlocked)

    Recommended reading for newbies: How to ask questions the smart way
  9. Master Droid
    Jharmon12's Avatar
    Member #
    65059
    Join Date
    May 2010
    Posts
    257
    Phone
    Moto Droid
    #19
    i knew it had to do something with the check sum but i wasnt sure how to calculate the right one because thats the only difference between the good file and the bad one. The question is how much of the difference between the files really matter?
    Last edited by Jharmon12; 09-09-2010 at 12:29 AM.
    Moto Droid <--Best Phone Ever Made)
    TUD 1.0 Rom
    Slayher's 1.2 ghz
    Check This Out To Change Your Boot Logo (The M) <--- Warning this will put your phone back to 2.0.1 And Is For Educational And Proof of Concept Purposes Only!!

    If you want a quick fix Check out Shibby's Boot Logo Generator.

    If You Like My Work And Wanna Buy Me A Beer (I Like Guinness) PM me!
  10. XOOM RS Team Lead
    fish1552's Avatar
    Member #
    47771
    Join Date
    Mar 2010
    Location
    Savannah area of Coastal Georgia, USA
    Posts
    652
    Liked
    36 times
    Twitter
    fish1552
    Phone
    MOTO X + Nexus 7
    Premium Member
    #20
    ^^^ Bad choice of characters in my substitution of the numbers. I wasn't really adding them, just figuring how they were holding places sort of to search for the pattern. The "+" meaning "&" really. And I guess with my including the "=" it didn't help.

    I saw the
    Code:
    File: 0x7C87, Phone: 0x18BB
    Is that actually TELLING us to put the 18 BB where the 7C 87 are.

    That is just too easy if it is right. 'Course, you DID hit on the "0x" part and you said something about not emphasizing it....
    Last edited by fish1552; 09-09-2010 at 12:13 AM.



Page 2 of 11 FirstFirst 1234 ... LastLast

Links

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Similar Threads

  1. Want better in-call audio? / How-To Change Voice Codec
    By xliderider in forum Android Tech Support
    Replies: 37
    Last Post: 05-21-2011, 06:38 PM
  2. Output to TV??
    By naknak95 in forum Android Audio and Video
    Replies: 4
    Last Post: 08-11-2010, 02:22 AM
  3. Divx codec from motoroi anyone?
    By raydm in forum Android Audio and Video
    Replies: 4
    Last Post: 04-19-2010, 04:01 PM
  4. GPS erroneous
    By greg_p in forum Android Tech Support
    Replies: 2
    Last Post: 12-23-2009, 10:30 AM
  5. USB port output music?
    By richelesro in forum Android General Discussions
    Replies: 2
    Last Post: 11-16-2009, 11:51 AM

Search tags for this page

error verifying code group
,
error verifying code group 32
,

error verifying code group 32 checksums

,
error verifying code group 33
,

error verifying code group 33 checksums

,
error verifying code group checksums
,
mb810 monster file
,
sbf flash checksum error
,
sbf flash unexpected chip 16
,

sbfcodec

Click on a term to search our site for related topics.
Find us on Google+