When trying to update the media library (on the server that is) I get an error:
"Error updating database: SQLITE_LOCKED(6) Database table is locked"
I can update some folders, but with others I get this error.
Does someone know how to fix this?
Thnx! Sander
Edit I also get this error:
"Error beginning database transaction: SQLITE_ERROR(1)cannot start a transaction within a transaction"
hello,
maybee you find it out by yourself... but if you doesn't (or for other peoples) -> just delete the library.db file in the RemoteAmp directory (of course you must have to close the remoteamp.exe before you do this) and then all should be work fine
greetz from austria
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?
When I try to edit a string in cmhomeres.dll, at the end of each text line there is a \0x00 which is lost when saving the change (for all the strings in that resource number and not only for the particular line I'm trying to change). And if I type the \0x00 then the result is \\0x00.
I'm using PE Explorer and followed the instructions given in it's help (under How to edit stringtable strings). Tried both explained methods.
(Did a forum search and found no help for this subject).
What am I doing wrong?
Well.... 0x00 is a null-character, so it is impossible to replicate (as far as I am aware). What are the effects of modifying the string, excluding the \0x00 and running it on your phone? Are there errors? [ Did you remember to re-sign the DLL ... You can find the signer by searching the forum...] I haven't actually changed strings in the cmhome DLL...so I am not so sure on the subject.
Unsign - edit - sign. Yes, those steps were followed.
PE Explorer's help states that each line of the stringtable must end with a null character but so far I have not been able to force it into the text.
Tried with ResHacker but using that one the null-char in not even visible.
If I save to a text file, edit there and reintroduce into the dll now I even get CR-LF chars
Have not tried copying the file without null-chars to phone for testing because the help file already raised a flag about null-char and afraid to brick it.
Attached is the HTC_IME from the HTC Android 2.1 rom. I have extracted the AndroidManifest.xml and I want to tweak it so that it thinks it is revision level 5 (Android 2.0) instead of 6 (2.1). This will allow us to attempt to install it on our Droids! Right now it wont let you cause of the version difference.
So I have the manifest extracted but since it's in some binary format I cannot spot the area to change the 6 to a 5!
Does anyone have any experience with this that can lend a hand?
I've opened up this xml file with a hex editor and I can see this, but no number to change:
Code:
.v.e.r.s.i.o.n.N.a.m.e.....v.e.r.s.i.o.n.C.o.d.e.....m.i.n.S.d.k.V.e.r.s.i.o.n.....t.a.r.g.e.t.S.d.k.V.e.r.s.i.o.n.....n.a.m.e.....l.a.b.e.l.
Ok so I have found the spot by trial and error and changed the 6 to a 5. Now it throws a digest error. Any easy
Code:
12-01 17:41:24.357: WARN/PackageParser(1015): java.lang.SecurityException: META-INF/MANIFEST.MF has invalid digest for AndroidManifest.xml in /data/app/vmdl69536.tmp
I guess thats cause I didnt change the SHA1-Digest. Is this even possible to calculate a new one?
Code:
Name: AndroidManifest.xml
SHA1-Digest: fEnI7fRlROXrwteoq4qvTr9c4zs=
Ok, so you going to release one that will work on 2.0 or 2.0.1 firmwares that doesn't do the htc check?
Hi pcm2a,
Seems you need to re-sign the full apk.
Clean the Manifest file from all the SHA1-DIGEST lines and signa again the apk file.
There is also the SignApk tool as well.
pcm2a said:
Ok so I have found the spot by trial and error and changed the 6 to a 5. Now it throws a digest error. Any easy
Code:
12-01 17:41:24.357: WARN/PackageParser(1015): java.lang.SecurityException: META-INF/MANIFEST.MF has invalid digest for AndroidManifest.xml in /data/app/vmdl69536.tmp
I guess thats cause I didnt change the SHA1-Digest. Is this even possible to calculate a new one?
Code:
Name: AndroidManifest.xml
SHA1-Digest: fEnI7fRlROXrwteoq4qvTr9c4zs=
Click to expand...
Click to collapse
Can you tell me where you found the versionCode? I'm trying to do something similar myself.
hello everyone,
Well After a few weeks looking to find a guide with all the update scripts commands. I finally dove into the source from CM7 and stripped out the commands for writting scripts. most of the descriptions were straight from the source with slight rewording to try and make it a bit clearer. I hope this helps!
****commands*****
assert(bool);
tests to see if the argument passed to it is true. continues if true or fails when false
format(root)
wipes data starting at the point passed to it
delete<file1>[<fileN>...]
like rm -f. it will continue to delete even if previous delete failed.
delete_recursive<file or dir1[<file or directoryN>....]
same as delete except if it fails to delete early it will stop
copy_dir<source-dir> <dst-dir> [timestamp]
copies from source to dst. nothing in dst is changes unless something in source overwrote them. the timestamp is
in decimal seconds since 1970. if not supplied a default one will be used
ex: "copy_dir PKG:system SYSTEM:" will copy the contents of system to SYSTEM
run_program <program-file>[args....]
run a program included in the update package
set_perm <uid> <gid> <mode> <path>[<pathN>....]
set_perm_recursive<uid> <gid> <dir-mode> <file-mode> <path>[<pathN>....]
like "chmod" "chown" "chgrp" all in one. sets permissions and owner using integer values for linux permissions on
a single file or an entire directory tree. any error causes failure.
show_progress <fraction> <duration>
use <fraction> of the on screen progress bar for the following operation. fill acording to <duration> or faster if
the actual duration can be determined.
symlink <link-target> <link-path>
creates a symlink between <link-target> and <link-path>. <link-path> must be in rootath format however
<link-target> may be relative.
write_radio_image<src-image>
write_hboot_image<src-image>
copies radio or hboot image to the proper partition. will not take effect until the rest of the instalation
finishes.
write_raw_image <src-image> <destination-root>
write an image to ur specified partition
mark <resource> dirty|clean
marks the resource as dirty or clean. checks exist to insure that the entire file system is not marked dirty to
force a downgrade
**** function definitions *****
compatible_with(<version>)
returns true if the parser and command set support the named version
update_forced()
returns true if some part of the system has determined that the update should happen no matter what
get_mark (<resource>)
returns the current mark provided with <resource>
hash_dir(<path-to-dir>)
makes a hash for comparison uses of the provided dir
matches(<str1>, <str2> [,<strN> ...])
test to see if a supplied string matches. more than two may be supplied
concat(<str1>, <str2> [,<strN> ...]
combines all supplied strings
getprop(<property>)
returns the named Android system property value or "" if not set
file_contains(<filename>, <substring>)
returns true if file contains <substring>
thank you very much
This would be extremely helpful for a lot of people if update-script wasn't outdated by updater-script and binary.
Any chance you want to take on that project too?
Cayniarb said:
This would be extremely helpful for a lot of people if update-script wasn't outdated by updater-script and binary.
Any chance you want to take on that project too?
Click to expand...
Click to collapse
To be fair, a lot of ROMs, themes, etc still use update-script rather than updater/binary. Idk, I still use update-script a lot. Having some issues with the set_perm. Regardless, than you for the thread. I have found it rather useful.