Related
I am still testing but... well another user gave us the info to the update file... and it gives us the radio.img, the boot.img, and an editable system folder... I wonder if it will let you update it if you change the files... Wonder if you can sign it yourself.
Well please do let us know!
It is too late to do it tonight (for me anyways) I will be deleting files and seeing if it keeps it signed status tomorrow (you know how HTC likes every signed a certain way LOL) will keep you informed. BTW there is another thread with the file.
You get hat Structure from the Following File
https://android.clients.google.com/updates/signed-kila-ota-115247-prereq.TC4-RC19+RC28.zip
Making the Customised Image is not an Issue though but how can we signed it to Possible load it on Device.
We must get Cracked Boot loader to flash Unsigned Object and file like we have done it so far to Windows Based HTC Devices.
Yeah, I think that the signature of those files (found in the MANIFEST.MF) is crucial to get it to flash.
If, however, you can get it to flash with those things changed - that'd be pretty awesome.
The easiest way to test it, I think, would be to leave the files intact but to alter one of the signatures in the MANIFEST.MF file so that you are effectively breaking the signing (which is the same thing changing one of those files would do) - once you have done that - if the device will still flash then you KNOW you are in business.
Just don't want to waste a lot of time building some sweet image only to find out you can't do anything with it.
Just my 2 cents.
The other question is - once you've run an update from the SD card with the RC29 update can you re-run the update?
RyeBrye said:
The easiest way to test it, I think, would be to leave the files intact but to alter one of the signatures in the MANIFEST.MF file so that you are effectively breaking the signing (which is the same thing changing one of those files would do) - once you have done that - if the device will still flash then you KNOW you are in business.
{...}
The other question is - once you've run an update from the SD card with the RC29 update can you re-run the update?
Click to expand...
Click to collapse
I can test it out for you. Just change any value in the file?
And someone else had stated that you can re-update, but I'll try it again with the file changed.
Okay... so you can run the update again, just confirming.
I removed a ringtone from the /system/media/audio/ringtones but didn't change anything in the MANIFEST.MF file.
"Verification failed
Installation aborted."
Next i'll try to change the value for it in the MANIFEST.MF file and see if it goes thru.
Changin the MANIFES.MF file failed because it checks with CERT.SF
Chaning CERT.SF to be the same.
Now I got the following
E:No signature (414 files)
E: Verification failed
Installation aborted.
Time to tinker away... If someone can guide me just a lil, that would be apreciated. I'm still going to waste my time doing whatever "I beleave" is progress in the mean time
quedijo said:
Now I got the following
E:No signature (414 files)
E: Verification failed
Installation aborted.
Time to tinker away... If someone can guide me just a lil, that would be apreciated. I'm still going to waste my time doing whatever "I beleave" is progress in the mean time
Click to expand...
Click to collapse
I wish i knew anything about linux permission, i would like to help
apatcas said:
I wish i knew anything about linux permission, i would like to help
Click to expand...
Click to collapse
Thoughts count aswell
I got to go do a job right quick... should be back in 4hrs or less, I hope
i'll try to help as much as i can
Ill look into how the manifest works, ill work on it as much as I can
Let's get this baby customized
The cert is referencing a checksum to the manifest. It seems that they are using sha1-digest as stated plainly in the manifest file but i believe it is further encoded by base32 encoding. Does anybody have a base32 encoder handy?
Digests and the Signature File JDK
I believe the second line in CERT.SF is a hash for MANIFEST.MF. You need that hash to match the hash for the actual file MANIFEST.MF. There could be something that also hashes CERT.SF to see if you messed with it, but I don't see that right now.
So, edit CERT.SF so the line:
SHA1-Digest-Manifest: lsGC/wXGYwKahxByTQdTNs2K5oY=
Matches the SHA1-Digest (in base32) of MANIFEST.MF and try again.
Just to clear up some things for those following this thread...
The update image is signed with a private key by either HTC or Google (honestly not sure which, probably google). When your phone receives the image it decrypts the signature with each of the public keys it has installed, if one matches it installs.
The keys are made in pairs, the private key (which only the signer has and we will not obtain) signs and the public key (which is installed on the device as trusted) is used to decrypt.
Of course if someone can manage root access to the phone through one of the processes running as root by using a buffer overflow or something of that nature we can simply add OUR OWN public key to the phone's repository, and sign our images with OUR OWN private key. This would allow a new image to be made that once installed could auto-check for updates and pull off the same kind of update process that we see with rc29...
netcmd said:
I believe the second line in CERT.SF is a hash for MANIFEST.MF. You need that hash to match the hash for the actual file MANIFEST.MF. There could be something that also hashes CERT.SF to see if you messed with it, but I don't see that right now.
So, edit CERT.SF so the line:
SHA1-Digest-Manifest: lsGC/wXGYwKahxByTQdTNs2K5oY=
Matches the SHA1-Digest (in base32) of MANIFEST.MF and try again.
Click to expand...
Click to collapse
It is the hash for MANIFES.MF
I did that and still gives the following:
E:No signature (414 files)
E:Verification failed
syrusfrost said:
Just to clear up some things for those following this thread...
The update image is signed with a private key by either HTC or Google (honestly not sure which, probably google). When your phone receives the image it decrypts the signature with each of the public keys it has installed, if one matches it installs.
The keys are made in pairs, the private key (which only the signer has and we will not obtain) signs and the public key (which is installed on the device as trusted) is used to decrypt.
Of course if someone can manage root access to the phone through one of the processes running as root by using a buffer overflow or something of that nature we can simply add OUR OWN public key to the phone's repository, and sign our images with OUR OWN private key. This would allow a new image to be made that once installed could auto-check for updates and pull off the same kind of update process that we see with rc29...
Click to expand...
Click to collapse
@syrusfrost: It's true that the zip is signed with a private key from HTC, however we can easily resign the package using our own key. The question is will the G1 accept this?
Has anyone tried resigning the application with the jarsigner? The errors people have been listing, and the files located in META-INF corrospond to the same errors you get after patching a dalvik-executable (dex file) and not resign the package.
If the system files are NOT verifying it to the the specific HTC key we should be able to resign and have it accept out own update file...
I'm currently not at my development machine but I'm thinking we might be able to get somewhere using the permissions.xml file located in /system/etc/ - though this is considered a 'read-only' file in both the emulator and in the G1 hardware so changing it has thus far been unable to happen... Possibly a minor change like the following;
Code:
<!-- Test to see if we can gain cache access by assigning permissions and getting new
update -->
<assign-permission name="android.permission.ACCESS_CACHE_FILESYSTEM" uid="shell" />
Then resigning the whole package would let us get access to the /data/dalvik-cache system? Any takers on my... Seemingly stretching assumption?
strazzere said:
Then resigning the whole package would let us get access to the /data/dalvik-cache system? Any takers on my... Seemingly stretching assumption?
Click to expand...
Click to collapse
Okay bare with me. I wan't instructions on how to get the SHA1-digest of a file.
I found some instructions to use PHP and I can boot a LiveUSB Distro of Fedora but i'm sitll a bit lost
I have installed CyoHash for vista and the SHA1 base64 are exactly the same as the ones in the MANIFEST.CF but different for CERT.CF
So are the hashes for MANIFEST.CF SHA1 base64 and SHA1-Digest base32 for CERT.CF?
quedijo said:
Okay bare with me. I wan't instructions on how to get the SHA1-digest of a file.
I found some instructions to use PHP and I can boot a LiveUSB Distro of Fedora but i'm sitll a bit lost
I have installed CyoHash for vista and the SHA1 base64 are exactly the same as the ones in the MANIFEST.CF but different for CERT.CF
So are the hashes for MANIFEST.CF SHA1 base64 and SHA1-Digest base32 for CERT.CF?
Click to expand...
Click to collapse
I think Manifest.cf is just a regular hash checking file to make sure all files are there. While Cert.cf is the one that makes sure they are signed by the RSA
EDIT: CERT.CF is signed with HMAC-SHA1 The RSA is the public Key used to decrypt the hash correctly. I believe this means we can definitely use our own private/public keys to sign the package.
Anyone wanna help me figure out how to sign a HMAC-SHA1?
This has been resolved by using the flash lite exploit to gain root access allowing the misc partition to be flashed with a downgraded main version number which allows the old leaked Eng RUU we have to be flashed!
GUI for how to root
http://forum.xda-developers.com/showthread.php?t=720565
Old and Outdated information from the Original Post listed below for historical purposes ONLY
Who is Affected: If you've flashed the official OTA update on top of a non rooted ROM or your new EVO comes loaded with it, right now it appears there is no way to obtain root...yet!
What is Patched by the OTA: Through the radio.img which the OTA flashes, it updates the Main Version in the bootloader preventing Toast's root methods from working. It also flashes back the stock recovery, removing our root access in recovery mode and ability to apply .zip files. And last of all, the OTA patches the exploit hole in /system/bin/hstools used for unrevoked1 root.
Successfully eliminating all released methods of obtaining root access.
Conclusion:
after going through all these methods with a great helpful member of the unrevoked team, joshua_, this was the final answer:
[22:34] <joeykrim> cant see to find a method to RUU the phone back down ... ive tried all the methods ive seen. any methods i missed?
[22:34] <joshua_> ok, looks like we are hosed then
[22:34] <joshua_> we have a few more tricks up our sleeve sooner or later
Future:
If you have any suggestions/ideas, please post. I might have missed a method.
We will work towards obtaining root for those with new EVOs that have the official OTA applied and those who applied the official OTA.
Details of the tested known root methods:
user debug PC36IMG.zip (toast part 1) - bootloader error - Main Version is older! Update Fail! Do you want to reboot device?
eng build PC36IMG.zip (toast part 2) - bootloader error - Main Version is older! Update Fail! Do you want to reboot device?
RUU_Supersonic_1.32.651.6 extracted rom.zip renamed to PC36IMG.zip - bootloader error - main version is older
RUU_Supersonic_1.32.651.6_Radio_1.39.00.05.31_release_171253_signed.exe - Error [140]: Bootloader version error The ROM Update Utility cannot update your Android. Please get the correct ROM Update Utility and try again.
RUU_Supersonic_1.32.651.1_Radio_1.39.00.04.26_release_171253.exe - Error [140]: Bootloader version error The ROM Update Utility cannot update your Android. Please get the correct ROM Update Utility and try again.
Stock Recovery - Apply update.zip - clockwork recovery update.zip - E:failed to verify whole-file signature E:signature verification failed
flash_image (flash boot or mtd-eng.img) - copied to /sdcard, but sdcard is mounted with noexec. partition with write access for non-root user and allows executing is /data/local . flash_image can't write to the partitions w/o being run with root permissions. chownto and chown of flash_image to user root - permission denied.
##786# - Reset - doesn't seem to effect much in the way of bootloader version ...
Modifying PC36IMG.zip - using a hex editor to attempt at changing the MainVer stored in the android-info.txt, if any bit changes, it seems to fail the validation by the bootloader.
I tried almost all of these after the OTA hit my wifes phone. No dice. Subscribed to further updates on this thread.
I created a PC36IMG.zip file which contained the .6 releases wimax image and the android-info.txt file from the new update. I was then able to successfully flash it with hboot by placing it in the root of the sdcard and doing a down volume power on boot. It found the pc36img.zip file, verified it, asked me if I wanted to flash it. When I selected yes, proceeded to do so. It then reported the flash as having been successful.
I can't tell if the flash actually worked because I don't know where to check the wimax version info...
I don't know if this worked because the phone doesn't care to check the MainVer when flashing just the wimax image or if it did it because I pulled a fast one with the android-info.txt file swap.
I extracted the wimax image from the RUU_Supersonic_1.32.651.6_Radio_1.39.00.05.31_release_171253_signed.exe file.
I wonder if it would be possible to pull the same trick with the larger subset of images from the rooting pc36img.zip files. i.e. swap out the android-info.txt files...
frankenstein\ said:
I created a PC36IMG.zip file which contained the .6 releases wimax image and the android-info.txt file from the new update. I was then able to successfully flash it with hboot by placing it in the root of the sdcard and doing a down volume power on boot. It found the pc36img.zip file, verified it, asked me if I wanted to flash it. When I selected yes, proceeded to do so. It then reported the flash as having been successful.
I can't tell if the flash actually worked because I don't know where to check the wimax version info...
I don't know if this worked because the phone doesn't care to check the MainVer when flashing just the wimax image or if it did it because I pulled a fast one with the android-info.txt file swap.
I extracted the wimax image from the RUU_Supersonic_1.32.651.6_Radio_1.39.00.05.31_release_171253_signed.exe file.
I wonder if it would be possible to pull the same trick with the larger subset of images from the rooting pc36img.zip files. i.e. swap out the android-info.txt files...
Click to expand...
Click to collapse
im guessing the only reason it allowed you to flash a PC36IMG.zip which wasn't HTC signed is because you're using the hboot from the eng build of the PC36IMG.zip which doesn't check for HTC signatures on the PC36IMG.zip file. Not sure if it looks at the MainVer or not ...
once you're on a stock hboot, the PC36IMG.zip file has to be signed by HTC in order to flash!
I think in order for this to be patched, the bootloader code needs to be disassembled between the two versions to find out what bytes were patched and then either remove the code that checks for HTC signing or find a way to circumvent it.
We had to do things like this when working with mach_kernel when we got ahold of the first developer build of OS X for Intel. It was a pain in the ass and took weeks before we cracked the kernel.
There is even more risk with this though since tampering with the bootloader can definitely permanently brick devices.
joeykrim said:
If you've flashed the official OTA update or your new EVO comes loaded with it, right now it appears there is no way to obtain root...yet!
after going through all these methods with a great helpful member of the unrevoked team, joshua_, this was the final answer:
[22:34] <joeykrim> cant see to find a method to RUU the phone back down ... ive tried all the methods ive seen. any methods i missed?
[22:34] <joshua_> ok, looks like we are hosed then
[22:34] <joshua_> we have a few more tricks up our sleeve sooner or later
If you have any suggestions/ideas, please post. I might have missed a method.
We will work towards obtaining root for those with new EVOs that have the official OTA applied and those who applied the official OTA.
Here are details of the tested methods:
user debug PC36IMG.zip (toast part 1) - bootloader error - Main Version is older! Update Fail! Do you want to reboot device?
eng build PC36IMG.zip (toast part 2) - bootloader error - Main Version is older! Update Fail! Do you want to reboot device?
RUU_Supersonic_1.32.651.6 extracted rom.zip renamed to PC36IMG.zip - bootlaoder error - main version is older
RUU_Supersonic_1.32.651.6_Radio_1.39.00.05.31_release_171253_signed.exe - Error [140]: Bootloader version error The ROM Update Utility cannot update your Android. Please get the correct ROM Update Utility and try again.
RUU_Supersonic_1.32.651.1_Radio_1.39.00.04.26_release_171253.exe- Error [140]: Bootloader version error The ROM Update Utility cannot update your Android. Please get the correct ROM Update Utility and try again.
Stock Recovery - Apply update.zip - clockwork recovery update.zip - E:failed to verify whole-file signature E:signature verification failed
flash_image (flash boot or mtd-eng.img) - copied to /sdcard, but sdcard is mounted with noexec. only partition with write access for non-root user and allows executing is /sqlite_stmt_journals . flash_image can't write to the partitions w/o being run with root permissions. another words, need root access to use flash_image
##786# - Reset - doesn't seem to effect much in the way of bootloader version ...
Click to expand...
Click to collapse
since my frien did the OTA update yesterday and "bricked" his phone i have been trying to fix the phone (i have access to bootloader so it seems to me that maybe, just maybe i can save the phone) anyways, i have been getting a lot of the same error messages anytime i try to update/load any stock rom via bootloader.
what my question is, is there a way to take a 1.47.651.1 rom/image and put it into an ruu? i have looked all over htc's website, but they don't even acknowlege the existence of the evo, at least not that i can find.
joeykrim said:
flash_image (flash boot or mtd-eng.img) - copied to /sdcard, but sdcard is mounted with noexec. only partition with write access for non-root user and allows executing is /sqlite_stmt_journals . flash_image can't write to the partitions w/o being run with root permissions. another words, need root access to use flash_image
...
Click to expand...
Click to collapse
Just curious here, regarding the above step, if you had access to a phone that was already rooted, could you use your sdcard in that phone to copy the files into /data and then transfer the sdcard back to the unrooted phone to flash it then?
Sorry for the long multi quote, there are quite a few good ideas and I wanted to make sure I explored each of them as far as the original poster intended.
EtherealRemnant said:
I think in order for this to be patched, the bootloader code needs to be disassembled between the two versions to find out what bytes were patched and then either remove the code that checks for HTC signing or find a way to circumvent it.
Click to expand...
Click to collapse
interesting ... circumventing the HTC signature check would be perfect and essentially give us an eng build bootloader.
in the RUU.exe rom.zip files, the android-info.txt indicate the MainVer along with a separate hboot.img file. the official OTA didn't have an hboot.img file. It only had a radio.img file which must have updated the MainVer value.
Not sure where on the phone this MainVer value is stored? in the radio?
you're suggesting, compare the bootloader, which is obviously stored somewhere in radio.img as thats the only file being flashed thru the OTA which increments the bootloader version number, against an older radio.img to attempt and find which bytes were changed for the version number?
The radio.img files are all around 22mbs ... ugh
if we're able to find the change in version number on the radio.img, not sure how it would help in flashing over it?
i was kind of thinking down these lines...since the bootloader checks the version number of any file it attempts to flash, the version number is going to be the key.
if we're able to increment (or temp change) the main version number in the file being flashed w/o messing up the htc signature, that could work.
2002wrex said:
what my question is, is there a way to take a 1.47.651.1 rom/image and put it into an ruu?
Click to expand...
Click to collapse
i've heard this was often done back in the WinMo days but i haven't seen anything on this board regarding this approach. if you have any detailed information, we could def look into it!
unknown_owner said:
Just curious here, regarding the above step, if you had access to a phone that was already rooted, could you use your sdcard in that phone to copy the files into /data and then transfer the sdcard back to the unrooted phone to flash it then?
Click to expand...
Click to collapse
very clever concept!
i'm not 100% sure on all the different approaches in the suggestion, but here are the ones it prompted me to explore.
unfortunately, every time the /sdcard is mounted on the phone, its mounted as noexec, meaning no files located on the /sdcard can be executed like programs.
also the /sdcard is mounted with uid=1000 and gid=1015 meaning all files mounted on the /sdcard have their uid/gid overwrote so none of them are allowed root ownership.
without being able to "su" to root access, we aren't able to run any programs with root access.
trying to chownto flash_image to any reference file as root results in:
chownto flash_image /system/bin/chown
Can't change user/group to root!
chown root flash_image
Unable to chmod flash_image: Operation not permitted
if i missed the suggested approach, could you elaborate?
Oh boy...... I thought I was alone in this. I try everything I can and now gave up. Any one can rooted this new OTA please let me know. I really need to downgrade from this.
Made me think of a problem that happened with the Directivo a few years back...
ht t p://dealdatabase.com/forum/showthread.php?t=22154
I was looking around, trying to figure out some way to hack the hdvr2 w/o modifying the prom. I recalled something from the xbox-linux team's presentation for CCC, which was something close to "once you break the chain of trust, the box is forever compromised." I thought to myself: "self, if we can load one kernel via BASH_ENV, why can't we load a second kernel?"
Click to expand...
Click to collapse
So, is there a way we could compromise the kernel? If so, then...
Subscribed...
Not really interested in rooting until froyo is working, and I could really use the wifi fixes this OTA is supposed to offer, but I'll hold off installing it until we know it can eventually be rooted.
Mikesus said:
http://dealdatabase.com/forum/showthread.php?t=22154
So, is there a way we could compromise the kernel? If so, then...
Click to expand...
Click to collapse
i read thru the thread. im not clear on how they used BASH_ENV or any other method to load a 2nd kernel.
unfortunately, i think we have an extra layer of security that they dont. thanks HTC!
without nand unlocked on the kernel partition no data can be stored there including a 2nd kernel.
appreciate the link and info. perhaps the ideas or concepts will spur some innovation!
joeykrim said:
i've heard this was often done back in the WinMo days but i haven't seen anything on this board regarding this approach. if you have any detailed information, we could def look into it!
Click to expand...
Click to collapse
the thing about winmo ruu's (here's a topic i DO know well) is that they are always in a zip. you decompress the zip and have access to all the files. one of them will be the ruu, the rest are all the supporting files/images/rom. all of the android ruu's seem to come as on large exe that doesn't allow access to the files, it merely runs itself. in the winmo days if you got a rom with no ruu, and didn't want to flash from SD, you just took someone elses ruu and dumped the rom image in to the decompressed folder containing the ruu.
i appreciate the help joey, obviously you are busy with your own problems and a lot of people around here just throw you the old "SEARCH BUTTON" response. any help is greatly appreciated!
2002wrex said:
the thing about winmo ruu's (here's a topic i DO know well) is that they are always in a zip. you decompress the zip and have access to all the files. one of them will be the ruu, the rest are all the supporting files/images/rom. all of the android ruu's seem to come as on large exe that doesn't allow access to the files, it merely runs itself. in the winmo days if you got a rom with no ruu, and didn't want to flash from SD, you just took someone elses ruu and dumped the rom image in to the decompressed folder containing the ruu.
Click to expand...
Click to collapse
interesting again .. so the RUU .exe files for android, do have a payload stored in a rom.zip file which is dumped to a temp directory after the RUU .exe starts and before it finishes.
now, the rom.zip files have been pulled and posted in each of the two RUU .exe threads we currently have. these rom.zip files do contain all .img files which are flashed to the phone. the catch is though, just as the PC36IMG.zip files used in root, these rom.zip files seem to have a special HTC signature (checksum?) in their header.
if you open these rom.zip files from the RUU in winzip, it will error out, but using 7zip, they open just fine.
im new to HTC, this is my first HTC android phone and its almost been 4 weeks so this is as much as i know. it seems, if we're able to alter these rom.zip files either used in the RUU .exe or naming them PC36IMG.zip flashed thru the bootloader and the phone excepts them, we would be golden!
to help save you some searching and let you see what im talking about, here is the latest RUU rom.zip file
http://www.joeyconway.me/evo/stock/RUU_Supersonic_1.32.651.6_Radio_1.39.00.05.31_rom.zip
Subscribed, I was able to Order my EVO today so I will be watching for development. I pledge my donations to whoever is able to figure it out. I really appreciate the efforts of this community.
I second that pledge for donations! I, like many others here, updated while knowing that I probably shouldn't have. I knew better...
Subscribed.
Thanks for all the effort and work. I hope ya'll get it figured out.
dang, I just got my evo yesterday and got the update message so I thought it'd be ok to update it as I thought it might have been old.
Came home and was excited to do all my customization and tweaks, but w/ no prevail
So my local best buy will not give the phone to the customer without pushing the new OTA to it :/
Apparently all of the stores will be doing this per Sprint and HTC's request.
EtherealRemnant said:
So my local best buy will not give the phone to the customer without pushing the new OTA to it :/
Apparently all of the stores will be doing this per Sprint and HTC's request.
Click to expand...
Click to collapse
Try calling them ahead of time before picking it up and asking if you can just swing by and pick it up yourself and call Sprint to activate yourself. Tell them you are in a rush, make up a story, and see if they just let you pay for it and run.
Hey guys, I'm trying to tinker with the recently-released Telstra-Branded Froyo ROM so I can check on some of the data inside and modify T-Mod to suit, but I've come across two very strange problems:
1: Extracting the update form the RUU gives me naught but a .img file which I have no clue how to open (I know it's a filesystem image, but I haven't been able to find tools to open it)
2: The OTA version of the update, while easily viewable, seems to use a .p file based patching system that I have never seen before.
If anyone can help me with these two problems by providing me with either the tools to decompile the RUU into something I can actually look at, such as tools for android's .img filesystem format, or a decrypted version of this ROM, it would be greatly appreciated.
EDIT: Nevermind, I found a copy of unYAFFS, figured it all out. just had to figure out what the filesystem on the RUU was.
Edit: I see you found it..
I know you're sorted now Muskie, but using dsixda's kitchen is also a useful tool.
http://forum.xda-developers.com/showthread.php?t=633246
Run the ruu until the menu comes up, go to your temp folder and copy the rom.zip and whack it in the kitchen.
Ben
I have a custom Email apk with my FRG22D build on my Droid phone. Trying to update now to FRG83D, but it doesn't like the Email apk mismatch. Does anyone have an idea if it's ok to omit these lines in the updater-script file (that resides in update.zip)?
assert(apply_patch_check("/system/app/EmailGoogle.apk", "6084f7aa8b61040bc2ef81cb6c2733fedd771e11", "35fd89388108f2e84d1c5e24235727d78705b595"));
set_progress(0.066739);
assert(apply_patch_check("/system/app/EmailGoogle.odex", "08a0ca76aa3c134b44c48102349418c7c053441e", "d74645ddedda58c33bf5059ae1bfe95cda764cd1"));
set_progress(0.083266);
Would the update still work? That is, does the updater replace these files (in which case this should work), or modify only certain parts of them (won't work)?
I unfortunately don't have the original Email APK that came with FRG22D.
No one knows?
Can Someone Please explain MD5 ... The uses and how to compare and check?
Many thanks in advance
What it does, how it works:
en.wikipedia.org/wiki/Md5
Program to calculate checksums (for example):
en.wikipedia.org/wiki/Md5sum
http://implbits.com/Products/HashTab.aspx this puts a tab on your (right click -> properties) and you can compare it there. makes MD5 easy.
its a way of error-detecting to see if it verifies 100% without any errors. this is critical when updating radios and things. if you have a bad copy of it then you may brick your phone or cause damage because you received a corrupted version
zephiK said:
http://implbits.com/Products/HashTab.aspx this puts a tab on your (right click -> properties) and you can compare it there. makes MD5 easy.
its a way of error-detecting to see if it verifies 100% without any errors. this is critical when updating radios and things. if you have a bad copy of it then you may brick your phone or cause damage because you received a corrupted version
Click to expand...
Click to collapse
I sort of get it....just ....what are you checking it with....so say i download a radio.img , then i check its md5 against what ? how would i know that whatever md 5 it had generated is the right one.....sorry for the questions
menov321 said:
I sort of get it....just ....what are you checking it with....so say i download a radio.img , then i check its md5 against what ? how would i know that whatever md 5 it had generated is the right one.....sorry for the questions
Click to expand...
Click to collapse
the OP would include a MD5. once you download it, right click the file you downloaded and go to the hash tab and copy paste the one the OP pasted.. copy paste it into the box and if it matches a check will appear meaning its 100% identical
if OP doesn't include one then you cant check
zephiK said:
the OP would include a MD5. once you download it, right click the file you downloaded and go to the hash tab and copy paste the one the OP pasted.. copy paste it into the box and if it matches a check will appear meaning its 100% identical
if OP doesn't include one then you cant check
Click to expand...
Click to collapse
OP????
what happens though if it isnt identical......
When it isn't identical, then the file got corrupted.
This can happen in a variety of ways, including:
- There was an error during download
- There was an error during the original upload
- The file got corrupted during storage on the server
- The file got corrupted because of an write/read error on your hard disk
- Someone purposefully manipulated the file, for example including a virus or even changed the file so that it would brick your device if you install it.
In any case: If the md5 doesn't match, then installing it is a big NO NO.
Effects can range from no problems over occasional errors and crashes to a completely bricked device (especially, if the error happens to be in the bootloader).
Or if someone manipulated the file willingly, he could be spying on you or causing you costs by making your phone send messages or doing calls to special expensive numbers. Or he could use your phone as a proxy for various illegal things.
PS: OP = orginal poster = the person who posted the file on the first place
Thank-you very much I understand now ....nice comprehensive answer....thanks though to all who posted
Sent from my Nexus S using XDA Premium App