[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!
Related
There are small differences between the OTA-2.1 and the Leak-V3. Tiny might be a better adjective.
This involves two files which are present (post install) in the OTA-2.1 which are not present in the Leak-V3 PB00IMG.ZIP file, and two files which are in the Leak-V3 PB00IMG.ZIP ROM file not present in OTA-2.1.
After a short background, I give my results. (For those with a high tolerance for boredom a complete description of the methodology I used follows that.)
Background
Back in mid-May, thenestor compared a significant fraction of the files in the OTA-2.1 http: download to the files unpacked from the Leak-V3 PB00IMG.ZIP.
Two days ago I extended that check to include all files, including those which undergo binary patching on the phone during the OTA-2.1 install. (This patching is performed by the HTC recovery boot as part of the OTA-2.1 install).
Summary of Results
The essential result is the strengthening of the conclusion that OTA-2.1 and Leak-V3 are identical. By file count, there are 4 differences among 813 files - a 99.5% match. There are no instances where there are two versions of the same file between the two installs.
The "system" partition of OTA-2.1 is essentially identical to Leak-V3, with the exception of 2 files which are present in OTA-2.1, and missing in Leak-V3.
The boot and recovery partitions are 100% identical.
The Leak-V3 install wipes clean the pre-existing /data mount point, and installs only two files into /data; these two files are not found post-install in the OTA-2.1.
Detailed Results
system partition ( /system mount point )
100% of files in the Leak-V3 /system partition identically match files in the post-install OTA-2.1 /system.
There are 2 files present in the /system folder of the OTA-2.1 which are not present in the Leak-V3 release:
/system/app/UpgradeSetup.apk
/system/xbin/modem_link
Based on name alone (rather than trying to decipher classs.dex within UpgradeSetup.apk by de-odexing) it seems reasonable that the OTA-2.1 upgrade only needs "partial" setup because it is an overlay rather than a wipe. Perhaps that is why this "app" is not present in Leak-V3.
The latter file - /system/xbin/modem_link ? I don't know what it does; it has some rather curious string data in it.
data partition ( /data mount point )
The OTA-2.1 process contains no files which are loaded into the /data partition, and only deletes unneeded cache and application parameter settings within the pre-existing /data partition; this is done under control of the update-script.
The leak-V3 ROM, which is a "wipe" or "factory reset" type of operation, drops only two files into the /data partition:
/data/app/PingTool.apk
/data/local/dmdata/00004
Neither of these files are found in a (clean MR2 to) OTA-2.1 phone's /data partition following completion of the OTA-2.1 upgrade. I do not know what role these files play - the classes.dex files and some of the .xml files in the .apk suggest an IP-layer network diagnostic capability (ping, traceroute), as well as IP route manipulation.
boot, recovery partitions
As mentioned previously - bit-by-bit identical between Leak-V3 and OTA-2.1
Conclusion
Are OTA-2.1 and Leak-V3 identical? Technically, NO. But as far as all the system executables, libraries, and pre-installed applications are concerned, YES. There are four small differences - which appear to be in areas where phone owners typically do not venture.
Methodology (Read at peril of boredom)
1) Write scriptware (*nix) to compare two complete filesystem trees, looking for match/mismatch in MD5 hashes, as well as reporting missing files. For completeness, the script works bijectively - it first examines all files found in TreeA relative to TreeB, and then reverses this (all files in TreeB relative to TreeA). This catches all missing files (which are in A, but not B; or alternatively are in B but not A). This script does not (presently) examine file modes, ownership, or timestamps, nor does it look at symlinks or directories; so differences of that nature are unexamined here.
2) Unpack partitions from the Leak-V3 PB00IMG.ZIP file using appropriate tools into separate directory (subtrees).
3) Perform a 1.5 full factory rollback on the phone, including bootloader and radio, followed by an OTA-2.1 update. Install 1.49 S-OFF bootloader (only, via battery pull trick), and then soft-load Amon_RA v1.6.2 via a fastboot "boot" operation ("fastboot boot recovery-RA-eris-v1.6.2.img")
4) Via adb (to the Amon_RA recovery soft-boot), perform:
- mkyaffs2image on system and data partitions (output goes to SD card)
- dump_image on recovery and boot partitions (again, output goes to SD card)
5) Pull all images to the PC and
- unpack the system and data images via "unyaffs"
- **unpack the boot and recovery images with split_bootimg.pl and then
- **unpack the ramdisk (gunzip -c bootimg-ramdisk.gz | cpio -i)
** For Leak-V3 vs. OTA-2.1, this step is superfluous, as both ship the contents of these partitions as monolithic ".img" files, which have the same MD5 has in both. (I did this step to set up comparisons against Leak-V2 and Leak-V1, which I am not reporting on here)
6) Run the analysis script to compare trees
bftb0
WOW
very informative
bftb0, thanks once again for such awesome information. I'd be interested in seeing the script you wrote, although I'd understand if you didn't share it.
nindoja said:
bftb0, thanks once again for such awesome information. I'd be interested in seeing the script you wrote, although I'd understand if you didn't share it.
Click to expand...
Click to collapse
Sent you a link to a pastebin in PM. It's cruftware, not lebenswerk. Don't take it too seriously.
Very intersting. I'm really trying to get into all this coding and dev. stuff. Thanks for the post. Always nice to learn new things.
I'm sorry, but I don't understand ANY of that. Are they really the same or are they different ? I have the v3 leak installed and I really want to install the "official" firmware. Should I ?
hallstevenson said:
I'm sorry, but I don't understand ANY of that. Are they really the same or are they different ? I have the v3 leak installed and I really want to install the "official" firmware. Should I ?
Click to expand...
Click to collapse
You need to install the "Official Leak-V8". It's identical to Leak-V3, but there is a picture of a bunch of carrots on the package it comes in. Waaaay better than V3.
Wow great post thanks!
-------------------------------------
Sent via the XDA Tapatalk App
Seriously though, excellent information. Myself and a number of others have been repeating endlessly that the last leak and the OTA were really the same but some just refused to believe it. Even after 'thenestor' did the MD5 comparison and "proved" it, it didn't seem to matter to some ("what's MD5 ?"). Now there's a 2nd backup to help prove it. Hopefully it works !
Thanks for the info. Basically the operation and functionality of the two versions are the same, just a couple of files in one that aren't in the other, but the end user won't notice a bit of difference.
-------------------------------------
Sent from my HTC Droid Eris using Swype
Ok folks. I got this phone in March. It's my first Android phone. I love it. What do I love most? Hacking, tweaking, building, learning cool stuff. Yeah, it makes calls and stuff like that too. Whatever. So did my Startac.
I've been very slowly creating a 'how to get started' post for people who what to be devs. The info is out there elsewhere, but I'd like to consolidate much of it into kind of an overview with links to more detail. The first part is pretty much ready to post, so I figure I'll post it and keep working on the rest. Maybe some of you would like to contribute. Maybe not. I welcome the help though.
Some basics:
1) ROM structure - unzip an existing ROM and get to know the structure
Here's a fairly standard folder structure for an Eris ROM. Most other devices will have something similar.
Code:
/system
/app <- system apps and others that can't be uninstalled normally
/bin <- system binaries (small, standalone programs)
/customize <- has files that control initial boot and some screen settings (not always here)
/etc <- generally system configuration files
/bluez <- bluetooth config files
/clockwidget <- ? (not always here)
/dhcpd <- dhcp config files (dhcp is used to negotiate a network address)
/dmdata <- ?(not always here)
/firmware <- system firmwares
/iproute2 <- configuration files for network routing? (not always here)
/permissions <- describes permissions that apps may use
/ppp <- ppp configuration files?
/security <- certificates for over-the-air (OTA) updates
/wifi <- configuration files and firmwares for wifi
/fonts <- fonts
/framework <- mostly java jar files that contain code that other apps call
/lib <- C (mostly?) libraries that contain code for the system and apps to call
/bluez-plugin <- bluetooth stuff
/egl <- files needed for hardware 3d rendering
/hw <- files needed for various hardware like lights & sensors
/modules <- modules that the kernel might load, such as wlan (wifi)
/media <- audio and animations (usually here)
/audio <- audio files
bootanimation.zip <- well... (can be done another way or two)
/usr <-
/keychars <- keyboard drivers
/keylayout <- keyboard definitions (you can edit the .kl files!)
/share <- ?
/srec <- dictionaries?
/xbin <- more system binaries
build.prop <- config file that sets system variables and stuff
/META-INF
/com
/google
/android
update-script - script that actually copies the ROM to the phone when you flash
CERT.RSA <- created when ROM is signed
CERT.SF <- created when ROM is signed
MANIFEST.MF <- created when ROM is signed
boot.img - see #2 below
Code:
/data <- user and app data
/app <- apps that are installed by and can be removed by user (not always in ROM, but created on device
/other folders (Android/apps create some folders in here post flash and some devs will also add an extra folder or two occasionally
Some .apks can be removed and some cannot. Many different things tie together. For instance, one apk may call code in a lib file, so it's dependant on the lib file.
If you do take an existing ROM apart and change it, you'll have to zip it back up and resign it before it will flash. Here are some tools that will sign a ROM -
EasySign - http://android.grdlock.net/index.php?&direction=0&order=&directory=HTC Droid Eris/Extras
dsixda's Kitchen - http://forum.xda-developers.com/showthread.php?t=633246
AutoSign - http://androidforums.com/developer-101/8665-how-signing-roms.html
2) boot.img - kernel, ramdisk, and init files
The boot.img has the actual linux kernel with some Android and device specific tweaks. Here's the structure for it -
Code:
boot.img-kernel <--- actual kernel (zImage renamed)
boot.img-ramdisk.cpio.gz <--- ramdisk
/data
/dev
/proc
/sbin
/sys
/system
default.prop
init
init.desirec.rc <-- will be named different for different devices, supposed to be device-specific init file
init.goldfish.rc <-- for emulator (You can lose this.)
init.rc <-- always here, this is run on boot
The *.rc files are initalization files, in case you didn't get that. They run when the phone boots up and do things like start 'services' and change permissions on files/folders. I highly recommend that you look at them and compare different ones with something like WinMerge.
I attached an example. You can see where there's been a typo in the stock init.rc for a long time. This is a comparison between the stock init.rc and the one from CELBFroyo.
3) Hardware
Confused as to what refers to what? Me too! Here's a few things that I've figured out. Please point out anything you think is incorrect or needs to be added.
melfas, capella, synaptics = touchscreen
i2c = bus
akmd/akm8973 = accelerometer
mtd/nand/sdio = internal memory
s5k3e2fx = camera sensor
qdsp/adsp/dsp = audio
brf6350 = bluetooth?
Fw1251r1c/wpa/wifi/tiwlan0 = wifi
gralloc/copybits = framebuffer/video/display/graphics memory
malloc = memory allocation
Reserved for more info
Another one reserved for future info.
I just posted something similar in the "general" section...(about Christmas, that is...)
http://forum.xda-developers.com/showthread.php?t=886630
Thanks you for your work and contributions to the eris community. This will be very helpful as im trying to learn my way up. My comp died last week so it'll be a few more weeks till I get another one,but im trying to start doing a lil rom making/codeing myself. Thanks and MERRY CHRISTMAS TO ALL!!ΒΆ
Awesome work Gnarly
Brilliant thread! Thanks buddy.
And happy whatever and thanks to all the devs and smart ass users that make this phone surpass expectations every day.
Wait, how do I do all this again? Can you help me?
workshed said:
Wait, how do I do all this again? Can you help me?
Click to expand...
Click to collapse
No. Use the search feature noob!
Thanks for all of the thanks folks. I'm just trying to make it easier for people to become devs. We need as many as we can get. It takes time to learn this stuff, and it's nice when you don't have to spend quite so much of your time searching for the info instead of spending your time learning about the Eris and Android.
To make it more difficult, there's this dev 'club', with their secret IRC channels and PMing all of their secrets back and forth instead of being open and honest. And the chest-hair burning initiation is really tough to get through. (That's why we don't have any female devs, you know.) I did though. And now, I've went all wikileaks on them and they are angry. The attacks have begun already. They are mostly from Delaware, Pittsburgh, and the Seattle area. But, there is a completely incompetent attack coming from Michigan too.
This will help me out a lot. There are a lot of barriers to getting started, and this breaks down many of them. Thanks.
gnarlyc said:
Thanks for all of the thanks folks. I'm just trying to make it easier for people to become devs. We need as many as we can get. It takes time to learn this stuff, and it's nice when you don't have to spend quite so much of your time searching for the info instead of spending your time learning about the Eris and Android.
To make it more difficult, there's this dev 'club', with their secret IRC channels and PMing all of their secrets back and forth instead of being open and honest. And the chest-hair burning initiation is really tough to get through. (That's why we don't have any female devs, you know.) I did though. And now, I've went all wikileaks on them and they are angry. The attacks have begun already. They are mostly from Delaware, Pittsburgh, and the Seattle area. But, there is a completely incompetent attack coming from Michigan too.
Click to expand...
Click to collapse
+1 Internetz to you sir, I lol'd!
Wait so where is the download link? How do I install this?
Hey gnarly I just now looked at this, as many times as I've probably looked at your links I didn't see it and it is perfect, short & sweet but to the point and very informative. I'm sorry for bringing up an old thread guys but I just had to get it out there how helpful this is. Thanks bro!
lemonoid said:
Hey gnarly I just now looked at this, as many times as I've probably looked at your links I didn't see it and it is perfect, short & sweet but to the point and very informative. I'm sorry for bringing up an old thread guys but I just had to get it out there how helpful this is. Thanks bro!
Click to expand...
Click to collapse
No problem. I'm glad you find it helpful. My intention was for other folks to contribute as they learned new things, but that didn't really happen. Oh well... (Hint, hint, hint).
And, I never got around to adding a section on 'ethics', so here you go...
1) ask permission before using other's work
2) give credit for using other's work
3) don't lie about what you did or what your ROM really is
4) #1-#3 are much easier and less stressful than the alternatives, and they're just plain nice
gnarlyc said:
No problem. I'm glad you find it helpful. My intention was for other folks to contribute as they learned new things, but that didn't really happen. Oh well... (Hint, hint, hint).
And, I never got around to adding a section on 'ethics', so here you go...
1) ask permission before using other's work
2) give credit for using other's work
3) don't lie about what you did or what your ROM really is
4) #1-#3 are much easier and less stressful than the alternatives, and they're just plain nice
Click to expand...
Click to collapse
Well as I pick up on a few more things, I have a few kinks in my brain to work out, I will definitely put whatever I can to help. As you know at least, I'm still very fresh at all of this, which makes this even better. Newer minds are constantly developing new knowledge and skills to improve their own efforts, and I personally think that many of the seasoned devs know so much and have had their hands in the pot so long, that they might not remember all of the little things that had to be overcome or learned at the beginning. So with good communication between beginners and experienced developers, I believe that is the only way an amazing guide can be released. And that has already begun here, and obviously countless other places. Thanks again gnarly
Nice write up! Thanks, the info is greatly appreciated.
Sent from my un-rootable Incredible 2 using XDA app
I have searched, read, and tested my butt off on this so, I'm not posting without doing my own homework. I promise.
I'm looking for CURRENT documentation on how to create a standard update.zip file that simply copies a file into /system/foo/bar and chmods it.
All the links I've looked at seem to have old deprecated syntax on the update-script file, or the examples given simply do not work.
I do NOT want to download someone else's script-pak, windows app, or any other such thing that makes it for me.
As for signing, I'm completely comfortable signing using the SDK, although I'll probably take the easy route with ZipSigner/Signapktic running on the phone/tab now that I've discovered those.
Can someone please post a very simple howto?
Thanks for posting this -- I'm with you, I'm not a script-kiddie using someone else's tools, I want to learn it for myself, but like you, I've searched, and what I've found -- while probably correct and accurate -- isn't working the way they say it should. I've even followed the directions on android.com itself and they fail, so I'm starting to suspect my recovery or my ROM is at fault, not the signing itself.
I have a bunch of files I want to place in /system/foo/bar and chmod, as you say, and the error I'm getting is "No signature (172 files) Verification Failed". I do indeed have signatures in the file, as when I open them I see CERT.RSA and others that weren't there before signing, so IDK what the deal is with the error I'm getting (obviously something's missing -- maybe a public key verification from a trusted authority like Thawte or VeriSign).
I see you, too, are getting as much help as I am seeing others get. They start threads, get all sorts of praise from script kiddies who have no clue and just see a point-click solution, and then someone asks for real help and everyone shuts up for months until the thread eventually dies.
But kudos to you, sir, for being in the same boat as I!
cj chitwood said:
Thanks for posting this -- I'm with you, I'm not a script-kiddie using someone else's tools, I want to learn it for myself, but like you, I've searched, and what I've found -- while probably correct and accurate -- isn't working the way they say it should. I've even followed the directions on android.com itself and they fail, so I'm starting to suspect my recovery or my ROM is at fault, not the signing itself.
I have a bunch of files I want to place in /system/foo/bar and chmod, as you say, and the error I'm getting is "No signature (172 files) Verification Failed". I do indeed have signatures in the file, as when I open them I see CERT.RSA and others that weren't there before signing, so IDK what the deal is with the error I'm getting (obviously something's missing -- maybe a public key verification from a trusted authority like Thawte or VeriSign).
I see you, too, are getting as much help as I am seeing others get. They start threads, get all sorts of praise from script kiddies who have no clue and just see a point-click solution, and then someone asks for real help and everyone shuts up for months until the thread eventually dies.
But kudos to you, sir, for being in the same boat as I!
Click to expand...
Click to collapse
See my other reply to you in a similar topic.
I may be wrong but dont you have to sign system apps with the same key that the rom was signed with.
You can compile and sign from source and then add system apps or data
From something awesome
killersnowman said:
I may be wrong but dont you have to sign system apps with the same key that the rom was signed with.
You can compile and sign from source and then add system apps or data
From something awesome
Click to expand...
Click to collapse
System apps must be signed using the same key that is used to sign the platform. This has nothing to do with the ZIP signature that may or may not be present on a recovery update. The actual platform public key is stored within the ROM and gets extracted just like any other file in the system image.
If you compile from source, you use the platform key provided in the source; typically: build/target/product/security/platform.x509.pem. If you are an OEM like say HTC, you'll use your own key to compile the platform and sign the system apps.
Gene Poole said:
System apps must be signed using the same key that is used to sign the platform. This has nothing to do with the ZIP signature that may or may not be present on a recovery update. The actual platform public key is stored within the ROM and gets extracted just like any other file in the system image.
If you compile from source, you use the platform key provided in the source; typically: build/target/product/security/platform.x509.pem. If you are an OEM like say HTC, you'll use your own key to compile the platform and sign the system apps.
Click to expand...
Click to collapse
So in order to put ringtones in the appropriate system folder, I have to sign the update.zip with the same key that e.g. Roalex uses to sign the ROM? Of course that won't work, as I don't have his key, and then there are kernels and themes that other people make that work, and surely they don't have Roalex's key.
So I think I'm misunderstanding this still.
But if I compile from source, I sign with the key that's in the source, so if I know Roalex compiles from source, if he signs with the source key, I can sign an update.zip with that key and it will work?
Also, Recovery says there is NO signature in the file, but does that not necessarily mean really what it says?
I don't know who Roalex is. I don't know anything about your device per se. I don't know anything about Amon-Ra recovery. I was hoping some others would jump into this thread to help out with these unknowns. I've always used clockworkmod recovery so that's all I can speak for, but I did D/L an Amon-Ra recovery to analyze it.
As far as custom ROMs go, most are based on some OEM ROM and still contain system files signed by the OEM and the OEM certs are still included with the ROM so no modifications are necessary.
If you have a simple update.zip with just some files to be written to the system partition, then signing the update.zip file is unnecessary. A signed update.zip is only useful when it is distributed by an OEM with an official OEM update since the stock recovery will refuse anything not signed by the OEM. One of the reasons for using a custom recovery on rooted devices is that it gets around this security check to allow you to install custom stuff written by someone other than the OEM.
If you are having trouble installing an update.zip that contains an otherwise valid working "amend" or "edify" script, then I don't know what the issue might be. Clockworkmod recovery (at least all the versions I've run) has an option to toggle signature checks in the "apply update from SD card" sub-menu, but I don't know of any good reason that it is there since it only has one key and it is the same "test" key distributed in official source distributions, and the toggle is off by default.
I've been poking around github and grabbed the current source for amon-ra recovery (https://github.com/packetlss/amonra_bootable_recovery) and interestingly, amon-ra has a signature verifyer that is missing from clockworkmod recovery. It actually parses the zip file for the META information and ensures that the included signing key for the zip is consistent with the manifest and each file's signature.
So, it would seem that your update.zip should be signed the same way an APK is signed, using jarsigner.
Do you have a valid signing certificate and are you signing your update.zip correctly?
After learning to compile cm from source I found it easiest just to edit the .zip and then resigning the zip. I have added a few programs into /system and never had an issue. Perhaps this is because it's cm?
Gene Poole said:
I've been poking around github and grabbed the current source for amon-ra recovery (https://github.com/packetlss/amonra_bootable_recovery) and interestingly, amon-ra has a signature verifyer that is missing from clockworkmod recovery. It actually parses the zip file for the META information and ensures that the included signing key for the zip is consistent with the manifest and each file's signature.
So, it would seem that your update.zip should be signed the same way an APK is signed, using jarsigner.
Do you have a valid signing certificate and are you signing your update.zip correctly?
Click to expand...
Click to collapse
i was just going to conjecture that perhaps the amon-ra recovery is verifying sigs. you however have found proof. thank you
the only way someone would have the valid sig is for it to either be public, or for them to have signed the platform themselves and have there own private key. i ran into this same problem when investigating the android.intent.action.REBOOT intent which can only be broadcast by system apps signed with the same sig as the platform.
Gene Poole said:
I don't know who Roalex is [...]
Click to expand...
Click to collapse
Sorry, he's the guy who put together the COS-DS ROM for G1/HTC Dream based on CyanogenMod and AOSP sources.
Gene Poole said:
As far as custom ROMs go, most are based on some OEM ROM and still contain system files signed by the OEM and the OEM certs are still included with the ROM so no modifications are necessary.
Click to expand...
Click to collapse
Wait... can signing the zip be as easy as including the CERT.MSA and related other two files as found in the other update.zip files I have that work? Seems that would be too easy... I assumed there would be something in the zip file headers that would be modified to reflect a key as well so that they would also have to match. Maybe this is getting too in-depth...
Gene Poole said:
If you have a simple update.zip with just some files to be written to the system partition, then signing the update.zip file is unnecessary.
Click to expand...
Click to collapse
So just put together a common zip file with the update-script and the right folder structure in it, and I'm good? I tried that too and it also failed. Does the NAME of the file have to be update.zip in that case, though? I didn't actually try that. My unsigned one was named "CJ-Audio-Update_unsigned.zip" or something like that.
Gene Poole said:
A signed update.zip is only useful when it is distributed by an OEM with an official OEM update since the stock recovery will refuse anything not signed by the OEM. One of the reasons for using a custom recovery on rooted devices is that it gets around this security check to allow you to install custom stuff written by someone other than the OEM.
If you are having trouble installing an update.zip that contains an otherwise valid working "amend" or "edify" script, then I don't know what the issue might be. Clockworkmod recovery (at least all the versions I've run) has an option to toggle signature checks in the "apply update from SD card" sub-menu, but I don't know of any good reason that it is there since it only has one key and it is the same "test" key distributed in official source distributions, and the toggle is off by default.
Click to expand...
Click to collapse
Okay then. From here it's a lot clearer than a week ago. Thanks for taking the time to explain it so thoroughly... I think so many people understand so little and they're so quick to say "here, just use this other guy's tool LOL!!!111!1 he r0x0r$!!!1!1". I mean, that's great, that there are tools, but I want to understand it, not just be a script kiddie with someone else's tools, blindly trusting that they're doing it right and all that. Not saying the tools are bad or wrong, but by knowing myself, I know whether it's done right, you know? Same reason I learned automotive mechanicals, computers, and electrical wiring. Oh, and plumbing is slowly being added and in a few years roofing
Then it's on to framing as I build a 20-by-20-foot "workshop" in the back yard but I digress...
Thanks again!
Well this is interesting...
I took the MSA and other two files from the COS-DS update, and put them in a new zip containing my other files (not signed) and it didn't complain about no signature... instead, it failed saying some lib file is missing. Stagefright or some such. Progress is still progress though...
EDIT:
Okay, so it looks like there's something in those signats that says, "hey, look for all these other files too", so I'ma try a different tack...
EDIT2:
I guess I'm just gonna have to use Testkeys. They appear to have worked. :/ But if everyone else is doing it that way, I guess there's no harm.
Hey, I noticed while looking through the Stock Firmware AP file, that in meta-data/fota.zip there are .jar files that have to do with package signing. Only issue is that the zip is password protected. If someone has the Compute power and skills to decrypt a zip and look at the jar files and ****, maybe we could find a way to sign our own TWRP recoveries and roms. Just a thought, i'll post a link to the fota.zip file i was talking about in a bit if anyone wants to take a crack at it. (Google drive is taking forever to upload cause of AT&T's ****ty DSL speeds, sorry)
Download Link: htt*ps:/*/drive.*google*.com/file/*d/0B9tb-svjqaVD*b3Y0V0tXR3drSzA/vie*w?usp=sharing (Remove all *'s from link, stupid 10 post until you can post links limitation)
Thanks,
Lavavex
Did you saw this Thread?
https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
About fota.zip...
Did you heard about plain text attack?
In few Seconds... minutes done... no password required but you can unpack.
Best Regards
Yesterday I have download this fota.zip... and yes... same password as for instance from my prior test with:
SM-J330F and 1 more...
Here are the 3 keys to decrypt if somebody want try...
Code:
2b4d493c
6142b289
1b7024aa
Code:
Key0
Key1
Key2
I have used Advanced Archive Password Recovery from elcomsoft...
Best Regards
adfree said:
Yesterday I have download this fota.zip... and yes... same password as for instance from my prior test with:
SM-J330F and 1 more...
Here are the 3 keys to decrypt if somebody want try...
Code:
2b4d493c
6142b289
1b7024aa
Code:
Key0
Key1
Key2
I have used Advanced Archive Password Recovery from elcomsoft...
Best Regards
Click to expand...
Click to collapse
Which will allow unpacking of the above zip? I thought it needed a zip password.
osm0sis said:
Which will allow unpacking of the above zip? I thought it needed a zip password.
Click to expand...
Click to collapse
We never found the Password... but for Decryption you need only these 3 Keys...
They can be easily found in few Minutes... with the right Tool...
Code:
2b4d493c
6142b289
1b7024aa
Here Key0 Key1 Key2 for Samsungs fota.zip...
This is really no rocket science...
Simple read about plain-text attack...
You can see all filenames...
You can see all filesizes etc...
Many files are floating around the Internet... to create ZIP for attack...
Then result is in few Minutes possible... :angel:
Use these 3 Keys in Tool:
Code:
Advanced Archive Password Recovery
And try self to unpack...
Best Regards
Edit 1.
Screenshot added...
Then maybe more clear...
Trial Version have mabye limtations... but to see it work... it is enough to play with trial.
@adfree or to anyone who can answer.
Quick question, what are the legal limitations to what is going on here? I may or not have a file from inside the fota.zip, but will sharing it put me in the legal wrong? If it is within the legal boundaries, I'd be happy to upload it for anyone to take a look at, but I don't want to land on the wrong side of the law by doing so. Please do let me know, as this is the most exciting development we've had when it comes to bootloader unlocking in a while. Also, it seems as though we can't view the entirety of the contents of the fota.zip with the trial version of the zip extraction tool mentioned in this thread, so if someone with more knowledge about this can confirm we could unlock our bootloaders with the contents of the zip (based on what is currently known about this), I'd be happy to bite the bullet of paying for the premium version given we can do this within the boundaries of the law.
Thanks.
1.
Maybe you can answer your question self...
Samsung PROTECTED this ZIP with password.
2.
IMHO it is Kernel related...
Yeah I know... Boot is every irritating...
But it is not sboot.bin related...
3.
About decrypting all files...
There are floating around Command Line Tool...
Code:
pkcrack
Try to Google it...
I have not tried...
I am 1 click Button user...
Best Regards
zipdecrypt from the pkcrack package plus those 3 keys worked flawlessly. :good:
Edit: Crazy number of utilities in this zip, but no script to run them all, and a lot of references to external files. No smoking gun like a "sbootimg_signer" binary or anything to make their proprietary footer signature, and no Samsung signature files.
the password for that zip is fotatest1234
Correct. All fota zips passwords are fotatest1234
Drdra3 said:
Correct. All fota zips passwords are fotatest1234
Click to expand...
Click to collapse
@lavavex , @osm0sis
Yes it is, but now the question still to be answered is, do the tools within the fota.zip file, actually work for legitimately repacking the boot/recovery image? Because in the fota.zip I checked from Android Pie's release it mentioned the "user/test-keys" and very much so had all of the compiled tools to actually patch a system and create and ADB flashable zip for stock recovery.
Could we technically make a signed sideloadable update.zip if the the update package was created on the device itself? The scripts included, along with the updated compiled binary tools, really do seem to be the Toolkit we've been looking for but have overlooked. I haven't tested it out fully, but I'm still reading about how to proceed. It isn't just the S7 either. So are the tools customized to the device, the android branch, or the bootloader?
Delgoth said:
@lavavex , @osm0sis
Yes it is, but now the question still to be answered is, do the tools within the fota.zip file, actually work for legitimately repacking the boot/recovery image? Because in the fota.zip I checked from Android Pie's release it mentioned the "user/test-keys" and very much so had all of the compiled tools to actually patch a system and create and ADB flashable zip for stock recovery.
Could we technically make a signed sideloadable update.zip if the the update package was created on the device itself? The scripts included, along with the updated compiled binary tools, really do seem to be the Toolkit we've been looking for but have overlooked. I haven't tested it out fully, but I'm still reading about how to proceed. It isn't just the S7 either. So are the tools customized to the device, the android branch, or the bootloader?
Click to expand...
Click to collapse
Presumably what I previously said still stands:
osm0sis said:
Crazy number of utilities in this zip, but no script to run them all, and a lot of references to external files. No smoking gun like a "sbootimg_signer" binary or anything to make their proprietary footer signature, and no Samsung signature files.
Click to expand...
Click to collapse
I bought a replacement V20 from China. It was sold as new but it's definitely been opened. Is there any way to pull an image off it and compare it with a known good one? I'll probably reflash it anyway to be sure, but it'd be nice to confirm.
It reports its version as VS9951BA. I've grabbed that kdz off https://lg-firmwares.com but I can't find a second copy of it hosted anywhere else to confirm the hash. Not that I don't trust lg-firmwares, but it's nice when you see the same hash from a lot of sources.
Code:
$ for h in sha256sum sha512sum md5sum; do $h --tag VS9951BA_01_0321_ARB00.kdz; done
SHA256 (VS9951BA_01_0321_ARB00.kdz) = edefde524ac1c45271f47a48ad51aeeab49fbdba325cb59652b7e0770848958f
SHA512 (VS9951BA_01_0321_ARB00.kdz) = 0b3bf61504b4dfa328bac92af4ceaa1ff3d6108f292a0c40d7ce4e812bc23c8dd7fd877cfe687b1127cab3ef69f5ef8171cf4b7da98ee703282c1be4aa9841ca
MD5 (VS9951BA_01_0321_ARB00.kdz) = 58aecb6979acf0a5c8705d1be86a6dcb
You can find a mirror of the file here, and the MD5 hash value matches:
https://androidfilehost.com/?fid=11410963190603847106