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?
Hey guys,
I am currently working on a workaround to get root back from the RUU_Hero_C_Sprint_2.27.651.5_R_signed_release.exe that Sprint released for the HTC Hero.
I have figured out a way that will revert us back to root using a hacked version of one of the test_signed RUU's I have.
My main question is:
I need to edit a text file in a .zip signed by HTC, without breaking the signature OR changing the md5 hash. Can this be done?
I have tried many ways of going about this (including hex editing the zip) and have not made much progress.
Any ideas?
Any input would be appreciated, for I too "took one for the team" and updated with the released RUU, to the unrooted Sprint 2.1 Android release in order to test this out.
Nope, that would negate the reason for a check sum.
The hash is calculated according to the current file/s so each time you alter it/them/an archive you will change your hash....
I've got unrooted official 2.2 device and I don't want to root it. The only thing I'd like to achieve is to remove some stock applications. While I can't remove apk files I thought about upgrading them to some empty versions without activities and intents.
I can prepare such upgraded apk with modified manifest without problems. The problem is to make an actual upgrade. From what I read the apk needs to be signed with the same key as the original. I get 'already exists' error which probably means the same resource but different certificate.
Is it possible to hack/resign such a file to be able to upgrade the stock application?
Hello.
I want to know how can I verify the digital signature of an APK file.
I'm currently downloading what calims to be a leaked Nexus 4 system dump.
When I right click->Properties on an exe file (on Windows), I can see Digital Signatures tab and there I can see certificates etc.
I want to do something similiar to APK files. In my current situation, I want to make sure apps I'll find on the download are actually unmodified, Google-made thing.
This will also come in handy in other situations.
Solutions that work on Windows are great, solutions that work on Android are also OK.
Thanks.
Hello lads, new poster here -
I've had a bit of an FRP issue with my phone, and after fiddling with this for a few hours, and searching for a few more (I ran out of google results after page 3), I've been completely unable to find a combination file for this specific model (U6CSF2). I've attempted to make one from a guide (Image attached), but the key step, renaming the AP file to a .zip and extracting some files, doesn't work as the new zip folder requires a password (Image attached as well).
Now, this password thing happened on two separate firmware folders I downloaded. Are these the same folders and one was ripped off and re-uploaded to a new site, or is this password a Samsung thing that someone here knows? (I was unaware you could even password encrypt a file just incase it gets re-zipped).
I'm a complete novice, probably doing something silly someone could point out, any help is appreciated, including this specific combination file if someone knows where to find it.
(I did try looking for the password around these downloads and by searching the name of the uploader, but to no avail.)
Turning it on and off again did not fix it. Any ideas?