[SIZE=-2][ I realize this post doesn't belong here - shout me down after you've read the post ][/SIZE]
[gratuitous-begging]
Hi folks,
If you are publishing ROMs or other installable .ZIPs please please please (yes, I'm begging now) publish MD5 checksums (or at least an exact byte count) of the files you upload for public consumption in the posts in which they are announced. Both would be even better.
The problem isn't one of authenticity of download files (although it is useful to have that); it's that a tremendous amount of "help me" board traffic gets generated (both here and at AF) by folks complaining that they have a problem installing a ROM, when the real trouble they are having is corrupted files. I would be willing to bet that more than 90% of this traffic is caused by people attempting to flash truncated or otherwise corrupted files.
Yes, I know - if they would just pay attention to the fact that "E:" means ERROR in Amon_RA output, we would all be better off. That's hoping for a lot from newbs, though.
But honestly, if you don't publish a byte count or a checksum, those folks can't really check their downloads, even when they do know better. ( Some of the download sites report the download size, but usually only to 3 or 4 significant figures, and with no clear indication of whether MB means 10^6 or 1024^2. )
Many of the devs don't spend much time in the XDA Q&A or General sub-forums, and possibly never on AF, so they don't see this going on; that is to be expected and OK, too, because they are busy building ROMs and other goodies.
But, you can help the folks that are helping other folks get rooted in order to enjoy your work product if we can encourage a culture where people routinely check their downloads - using their phone! - to make sure that your good stuff has arrived safely on their SD cards.
With the help of jcase and Eclips3, user "scary alien" from AF put together a free app for computing MD5 or SHA1 checksums on the phone. There are lots of other ways to skin that cat, too; but the place to start encouraging a culture of having people check their downloads is with the devs - at their announcement posts.
Thanks for your time and consideration.
[/gratuitous-begging]
bftb0
good idea. would help those who have corrupted downloads.
bftb0,
Wonderful thread / post. Thank you very much--this is much appreciated.
By the way, I am working on trying to make the MD5 sum app a little more user-friendly by making the file selectable instead of having to type in the filename (I'm still learning about Android app development......thanks again to jcase and eclips3 for getting me started). I'll try to re-post here when (if?) I ever get this enhancement made.
We all very much appreciate all of the hard work and fruits of labor that you developers produce. Thank you!
scary alien said:
bftb0,
Wonderful thread / post. Thank you very much--this is much appreciated.
By the way, I am working on trying to make the MD5 sum app a little more user-friendly by making the file selectable instead of having to type in the filename (I'm still learning about Android app development......thanks again to jcase and eclips3 for getting me started). I'll try to re-post here when (if?) I ever get this enhancement made.
We all very much appreciate all of the hard work and fruits of labor that you developers produce. Thank you!
Click to expand...
Click to collapse
You might consider putting the byte count in the result display along with the checksum; if you get those two mods put together, you should make an XDA-wide announcement as something this generic is useful to all XDA (Android) users. Take it one step further - and add a "ROM verify (only)" function, and everyone at XDA will know your (screen) name.
Jp50 -
Check out this tangentially related thread. I wonder if your problem the other day with Nonsensikal was due to a similar problem - corruption of the ROM not on the SD, but in system flash (NAND).
One more tidbit, I suppose I should come clean about, it seems about time.
bftb0 == erisuser1 (on AF)
That should explain my motivation for begging this way. Just a historical accident that it worked out that way - i tried not to let the two become cross-forum sockpuppets, but sometimes that was inevitable
bftb0/eu1
Sheer elegance... I should have known it was you eu1!
Great post.
bftb0 said:
You might consider putting the byte count in the result display along with the checksum; if you get those two mods put together, you should make an XDA-wide announcement as something this generic is useful to all XDA (Android) users. Take it one step further - and add a "ROM verify (only)" function, and everyone at XDA will know your (screen) name.
Click to expand...
Click to collapse
eu1/bftb0, lol! I am floored! But not too shocked...how do you find the time?
The byte-count (shown as "File Size:") is already present...I actually created this app in no small part of your exhortations for checking MD5s over at AF -- I knew better than to not include something so vital per your tutelage.
Also, for those that don't know, you can also check your MD5 checksums via Astro File Manager (long-press a filename and select Details). There is also a free app in the Market, ManD5 that will also compute MD5 sums (it did not work (at least for me) when I first wrote my little app, but it does now). And, of course, in some ROMs, the busybox/md5sum program is often available.
However, mine will also calculate SHA1 checksums (which do take much longer to calculate and are more compute-intensive).
Cheers everyone!
This should get stickied or something. We should also get in the habit of asking devs for MD5s if they don't provide them initially. I think you're right; a massive amount of traffic (and headaches!) could be spared if we would do this.
I will provide md5's for future releases I have no problem with posting them but I think the expectation that this will somehow reduce the number of newbie questions/issues is unrealistic. The fact of the matter is that people just don't take the time to read/understand what it is that they are doing. I appreciate the effort here but I just don't see it making a difference. You love my rants don't you? lol
We'll see
Sent from my nonsensikal froyo
listyb01 said:
I will provide md5's for future releases I have no problem with posting them but I think the expectation that this will somehow reduce the number of newbie questions/issues is unrealistic. The fact of the matter is that people just don't take the time to read/understand what it is that they are doing. I appreciate the effort here but I just don't see it making a difference. You love my rants don't you? lol
We'll see
Sent from my nonsensikal froyo
Click to expand...
Click to collapse
yeah i agree here....even though grdlock site where i upload my roms automatically displays the md5sum i just doubt that people who won't even use the search function will bother to check the md5
listyb01 said:
The fact of the matter is that people just don't take the time to read/understand what it is that they are doing. I appreciate the effort here but I just don't see it making a difference.
Click to expand...
Click to collapse
That's probably correct, but you will be reducing the effort of the folks that are trying to help the newbs out, and know better.
Right now what they have to do - in addition to instructing the newb where to get an app that will report file size or md5sum for a ROM file is to: download the ROM themselves, run it through "jarsigner --verify" to see if their own download is OK (signing check), and then compute the MD5 and report that back to the newb. It would be a lot easier to just say:
"Use Astro to compare the MD5 signature of the file on your SD card to what the dev published".
In addition, it helps a little bit with the authenticity problem, too - if someone finds a file on a mirror someplace, they can go back and check the dev's post to gain some confidence what they found is actually "the real deal". Right now that's an impossibility with some dev ROMs.
cheers,
bftb0
bftb0 said:
That's probably correct, but you will be reducing the effort of the folks that are trying to help the newbs out, and know better.
Right now what they have to do - in addition to instructing the newb where to get an app that will report file size or md5sum for a ROM file is to: download the ROM themselves, run it through "jarsigner --verify" to see if their own download is OK (signing check), and then compute the MD5 and report that back to the newb. It would be a lot easier to just say:
"Use Astro to compare the MD5 signature of the file on your SD card to what the dev published".
In addition, it helps a little bit with the authenticity problem, too - if someone finds a file on a mirror someplace, they can go back and check the dev's post to gain some confidence what they found is actually "the real deal". Right now that's an impossibility with some dev ROMs.
cheers,
bftb0
Click to expand...
Click to collapse
I see the value here.
Man I need to get out more, didn't really realize that this was such a hot topic Now back to building v5.3 with md5
Sent from my nonsensikal froyo
listyb01 said:
I see the value here.
Man I need to get out more, didn't really realize that this was such a hot topic Now back to building v5.3 with md5
Click to expand...
Click to collapse
\m/
It's probably just a hot topic to me. You wouldn't believe how hard it is sometime to extract diagnostic information from a newb
:|
bftb0 said:
\m/
It's probably just a hot topic to me. You wouldn't believe how hard it is sometime to extract diagnostic information from a newb
:|
Click to expand...
Click to collapse
...but you're good at it.
As a semi-noob - perhaps the noobs would get more benefit if there were some instructions on what to do with the md5 on the rom page. The developer could use the instructions of his choice and the noob would follow them blindly as long as they're detailed enough. It could be a little tack on at the end of the disclaimer (or wherever they wana put it).
Sent from my Froyo Eris using XDA App
bftb0 said:
...Take it one step further - and add a "ROM verify (only)" function...
Click to expand...
Click to collapse
You mean something like recognizing when a ROM (.zip) name is entered or selected and calculating its MD5 sum and file size against a known, published value?
This would be pretty straightforward (I think...). I could initially just keep an internal table of the ROM names/size/MD5 sums and later, try to acquire this info dynamically from some public source...
Am I in the ballpark here?
Thanks!
edit: would the "jarsigner --verify" method be available to me in my app? (or is that what you had in mind all along?)
scary alien said:
edit: would the "jarsigner --verify" method be available to me in my app? (or is that what you had in mind all along?)
Click to expand...
Click to collapse
Exactly that functionality (but obviously not any Sun/Oracle code). What I don't know off the top of my head is whether or not the Google API provides sufficient functionality to implement it without resorting to a native method. That would make it more portable to other devices (if it is possible).
The native code for doing all the un-.zipping, and signing checks is in the AOSP sources (and elsewhere, e.g. CyanogenMod, Clockwork) available through github etc. From there it is only a "simple matter of programming"
bftb0
Okay, I think I'm fairly close...would you consider the verifying the SHA1 digests from the META-INF/MANIFEST.MF file against each file in the .jar/.zip as "verification"?
I'm a little shaky on the certificates and such, but I think I can do the validation of each file listed in the MANIFEST.MF file. There is the matter of the CERT.SF file whose checksums I can't (yet ) match-up with anything...
Thoughts?
scary alien said:
Okay, I think I'm fairly close...would you consider the verifying the SHA1 digests from the META-INF/MANIFEST.MF file against each file in the .jar/.zip as "verification"?
Click to expand...
Click to collapse
Okay, yeah, its probably silly to quote yourself p), but I've got Java code that works. It reads a .jar file, inspects the MANIFEST.MF file, and calculates the SHA1 digest for each file listed in the manifest. Still gotta incorporate it into my app, but should be pretty straight-forward to do...(oh, and convert the hex SHA1 sums into base64, but my app is already coded to do that).
Stay tuned...(hopefully by tomorrow night)
Here's a test run of my code against Zanfur's overclock patch jar file and the fciv-generated SHA1 digests for the extracted directory:
Code:
d:\temp >[COLOR="blue"][B]java JarVerify kernel-overclock-update-v3.zip[/B][/COLOR]
jar file = d:\temp\kernel-overclock-update-v3.zip
File: [B]boot.img [/B][SHA1 base64 checksum: t4mIp5wAG9kIwTVE+I07BUBFtDE=]
SHA1 (hex) checksum: [COLOR="Red"]b78988a79c001bd908c13544f88d3b054045b431[/COLOR]
SHA1 (base64) checksum: t4mIp5wAG9kIwTVE+I07BUBFtDE= (from MANIFEST.MF)
File: META-INF/com/google/android/[B]update-script [/B][SHA1 base64 checksum: nyfFfx8UMymvIfBVT/6M6stjyjs=]
SHA1 (hex) checksum: [COLOR="red"]9f27c57f1f143329af21f0554ffe8ceacb63ca3b[/COLOR]
SHA1 (base64) checksum: nyfFfx8UMymvIfBVT/6M6stjyjs= (from MANIFEST.MF)
File: system/lib/modules/[B]wlan.ko [/B][SHA1 base64 checksum: WwY9Y+I3ziLsQMDfr6S3wmGn2bs=]
SHA1 (hex) checksum: [COLOR="red"]5b063d63e237ce22ec40c0dfafa4b7c261a7d9bb[/COLOR]
SHA1 (base64) checksum: WwY9Y+I3ziLsQMDfr6S3wmGn2bs= (from MANIFEST.MF)
d:\temp>[COLOR="Blue"][B]fciv -r -sha1 "d:\temp\kernel-overclock-update-v3"[/B][/COLOR]//
// File Checksum Integrity Verifier version 2.05.
//
Start Time: 09/08/2010 at 23h54'34''
[COLOR="red"]b78988a79c001bd908c13544f88d3b054045b431 [/COLOR]d:\temp\kernel-overclock-update-v3\[B]boot.img[/B]
1a93b9f8dc0e3a7db4d62e1c28e34e377ab59a53 d:\temp\kernel-overclock-update-v3\META-INF\CERT.RSA
9d109bf59721f29b2e6ed90780e1e98e5aa6bf1a d:\temp\kernel-overclock-update-v3\META-INF\CERT.SF
[COLOR="red"]9f27c57f1f143329af21f0554ffe8ceacb63ca3b [/COLOR]d:\temp\kernel-overclock-update-v3\META-INF\com\google\android\[B]update-script[/B]
0e6fdf73ab53327c944a9430b090e388f76b60a1 d:\temp\kernel-overclock-update-v3\META-INF\MANIFEST.MF
[COLOR="red"]5b063d63e237ce22ec40c0dfafa4b7c261a7d9bb [/COLOR]d:\temp\kernel-overclock-update-v3\system\lib\modules\[B]wlan.ko[/B]
End Time..: 09/08/2010 at 23h54'34''
Processed 8 directories
Processed 6 files
Errors have been reported to fciv.err
d:\temp>
Its coming!!! (probably not tonight, though )....I've got my MD5sum app coded with the ability to verify all of the SHA1 checksums in a jar file's MANIFEST.MF.
I've gotta cleanup some code and make the interface invoke the jar verification as a separate option from the ones currently available.
Interesting things I've found while testing and doing some research:
1. There are usually two phases to a "jarsigner.exe -verify". Certificate verification and MANIFEST file checksum verification. It appears that -verify does not cause/force certificate validation. The second phase is pretty much does what my app does/will do: scan through the manifest and validate the manifest's entry's SHA1 digests. My app will initially not check certificates--just the individual manifest's digest verification.
2. The Eris 2.1 leaks ROMs (base root and the three non-root leaks) are not jars per se: they do not contain a META-INF directory and therefore there is no MANIFEST.MF to scan. Only a filesize and checksum verification is apparently needed or used on these PB00IMG.zip files.
3. I successfully verified Ivan's 1.0 ROM (100MB) on my Droid X...it took around 3 minutes (will obviously take longer on the Eris...).
Here's a ddms trace of my app scanning the same kernal-overclock-update-v3.zip (renamed to koc.zip to make typing it in easier/quicker):
Code:
09-09 23:31:35.302: INFO/MD5sum(5191): jar file = /sdcard/download/koc.zip
09-09 23:31:35.302: INFO/MD5sum(5191): File: system/lib/modules/wlan.ko [base64 SHA1: WwY9Y+I3ziLsQMDfr6S3wmGn2bs=]...verifying checksum...
09-09 23:31:36.029: INFO/MD5sum(5191): SHA1 (hex) checksum: 5b063d63e237ce22ec40c0dfafa4b7c261a7d9bb
09-09 23:31:36.029: INFO/MD5sum(5191): SHA1 (base64) checksum: WwY9Y+I3ziLsQMDfr6S3wmGn2bs= (from MANIFEST.MF)
09-09 23:31:36.029: INFO/MD5sum(5191): SHA1 (base64) checksum: WwY9Y+I3ziLsQMDfr6S3wmGn2bs= (calculated)
09-09 23:31:36.037: INFO/MD5sum(5191): SHA1 checksum matches MANIFEST.MF (w00t)
09-09 23:31:36.037: INFO/MD5sum(5191): File: boot.img [base64 SHA1: t4mIp5wAG9kIwTVE+I07BUBFtDE=]...verifying checksum...
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 (hex) checksum: b78988a79c001bd908c13544f88d3b054045b431
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 (base64) checksum: t4mIp5wAG9kIwTVE+I07BUBFtDE= (from MANIFEST.MF)
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 (base64) checksum: t4mIp5wAG9kIwTVE+I07BUBFtDE= (calculated)
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 checksum matches MANIFEST.MF (w00t)
09-09 23:31:38.091: INFO/MD5sum(5191): File: META-INF/com/google/android/update-script [base64 SHA1: nyfFfx8UMymvIfBVT/6M6stjyjs=]...verifying checksum...
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 (hex) checksum: 9f27c57f1f143329af21f0554ffe8ceacb63ca3b
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 (base64) checksum: nyfFfx8UMymvIfBVT/6M6stjyjs= (from MANIFEST.MF)
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 (base64) checksum: nyfFfx8UMymvIfBVT/6M6stjyjs= (calculated)
09-09 23:31:38.091: INFO/MD5sum(5191): SHA1 checksum matches MANIFEST.MF (w00t)
Cheers!
Ill publish these and make a sticky about it with detailed instructions on how's to check an MD5. If someone could PM me the list that would be a big help.
Cheers!
Ck
Sent from my Droid using XDA App
Captainkrtek said:
Ill publish these and make a sticky about it with detailed instructions on how's to check an MD5. If someone could PM me the list that would be a big help.
Cheers!
Ck
Sent from my Droid using XDA App
Click to expand...
Click to collapse
Captainkrtek,
bftb0 / eu1 included a link to a thread I created on AF (http://androidforums.com/htc-droid-eris/138831-verify-your-files-md5-checksums.html) in the OP (http://forum.xda-developers.com/showpost.php?p=7919706&postcount=1) that details various ways to check a file's MD5s checksums. Version 1.0 of my app simply calculated MD5 or SHA1 checksums against a specified file. There are several easy ways to get MD5s on the phone itself, as I detailed in the thread on AF.
Via bftb0/eu1's idea/suggestion, I'm very close to releasing an update to the app (v2.0) I wrote that will essentially do a 'jarsigner -verify' function against a jar (custom ROM)--at least the verification of the SHA1 digests of the files listed in the jar's manifest. This should take the guesswork out of knowing whether or not a user has successfully downloaded a complete/uncorrupted custom ROM (or otherwise signed jar file).
Last weekend, I posted a thread (http://androidforums.com/eris-all-things-root/168942-phone-rom-checksum-verifier.html) re. v1.1 of my app that was basically a brute-force approach to ROM verification. I created a table that the app loaded and compared against the checksum of the specified file to check its validity.
Anyway, I'm hunkering-down this evening trying to finish what my last two posts have detailed re. the v2.0 version of my app. My biggest hurdle is my unfamiliarity with Android development ))...I want to make it more user-friendly by not requring that the filename be inputed by hand, but instead allowing a file to be selected. I got just a little bit more testing and verification to do.
I'll be soliciting feedback and folks to test the app out and let me know what they think.
Thanks and cheers!
I flashed the UK sbf via RSDLite and then when I tried flashing the brazil sbf again I could not, right now I can no longer flash via RSDLite. Keeps on gettiing a 0x71000 error.
info5i2002 said:
I flashed the UK sbf via RSDLite and then when I tried flashing the brazil sbf again I could not, right now I can no longer flash via RSDLite. Keeps on gettiing a 0x71000 error.
Click to expand...
Click to collapse
I was running into the same problem, with Win7 x64, RSD Lite 4.6, latest drivers. Did some investigation into the error log and looks like I found a bug in their programming. Go into the directory you installed RSD Lite (for Win7 x64 the default is C:\Program Files (x86)\Motorola\RSD Lite\) and look for a file that starts with "FlashErrorLog". Open it, and if you see something like this:
Code:
Code:
Line: 865
ERROR: \\?\c:\SPRecovery_ESE81.sbfwtƒyoþÿÿÿ‚qawñrawðiµ was not found.
File: X:\test_dev_usb\flash\code\flashdll\PST_FP_FlashFi leIO.cpp
then you are experiencing this same bug that I had (looks like adr3nalin3 had this problem too). For those fellow programmers out there, looks like they are copying the filename into uninitialized memory and not explicitly adding the NULL terminator, meaning it's pure luck whether the filename is recognized or not. Since the uninitialized memory produces random results, this explains why people have had it work after restarting their computer, trying several times, using a different computer, etc. Hopefully if you follow my instructions below, you will be able to make it work right away.
So the work around for this problem is to rename the file so that the real filename overwrites all the unwanted junk characters at the end. These junk characters are random, and they are likely to change each time you open RSD Lite.
Here are step by step instructions:
Go to the folder where you installed RSD Lite
Delete any files that start with "FlashErrorLog"
Right click on "SDL.exe" and click "Run As Administrator"
Move your recovery file to the root C:\ directory
Rename the recovery file to something short, like "r.sbf", so that you will have space left for the filename to overwrite the junk characters
Try flashing the file with RSD Lite - it will most likely fail, don't worry (if it works then good job, you are lucky )
In the RSD Lite folder, open the newly created FlashErrorLog... file
Count the number of junk characters after the real filename - for example if you have this error:
Code:
Code:
ERROR: \\?\c:\r.sbfqawñraï was not found.
then the junk characters are "qawñraï" and there are 7 of them, so we are going to add 7 extra letters to the real filename
Rename the file to add the same number of letters/numbers as junk characters in the log file. In this case, we need to add 7, so change the filename to something like "r1234567.sbf" - make sure you add the characters BEFORE the file extension (".sbf"), not after!
Point RSD Lite to the renamed file, click Start, and it should work!
Note that some of the junk characters can't be displayed in the log, so there might actually be 8 of them when you can only see 7, etc. Just repeat the process from step 6, adding 1 character at a time (don't remove any), and it should work after a few tries.
Note that just making the filename really long won't work, you need to be precise so that you only overwrite the extra stuff, nothing more and nothing less.
Click to expand...
Click to collapse
Find Original post here: http://androidforums.com/droid-all-things-root/74153-if-you-get-failed-flashing-process-0x7100-rsd-lite.html
At #32 reply.
I just mis-clicked thanks when I want to quote your post.
Haha I returned the favour by thanking you too. By the way, all I had to do was to delete the error logs and then enter the
Code:
cd C:\Program Files\Motorola\RSDlite\
SDL.exe -f [FILENAME].sbf -t 2
and it starting flashing again.
Good luck!
OK i got a MT4 so i flashed the engineering bootloader, since it wasn't my first mytouch 4, i already had the files in my computer, so somehow my files got corrupted thanks to the new SSD technology, so now i have a phone that won't turn on at ALL.
Any way to recover from this one or the board is tossed? any way to save it with a JTAG?
thx
greenstuffs said:
OK i got a MT4 so i flashed the engineering bootloader, since it wasn't my first mytouch 4, i already had the files in my computer, so somehow my files got corrupted thanks to the new SSD technology, so now i have a phone that won't turn on at ALL.
Any way to recover from this one or the board is tossed? any way to save it with a JTAG?
thx
Click to expand...
Click to collapse
I don't know of any way to save it through software. You'd need the bootloader in order to use fastboot.
Advice for everyone:
Before you flash that bootloader, verify it by comparing it's md5 checksum to the one provided in grankin's thread. If you can't find it, this is it:
Code:
md5sum: df4fd77f44993eb05a4732210d2eddc6
I check mine at least once before and ALWAYS check after flashing. Here's how:
1. On your computer, after downloading. Mac/Linux users can probably do checksums in terminal. I downloaded a checksum utility for Windows that adds a checksums tab when I right-click >> properties on any file.
2. On the phone with terminal emulator. Assuming you pushed the file to /data/local, open terminal emulator and do this:
Code:
cd /data/local
md5sum hboot_dhd.nb0
If what you get does not match the above, re-download the file.
3. After flashing. You can enter the path of the bootloader as the argument for md5sum. This is ALWAYS a good idea to make sure it was written properly, even if you checked it already in /data/local. The command (in terminal emulator) is this:
Code:
md5sum /dev/block/mmcblk0p18
If what you get does not match the above, DO NOT REBOOT THE PHONE. Re-download the file if you have to and flash again. Only reboot if md5sum matches the above.
jdkoren said:
I don't know of any way to save it through software. You'd need the bootloader in order to use fastboot.
Advice for everyone:
Before you flash that bootloader, verify it by comparing it's md5 checksum to the one provided in grankin's thread. If you can't find it, this is it:
Code:
md5sum: df4fd77f44993eb05a4732210d2eddc6
I check mine at least once before and ALWAYS check after flashing. Here's how:
1. On your computer, after downloading. Mac/Linux users can probably do checksums in terminal. I downloaded a checksum utility for Windows that adds a checksums tab when I right-click >> properties on any file.
2. On the phone with terminal emulator. Assuming you pushed the file to /data/local, open terminal emulator and do this:
Code:
cd /data/local
md5sum hboot_dhd.nb0
If what you get does not match the above, re-download the file.
3. After flashing. You can enter the path of the bootloader as the argument for md5sum. This is ALWAYS a good idea to make sure it was written properly, even if you checked it already in /data/local. The command (in terminal emulator) is this:
Code:
md5sum /dev/block/mmcblk0p18
If what you get does not match the above, DO NOT REBOOT THE PHONE. Re-download the file if you have to and flash again. Only reboot if md5sum matches the above.
Click to expand...
Click to collapse
Wow, thank you for this!
Phateless said:
Wow, thank you for this!
Click to expand...
Click to collapse
+2 same here
Phateless said:
Wow, thank you for this!
Click to expand...
Click to collapse
No problem, if it helps people avoid bricking their phones.
greenstuffs said:
OK i got a MT4 so i flashed the engineering bootloader, since it wasn't my first mytouch 4, i already had the files in my computer, so somehow my files got corrupted thanks to the new SSD technology, so now i have a phone that won't turn on at ALL.
Any way to recover from this one or the board is tossed? any way to save it with a JTAG?
thx
Click to expand...
Click to collapse
Same here. Screen lights up but just blank when power button is pressed. Power + volume down doesn't work. Power +volume up makes the phone vibrate though but I dunno what that means. PC can't detect the unit via USB, tried ADB devices but no success.
Bricked forever? what's the cure??? help?
https://accounts.google.com/signin/...dSession#folders/0B9t5VvCjiCO-Qm9Bb29PdzdHajQ
That's the link. You get the shortcode link when trying to flash the Turbo 2 using fastboot Linux command line. I first found some other cool tricks I have never seen mentioned about the fastboot oem command and some certain characters, but I suspect it is not related.
I got in, I noticed they just did an update to all the files, I downloaded everything, aa zip of all of it, and promply lost access. I have a spreadsheet open in google docs describing the updates. You can see at the top that it says that permissions have changed.
binwalk: Did I really find a boot img? Also: Legal advice?
Here's what binwalk just found (edit's mine til I know legal deal):
Code:
1###1#0 0x1#ABC# Android bootimg, kernel size: 1871876996 bytes, kernel addr: 0x###4#F#E, ramdisk size: 1953406600 bytes, ramdisk addr: 0x6###6##0, product name: "reating boot image..."
1##6##0 0x10#ABC Unix path: /../../target/product/%s/%s
The hexadecimals (mem addrs?) are actuallly there. I have adjusted the sizes, but if you know them you could figure out they are legit and my edits were simple.
can you please upload this onto this post or zippyshare or some other place. dumbass google made it so you have to have a Motorola email address to login