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?
repack-zImage.sh is a bash script for Linux which allows you to unpack a kernel image (zImage) for modification and repack it afterwards into a new working kernel image.
You don't need a kernel tree for this program nor a compiler. It should work with any zImage that contains an initramfs, for whatever phone, operating system or CPU architecture you like.
My main purpose when I wrote it was to modify the initramfs of leaked Samsung i5800 firmware for which no kernel source is available.
Usage:
=====
Put the unzipped script into some directory along your $PATH (e.g., /usr/local/bin). Put the unpacked files from initramfs_utils.zip into /usr/local/bin.
Then simply run 'repack-zImage.sh -u' with your zImage in the current directory and it will create a directory named 'zImage_unpacked' which contains the unpacked blocks of your zImage. Refer to the comments near the start of the program to identify which file corresponds to which fragment of the original zImage. (The file name of the zImage should be "zImage". If it isn't, pass it as the only non-option argument. The subdirectory's name will change accordingly.)
Most notably, there will be a directory 'initramfs' in there, which contains all files from the original initramfs in their original tree. You can modify the contents as you like, but keep in mind that your initramfs cannot grow larger than the space reserved for it in the original zImage. So you're restricted to relatively small changes which should, however, satisfy many needs. You always can call a script or executable on some other partition (including the SD card if already mounted) if you need more room for your modifications.
After your modifications are done, cd back to the directory which contains zImage and zImage_unpacked and run 'repack-zImage.sh -p' to start the packing process.
This will create a directory called 'zImage_packing' which contains your new zImage (and a zImage.tar for loaders like ODIN). It will emit (between others) one or two messages about a padding being done and about how many bytes were padded. This number (or the lower number of the two) is an indication about how many compressed bytes are left for further additions to the initrd.
If your initramfs (or some other modified part) grows too large, the script will abort with an appropriate error message.
In initramfs-utils.zip, three programs are provided. They should be copied to /usr/local/bin:
* cpio_set0. This is a slightly modified cpio (compiled for 32 bit Linux). repack-zImage.sh will run without it, but there may be slightly more room in your initramfs if you use the modified one. It sets all file times in the archive to 0 (epoch), thus yielding better and consistent compression results. Else, the size of the compressed initramfs will differ from invocation to invocation due to differing atimes. Put it somewhere along your $PATH (e.g., /usr/local/bin).
* gen_init_cpio and
* gen_initramfs_list.sh. These are utilities copied from a kernel tree and used to support creation of an initramfs (in certain modes).
'repack-zImage.sh --help' will output usage information.
Happy hacking,
mizch
Current Version: 6
2011-05-03
('repack-zImage.sh --version' will output version information.)
- added support for lzma compressed ramdisks (both directions)
Version 4
2011-02-17
- Workaround for ambiguous gunzip result, see post #20
- Some code cleanup + CLI cleanup
- better error detection
Version 3
2011-01-06
- now also works with unzipped initramfs withing gzipped zImage part (i.e., all kinds of zImages)
Version 1
2011-01-05
- initial version. Works only for gzipped initramfs within gzipped zImage (e.g., G3 Eclair kernels)
-----------------------
repack-zImage.zip contains version 4 of the script.
For the newest version, download repack-zImage.v6.zip and initramfs-utils.zip.
It didn't work on zImage from Froyo firmware i tried. Great work however .
Works however for Eclair firmwares i've tested.
Good work.
Is this based off the i9000 script?
Also, I've noticed with the i5800 Eclair firmwares that the initramfs is gzipped AND cpio'd. So... Kernel + initramfs.cpio.gz are gzipped together.
Basically you need to extract [kernel+initramfs.cpio.gz].gz, extract initramfs.cpio.gz again, then extract initramfs with cpio.
On Froyo, the kernel + initramfs.cpio is gzipped together, but nothing more. So after you extract the kernel and initramfs, you just need to extract with cpio after that.
Hope that kind of helps..
In didn't go into Froyo for the i5800 until now. I used Eclair. It eases testing if you can compare things to a working kernel tree.
I see that Froyo doesn't use a compressed initramfs within the compressed kernel (which I doubt to make much sense anyway since compressing an already compressed part again is likely to produce a larger result). In theory, thus Froyo is easier to cope with than what I have now, but I have to write the code to handle it. This will need some time, maybe tomorrow, maybe the weekend.
And, no, this is not based on code from the i9000. It was written up from scratch. But I took some ideas from there and thank dkcldark for his good work.
mizch said:
In didn't go into Froyo for the i5800 until now. I used Eclair. It eases testing if you can compare things to a working kernel tree.
I see that Froyo doesn't use a compressed initramfs within the compressed kernel (which I doubt to make much sense anyway since compressing an already compressed part again is likely to produce a larger result). In theory, thus Froyo is easier to cope with than what I have now, but I have to write the code to handle it. This will need some time, maybe tomorrow, maybe the weekend.
And, no, this is not based on code from the i9000. It was written up from scratch. But I took some ideas from there and thank dkcldark for his good work.
Click to expand...
Click to collapse
If we can get this modified for Froyo, it will allow for native ext2 mounting within the initramfs. Then we can add things to it like the way CWM works - busybox, adb, etc... So that we have a recovery adb setup before /system mounts.
precurse said:
If we can get this modified for Froyo, it will allow for native ext2 mounting within the initramfs. Then we can add things to it like the way CWM works - busybox, adb, etc... So that we have a recovery adb setup before /system mounts.
Click to expand...
Click to collapse
Exactly, that could be very useful, since we could get ext2 (ext4 maybe if we compile it as a module ?) in /data natively
Gsam101 said:
Exactly, that could be very useful, since we could get ext2 (ext4 maybe if we compile it as a module ?) in /data natively
Click to expand...
Click to collapse
I already tried building ext4 and other modules off the i9000 sources... Didn't seem to work too well. Kept complaining about memmap or some random errors when I tried loading them.
Perhaps we can try them against JPF or something.
Heck.. or even allow a user to use a file off their SD card to loopback mount /system partitions... Or /data partitions - like how the i9000 has a (built-in) 16gb SD card.
precurse said:
I already tried building ext4 and other modules off the i9000 sources... Didn't seem to work too well. Kept complaining about memmap or some random errors when I tried loading them.
Perhaps we can try them against JPF or something.
Click to expand...
Click to collapse
I think so. Maybe we should just try to build an ext4 module with standard linux sources with armv6 as target ? Since i9000 has an armv7 processor..
Gsam101 said:
I think so. Maybe we should just try to build an ext4 module with standard linux sources with armv6 as target ? Since i9000 has an armv7 processor..
Click to expand...
Click to collapse
I setup my .conf to use the same CPU as what the G3 uses. I can't compile a kernel, but the modules compile.
It's a much different error I got from these modules than when I tried loading i9000 modules.
precurse said:
Heck.. or even allow a user to use a file off their SD card to loopback mount /system partitions... Or /data partitions - like how the i9000 has a (built-in) 16gb SD card.
Click to expand...
Click to collapse
Don't forget the internal SD of the sgs is on fast movienand SD memory, if one would loop back to his sdcard he would have to have a class 10 sdcard at least to get decent speed out of it.
I've posted a new version of repack-zImage.sh and the associated utilities in the first article of this thread. This version lifts the restriction which until now allowed only compressed initramfs disks. Now uncompressed ones are also supported.
This modification got somewhat tricky, as a newly created initramfs, when compressed, yields sizes different from the original (even if it contains exactly the same files) due to different ordering of the files. For a 2 MB ramdisk, a difference of 3k may not sound like much, but it is - if it is too large by this number in a zImage where the initramfs must fit into the original's room.
Some black magic was needed. Now the files are ordered like in the original, with additional files (if created by the user) appended at the end. Options are provided to change the optimisations if needed.
I tried with JPF and with JPA-custom, so changes are really good that you won't have to bother with the above and can just go ahead and do your own initramfs modifications.
Yeah, that worked for me. Thanks a lot .
have we (you all) found a way to unpack the froyo zimage yet? it worked great on eclair. thank you. and thanks for any help that you might provide.
i have tried on froyo for the epic but as it is unpacking it keeps looping 2 sets of numbers when i run the script. 5748017 5749018 and keeps repeating. any help would be great.
/Data and /cache ext2 conversion script.
Gsam101 said:
Exactly, that could be very useful, since we could get ext2 (ext4 maybe if we compile it as a module ?) in /data natively
Click to expand...
Click to collapse
hey here's a script that converts /data and /cache to ext2... i tried it.. worked for me.. i did not made this.. !
this is the work of MOTAFOCA !
quadarant score went from 305 to 515 and the best part.. internal memory shrunk from 176Mb to 161 Mb only
the script says its for i5508 but was made for 5800 as said by barquers
anyways.. here's the script.. hoping it will help
http://multiupload.com/O2ET4B8K0A
PS: im using MOTAFOCA's ROM... and script was made by MOTAFOCA not me
spdwiz18 said:
i have tried on froyo for the epic but as it is unpacking it keeps looping 2 sets of numbers when i run the script. 5748017 5749018 and keeps repeating. any help would be great.
Click to expand...
Click to collapse
It should work for any zImage. Sounds like a bug in the end detection for a compressed part. Can you provide me with a link to the zImage or contact me directly (PM/E-Mail) to pass me a copy? Then I'll go into it.
hey. does the script allows us to tweak the kernel so that it can be overclocked? ??
or we still need to wait for the kernel sources?
coolzarjun said:
does the script allows us to tweak the kernel so that it can be overclocked?
Click to expand...
Click to collapse
You cannot do that without writing your own cpufreq driver (if at all). You need the kernel sources to do this.
mizch said:
It should work for any zImage. Sounds like a bug in the end detection for a compressed part. Can you provide me with a link to the zImage or contact me directly (PM/E-Mail) to pass me a copy? Then I'll go into it.
Click to expand...
Click to collapse
Soryy gmail was not syncing for somereason. I will send tou what I have when I get home from work thanks.
Got the zImage, thanks. I could reproduce the problem. What happens:
Using gzip's magic number, I can tell the start of a gzipped section. To determine its end, I need the help of gunzip. It reports "trailing garbage" if its file is too long, "truncated file" if too small, "OK" otherwise.
With your zImage, gunzip reports "truncated" when fed with 5749017 bytes, "trailing garbage" at 5749018. Obviously, only one of the two (not both!) can be correct. But this is what gunzip reports in your case. I found that 5749016 is the correct size. Erm.
As a workaround, I now detect when the gunzip result is oscillating this way and if it does, I search nearby towards lower size values for an exact match. This is not an ideal solution but I have to deal with what gunzip returns and this fits it best.
I'll do some cleanup and some final tests now and if they succeed, I will post the new version in about an hour or so in the first posting of this thread.
EDIT: New version posted.
So almost everyone here should be pretty familiar with android, and that means you've probably heard of (and maybe even used yourself) the windows tool APK Manager by fellow XDA member Daneshm90.
Early last year I started to port the windows 4.9 version to mac using the outdated linux script for a base. And I had some early success at the time with simply using macports to install sox, optipng, etc. And then my computer crashed (double drive failure in July, 2011) and I gave up for the time being. Recently though I was excited to find that someone else tried to do the same thing, XDA member MAD Industries released a very basic port for mac.
Sadly though, a quick diff of his script and the outdated linux version shows that it was still woefully behind the windows version. And so I started working (once again) on my own port of APK Manager for Mac OS X, with my goal to not only bring this current to the windows feature set, but exceed it in many ways.
I've built in 32/64-bit architecture checking, and compiled and include the required missing binaries to re-enable optimizing png images and ogg files. I'm also including a .terminal file for easily configuring the default display, and a copy of my NEW favorite fixed-width font, Bitstream Vera Sans Mono.
And now some notes, and requests:
PLEASE note: this is currently INTEL only, but it supports both 32-bit and 64-bit all-in-one with architecture checking built-in to the script.
PLEASE note: if your computer is running OS X 10.7.X, "Lion" then it does not include a java runtime by default, please download it here first: http://support.apple.com/kb/DL1421
PLEASE note: due to the length of some of the strings used in the menus, etc., in order to not need to scroll your terminal window, you must adjust your default columns and rows settings. You can set this automatically by using the include "JocelynCustom.terminal" file, and you can also find simple instructions to set this yourself in the README.txt
PLEASE read the included readme for installation and very basic (for right now) usage instructions. I welcome any and all feedback on improvements for the readme file.
PLEASE report any and all bugs or generally wonky behavior, preferrably by posting here in this thread, or by posting a comment back on my blog.
LASTLY, please if you re-post this anywhere else, including blogs, other forums, etc. I would greatly appreciate if you would at least give me credit, and link back to my blog (http://girlintroverted.wordpress.com/) or at the very least, link back here to this post.
WHEN UPGRADING, DO NOT COPY OVER THE CONTENTS OF THE "other" directory or the root directory unless you absolutely know what you're doing.
IMPORTANT: Please see the second post in this thread for update notes, issues, concerns, etc. thanks
Download apk manager v2.2.5 here: http://www.mediafire.com/?o4idx4en9ldnwx4
Download migration tool v1.4 here: http://www.mediafire.com/?hbhftv9195tk86t
v3.0 BETA INFORMATION
May 11, 2012 - beta version of v3.0 is online now on github, if you want to help test it, I suggest backing up your old apk_manager directory entirely, and then going here, and reading the simple install instructions:
https://github.com/jocelynmallon/apkmanager
The basic install is pretty simple though: open terminal, cd into whatever directory you want the apkmanager folder to be created in, and run:
cd into whatever directory you want the apkmanager folder to be created in, and run:
Code:
git clone git://github.com/jocelynmallon/apkmanager.git
launch APKManager.app and follow all the instructions.
Also, git is utterly retarded when it comes to the OSX 'icon' resource files (for custom folder icons) so by default, the folder icon isn't included with 3.0+, but you can download it and apply it yourself still. Link is on the wiki here:
https://github.com/jocelynmallon/apkmanager/wiki/Basic-Information
and thank you very much to anyone that helps test this!
Cheers everyone
IMPORTANT!
5-11-2012 - v3.0 BETA notes
Some notes about the new v3.0 beta released today.
First, please backup your entire old apk_manager directory before you install/clone the 3.0 git repo. My OCD got the better of me when it came to releasing 3.0, and I ended up trashing my entire git repo/history (from v1.0-2.2.5) and starting a new history when I was ~90% through the 3.0 dev process. Because of that, your old directory will cause problems, DO NOT CLONE/INSTALL 3.0b into your old 1.X/2.X directory.
Second, for those comfortable with the command line that really want to help test APK Manager, there are four 'hidden' menu options in most menus (main menu, debug/settings menu, auto-updates menu, signing menu, clean menu) that turn on a variety of debugging options.
96) turns on 'trace mode' (set -x) for the entire script, once the main loop starts. This will make the script basically unusable for people, please only use this if you can reproduce a bug, and are saving the entire terminal output to submit an issue/error log.
97) turns on 'verbose mode' (set -v) for the entire script, once the main loop starts. This will cause some display issues, but the script will remain mostly usable.
98) turns on 'error mode' (set -e) for the entire script, once the main loop starts. This basically causes the script to exit if any condition/test/command fails. Not really useful on its own, but very useful in combination with option 96 or 97.
99) turns on a very (and I do mean VERY) simple debug information display between main apk manager header and most menus. This shows the current PID, the last exit/return code (Currently non-functional) and the last directory change.
So, if you can reproduce any bugs, please close apk manager, and delete your log.txt. Then open APK Manager again, and on the main menu, choose option 98, then next choose option 96. Then reproduce the bug, and copy/paste the entire terminal output into a log on pastebin.com, gist, etc., and send it to me. And of course, if you feel confident debugging and fixing it yourself, then fork the apkmanager repo, and send me a pull request with your changes.
4-14-2012 IMPORTANT!
An update to the issue below. This has been resolved in version 2.1 of APK Manager, and should not present any issues moving forward. However, because the old user settings and private keys were stored locally, inside the apk_manager directory, in order to save these before upgrading, I've created a migration utility/script, that needs to be run before you upgrade.
The link to this migration utility is in the original post in this thread, and the tool is also included in the APK Manager disk image starting with versions 2.1.1.
To run this tool:
mount the "Migration Utility.dmg"
Copy Migrate.app to your old root apk_manager directory.
Copy Migrate.sh to your old apk_manager/other directory.
From your old root apk_manager directory, run Migrate.app
Verify that the script completed without any errors
OPTIONAL - for those paranoid, you can double check that it worked manually. Execute the following commands in a terminal:
Code:
cd $HOME
ls -la | grep .apkmanager
cd .apkmanager
ls -la
4-13-2012 IMPORTANT!
AFFECTS all versions of apk manager prior to v2.1 (forthcoming release as of 4/13/2012.)
If you use any advanced signing functionality, you must backup your existing private key(s) and keystore(s) before upgrading to a new version of APK Manager.
Forthcoming version 2.1 will have a separate, automated, one-time backup & upgrade script to run, and all future versions will have automatic backup of key(s) and keystore(s) built in.
By default they get created and saved in the apk_manager/other/.keystores directory. This is a hidden directory by default. You can do one of several different things to unhide/view this directory, and backup your keystore(s).
I'm outlining one simple method here.
Enable 'show hidden files' in Finder. From a terminal copy and paste the following two lines:
Code:
defaults write com.apple.finder AppleShowAllFiles TRUE
killall Finder
Finder will restart after those two lines, browse to your apk_manager/other directory and make sure you see the .keystores folder (it should be dimmed compared to regular folders.)
Copy this folder and all contents somewhere safe (desktop, user home directory, user backup folder, dropbox, etc.)
Proceed with your upgrade (usually just delete the old apk_manager folder and copy over the new one, you might need to manually move project folders, etc. too)
Copy/Paste your saved .keystores directory into your new apk_manager/other folder
Test advanced signing functionality to ensure everything still works.
Once you've verified everything is working, run the following code to turn off viewing all files/folders in finder:
Code:
defaults write com.apple.finder AppleShowAllFiles FALSE
killall Finder
CHANGELOG
10-8-2012
fixed a couple bugs that were introduced with some changes to homebrew and pngcrush
updated smali.jar and baksmali.jar to version 1.4.0
fixed a few various typos
updated the built-in pngout downloader to download the newest version (May 30, 2012)
changed the "view changelog" option on the debug menu to use "git log" if you used homebrew & git to install
added the ability to forcibly reset the "home" directory by holding the command/apple key when launching APKManager.app
removed all the little "b/beta" tags I could find since this seems good enough for a "real" 3.0 release finally
4-28-2012
v2.2.5 uploaded! - Fixed "adb log" function. I have no idea how or when I broke this, but it was yet another boneheaded mistake.
4-28-2012
v2.2.4 uploaded! - Fixed a bug in the "batch sign with private key" option that would cause the signing process to fail if the key and keystore password weren't identical.
4-24-2012
v2.2.3 uploaded! - I'm retarded and somehow failed to include zipalign in every release. Fixed.
Added zipalign path information to debug/binary info screen.
Replaced all instances/uses of 'which' with 'command -v' instead.
Fixed an obscure bug that could cause infinite loop in the function to check and set png optimization tool.
4-20-2012
v2.2.2 uploaded! - Updated 32-bit optipng to v0.7.1 (Somehow I forgot to update the 32-bit binary when I last updated the 64-bit version)
Minor changes to the way debug/binary version info is scraped and displayed. I personally think this new method is cleaner, and more consistent.
Fixed bug in binary display screen (debug menu, option 2) whereby pressing "any key" did not actually close the screen and return to debug menu.
Updated other/Migrate.sh to dynamically pull the APKManager version banner from whichever other/Script.sh version is present, when its run. This should mean the end of unnecessary updates to Migration Utility.dmg, purely to bump the APK Manager version information.
4-17-2012
v2.2.1 uploaded! - Updated pngcrush to 1.7.27 (yep, that's it, lol)
4-16-2012
v2.2 uploaded! - Integrated color scheme selection into one single script, and removed the separate 'black text on light backgrounds' script file since its no longer needed.
Added new option to the "Clean" menu to reset/change color scheme.
Fixed a few obscure bugs with the apktool selection menu.
Added the actual apktool jar file in use to the debug menu information.
Changed the way the default apktool.jar symlink is created in order to prevent APK Manager from ever linking 'mod' versions by default.
Added a new custom icon for the apk_manager folder (CC by-nc-sa) Jocelyn Mallon, 2012
4-15-2012
v2.1.2 uploaded! - Fixed a bug causing decompile/compile errors due to old framework files not being deleted when changing apktool versions.
Added 2 new apktool versions, an upgraded 1.4.2 version, and 1.4.3 ICS Mod. For most instances, 1.4.3 is still the best option to use.
4-14-2012
v2.1.1 uploaded! - Fix brain-dead mistake regarding user settings & private key migration.
Packaged "Migration Utility.dmg" with APK Manager for easier upgrading from previous versions.
4-14-2012
v2.1 uploaded! - Migrated user settings and private keys to new location ($HOME/.apkmanager) to ensure preservation when upgrading.
Bumped copyright/CC info in various files to 2012
4-12-2012
v2.0.1 uploaded! - Quick hotfix for directory check/creation for advanced signing options.
4-12-2012
v2.0 uploaded! - Re-packaged into a DMG (mac disk image) file to alleviate potential unzip/setup errors.
Updated a lot of the various binaries to latest versions (adb, sox, optipng, pngcrush, etc.)
Added a new option to view java source, this has a lot of potential issues/caveats so please read the CHANGELOG.txt for more information.
Re-worked and (hopefully) simplified debug menu for the millionth time.
Added Chocolat.app to list of text editors/viewers http://chocolatapp.com/
Lots of stuff I probably missed, please read README.txt and CHANGELOG.txt for full details.
10-18-2011
v1.2.1 uploaded! - Mostly bugfixes for a few really stupid bugs I introduced in 1.2. If you had problems running APK Manager because of "missing programs" or "not in PATH" errors (from a clean install) it was my crappy coding skills, and it should be fixed now.
I honestly don't think I added any new features, just bug fixes and code cleanups.
10-10-2011
v1.2 uploaded! - Added another png tool option, pngout. Unfortunately, due to the licensing restrictions, it is illegal to redistribute the actual pngout binary, so instead, APK Manager will download and install the binary upon first attempted use of pngout. This means that if you never use pngout, it will never be downloaded.
Completely re-worked the adblog.txt function, now completely automated, and, with much clearer instructions.
Added two additional text editor/log viewer options: sublime text 2, and vico. Just like all the rest, they both require command line support to be installed in order to function.
Cleaned up adb shell, ddms, and draw9patch options so that they all now automatically close the new tabs that they open, and when necessary, will kill and re-start adb.
1.2 might be the last release. I had fun learning how to write shell script for this, but the overwhelming lack of interest in this project has already started to make it no fun for me. And well, its already basically good enough for everyday use, there's just not much else to keep adding.
10-8-2011
v1.1 uploaded! Please see Changelog.txt for full details.
switched some code back to a "portable" syntax and changed back to /bin/sh env in case users have a login shell other than bash set.
cleaned up and re-arranged debug menu again, it should be a lot less cluttered, and easier to use overall now.
fixed a few bugs in the startup check, hopefully nobody ever encountered them, they were pretty embarrassing, lol.
added option to choose between optipng and pngcrush for png optimization functions, and the setting is persistent between launches of APK Manager.
Good work man. Let me know if you'd like to collaborate or borrow ideas. I wrote Android-Utility and it is currently on v1.0.2 and development is active.
Tommy
Android-Utility Linky
tommytomatoe said:
Good work man. Let me know if you'd like to collaborate or borrow ideas. I wrote Android-Utility and it is currently on v1.0.2 and development is active.
Tommy
Android-Utility Linky
Click to expand...
Click to collapse
Hi Tommy,
Thanks for the compliment and the offer to work together. I'm not really sure how much else I'm going to add, but I did take a nod from your tool and add the option to choose between optipng and pngcrush. Mostly I added that just because optipng hasn't been updated in forever, and pngcrush just had an update last month.
So I compiled both 32-bit and 64-bit specific binaries of the newest pngcrush (v1.7.17) and included them with v1.1 of APK Manager.
Anyway, your tool is pretty amazing, I'm rather intimidated by how many features you have, lol.
Thanks again, cheers
s0niqu3 said:
Hi Tommy,
Thanks for the compliment and the offer to work together. I'm not really sure how much else I'm going to add, but I did take a nod from your tool and add the option to choose between optipng and pngcrush. Mostly I added that just because optipng hasn't been updated in forever, and pngcrush just had an update last month.
So I compiled both 32-bit and 64-bit specific binaries of the newest pngcrush (v1.7.17) and included them with v1.1 of APK Manager.
Anyway, your tool is pretty amazing, I'm rather intimidated by how many features you have, lol.
Thanks again, cheers
Click to expand...
Click to collapse
Back at you man. Yeah last week I went crazy. I went from version 1.0.2 to version 1.0.7 in three days. There's always something new that can be added.
Don't be intimidated! AU and apkmanager each have their places. I aimed to create a tool that encompasses everything to do with Android while apk manager focuses on modifying apks. Surprisingly however while I wrote the tool for mac users, I've had mote Linux users for au. But the mac community needed some love and attention, and now it has two tools to choose from
tapatalk signature here. lovely.
version 1.2 released, this might be the last release, I can't think of anything else to add really, and well, nobody really cares either, lol.
great work
1.2.1 uploaded with a few bugfixes, please re-download, and I'm really sorry I didn't catch them sooner until someone messaged me today.
Wow, this is amazing! So glad I don't need to boot into WinXP just to use apkmanager. I just downloaded the newest version, followed all instructions, and everything is working perfectly. Thanks for including all the extras such as terminal settings. Great for semi-noobs like myself.
Can't wait to try this tool out. Thanks for all the hard work in putting it together.
this not working anymore? Says applet version unsupported
Nhialor said:
this not working anymore? Says applet version unsupported
Click to expand...
Click to collapse
Yes same here
Hey,
Sorry, I'm pretty much stopped doing any work on android, but if you can describe the error in more detail, I'll look into it and try and fix the problem.
Sorry about that.
s0niqu3 said:
Hey,
Sorry, I'm pretty much stopped doing any work on android, but if you can describe the error in more detail, I'll look into it and try and fix the problem.
Sorry about that.
Click to expand...
Click to collapse
OK cool.
So it's not possible to start the setup file, because it's unsupported and starting the apk manager directly is also not possible because it has to be in the root directory
Gesendet von meinem Desire S mit Tapatalk
Kolo39 said:
OK cool.
So it's not possible to start the setup file, because it's unsupported and starting the apk manager directly is also not possible because it has to be in the root directory
Gesendet von meinem Desire S mit Tapatalk
Click to expand...
Click to collapse
Hi again,
Ok, so first, you can set the root directory manually if you open up the APKManager.command file with a text editor.
Look for the following:
Code:
# Set path to use this script in .command mode
# ENTER the POSIX path to your root APK Manager
# Directory between the quotation marks
MAINDIR=""
and inside the MAINDIR="" paste the full path to your apk_manager directory
for example, mine looks like:
Code:
MAINDIR="/Volumes/LappyHD/Android/apk_manager"
then you need to manually make the entire directory executable, so open a terminal window, and type:
Code:
chmod -R ug+x /Volumes/LappyHD/Android/apk_manager
But replace the path with the correct path for your setup (the same one you used in the .command file.)
Of course, that's not the solution for everyone, and I'd like to figure out why the setup script isn't working. I tried the setup script myself today on 10.7.3, x86_64 and it still works fine for me, so can you post some information about your mac, version information, java version installed, etc.?
sorry again about this, but hopefully I can get this fixed asap.
cheers,
s0niqu3 said:
Hi again,
Ok, so first, you can set the root directory manually if you open up the APKManager.command file with a text editor.
Look for the following:
Code:
# Set path to use this script in .command mode
# ENTER the POSIX path to your root APK Manager
# Directory between the quotation marks
MAINDIR=""
and inside the MAINDIR="" paste the full path to your apk_manager directory
for example, mine looks like:
Code:
MAINDIR="/Volumes/LappyHD/Android/apk_manager"
then you need to manually make the entire directory executable, so open a terminal window, and type:
Code:
chmod -R ug+x /Volumes/LappyHD/Android/apk_manager
But replace the path with the correct path for your setup (the same one you used in the .command file.)
Of course, that's not the solution for everyone, and I'd like to figure out why the setup script isn't working. I tried the setup script myself today on 10.7.3, x86_64 and it still works fine for me, so can you post some information about your mac, version information, java version installed, etc.?
sorry again about this, but hopefully I can get this fixed asap.
cheers,
Click to expand...
Click to collapse
I try this in the next days
My Mac Book Pro end 2011 has all updates installed (Lion 10.7.3)
---------- Post added at 05:17 PM ---------- Previous post was at 05:07 PM ----------
Ahh okay I fixed it!!!
The Unarchiver was not able to extract all files from the zip. So files doesn't work. But by using OSX Unarchiver everything works
Thanks a lot for this port!!
Kolo39 said:
I try this in the next days
My Mac Book Pro end 2011 has all updates installed (Lion 10.7.3)
---------- Post added at 05:17 PM ---------- Previous post was at 05:07 PM ----------
Ahh okay I fixed it!!!
The Unarchiver was not able to extract all files from the zip. So files doesn't work. But by using OSX Unarchiver everything works
Thanks a lot for this port!!
Click to expand...
Click to collapse
Hi again,
I'm glad you got it figured out. I think I'll start packaging it as a DMG file instead of a zip, and just made a custom background image to explain about copying the apk_manager folder somewhere.
I've also been working on updating it a little bit the past couple days, and will have a new version soon.
Cheers!
Uploaded version 2.0 update!
This adds a couple new features, some bug fixes, and re-packages the entire thing in a disk image, to hopefully alleviate those unzip/setup errors.
Please see OP for download link, and second post for changelog.
OP update with v2.0.1, hotfix for advanced signing options, please download the newest version.
Some time ago I sold my old android phone and forgot to make a backup of SMS messages and call logs, but kept a complete image backup made by clockworkmod recovery (system.img, data.img, etc.). I wanted to import my SMS messages and call logs to a new phone, but without a reasonable backup this seemed to be impossible. Some quick search over the internet showed that a question about extracting/importing SMS messages from mmssms.db is not so uncommon, but there are no tools to do this. So I wrote one, and decided to share
Sources are available at github.com abbot/android-restore-tools.
It requires Python 2.6 and above to run.
I've also made compiled binaries for windows, attached to this post.
[Binaries last updated on 12.04.2011]
Thanks for the tools. Nice work.
Sent from my GT-I8150 using XDA
Hello,
I'm trying to use your tool to extract SMS from a nandroid backup.
I'm using the data.yaffs2.img file from the backup.
When I choose #2 for mmssms.db and then "s" to extract SMS I get the following error:
Failed to extract messages: file is encrypted or is not a database
DatabaseError('file is encrypted or is not a database',)
Warning: failed to remove temporary file...
What does this mean, and is there a solution?
Hi,
This may be caused by two things: either my tool can't properly read/extract the image file, or it can't read the database.
Please try to extract the image (extract -x data.yaffs2.img). If this does not produce any errors, find the mmssms.db file in the extracted data, it will probably be in data/com.android.providers.telephony/databases/mmssms.db. Then try to run extract -s mmssms.db. Please post if you get any errors doing these steps.
There was an error while extracting the image...it got through partway, but then failed at some bluetooth directory with colons in the path.
So I used a different tool to extract it, which went successfully.
Then I ran extract -s mmssms.db which came with the same error.
I'm pretty sure there isn't some weird encryption since I opened it up with Notepad ++ and I could read bits and pieces of conversations.
Anything else to try?
This might be caused by an older sqlite3 version bundled with binaries. I have updated the binaries in the first message to a newer version, could you download it and try again, extract -s mmssms.db?
Different error this time:
Failed to extract messages: no such column: failure_cause
OperationalError('no such column: failure_cause',)
Warning: failed to remove temporary file...
FYI the first thing at the top of the file when I open in Notepad++ is SQLite format 3 and this is from an HTC device running Android 4.x does that help at all?
This is much better and now makes sense: android 4.0 usually has sqlite 3.7.x, previous binary build of this tool had sqlite 3.6.21, and that was the reason for the 'file is encrypted or is not a database' error.
Now it looks like mmssms.db format in Android 4.0 has changed a little bit. I will have a look on these changes and update the app accordingly. Hope it will not take too much time
abbot2 said:
This is much better and now makes sense: android 4.0 usually has sqlite 3.7.x, previous binary build of this tool had sqlite 3.6.21, and that was the reason for the 'file is encrypted or is not a database' error.
Now it looks like mmssms.db format in Android 4.0 has changed a little bit. I will have a look on these changes and update the app accordingly. Hope it will not take too much time
Click to expand...
Click to collapse
That would be awesome, perhaps keep the old version available for other folks too though
If you can get this working I'll be sure to send a couple bucks your way. Thanks!
I have updated the extractor again, did some limited testing with android 4.0.3 on the emulator - seems to work. This database has a number of fields removed on android 4 compared to android 2, however everything required for xml dump is still there - just had to remove some unused stuff. Download the new version and try again.
Regarding the older versions, no reason to keep them - new one works fine with old database formats.
Awesome works perfectly! Send me a PM where to donate.
Sent from my GT-I9000 using xda premium
Thanks! It really works perfectly. Any plans to include MMS?
Sorry for the noobish question but I'm not familiar with Python.
Installed newest version of Python and also got the extracted mmssms.db and contacts2.db (used Nandriod Browser to extract them), which command lines do I need/what do I have to do? :s
€dit: Downloaded the zip from github and got as far as opening mmssms2xml.py which gives me an error when opening the mmssms.db
Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Python27\lib\lib-tk\Tkinter.py", line 1410, in __call__
return self.func(*args)
File "D:\Downloads\abbot-android-restore-tools-bc8584d\abbot-android-restore-t
ools-bc8584d\mmssms2xml.py", line 99, in open_file
self.messages = read_messages(filename)
File "D:\Downloads\abbot-android-restore-tools-bc8584d\abbot-android-restore-t
ools-bc8584d\mmssms2xml.py", line 33, in read_messages
c.execute("SELECT _id, thread_id, address, person, date, protocol, read, pri
ority, status, type, callback_number, reply_path_present, subject, body, service
_center, failure_cause, locked, error_code, stack_type, seen, sort_index FROM sm
s ORDER BY date DESC")
OperationalError: no such column: priority
Click to expand...
Click to collapse
€dit2: No problems with contacts2.db?!
€dit3: Well..this should be the last, found this explanation of rani2001 over here (http://forum.xda-developers.com/showpost.php?p=25173166&postcount=7). That did it for me!
Dude you just made my day
Can you please compile a new windows version with the latest files from github?
Or give us a manual how to use the .py files.
I think this will help many of us.
Thank you very much.
BTW: Your tool worked perfectly with my mmssms.db but failed with contacts2.db. Maybe the new files requested above will help me.
Got all my sms back thanks to you.
Amazing script, Thanks for sharing and explaining and updating.
60% There
I was just wondering if there was anything special I had to do to merge my old SMS list and the ones from the new list. I didn't see an option there for it and I don't want to just paste it in there and load it. Many thanks ahead of time
Hi I want to extract the data.yaffs2.img from my HTC Desire nandroid backup but get the error message:
> extract.exe -s data.yaffs2.img
Failed to extract messages: file is encrypted or is not a database
Any ideas?
I tried this tool yesterday evening and I'm truly grateful for your work!
I was ready to spend the whole night to work with these damn tables when I found your work. Many thanks! :highfive:
Where is the file stored after i run it? This is what I got.
Code:
C:\Users\Damastah>C:\Users\Damastah\Downloads\yaffs-mmssmsdb-calls-extractor\ext
ract.exe -s D:\S3_recovery\mmssms.db
Read 1782 messages
Save as (empty=sms-20130330111807.xml): y
I just bought a used fire phone (note that this is rather a general security question, though, so I'm posting it here). Let me say, I am not an experienced user with Android, rather Linux, so I figured that owning a device without root access would not make sense. I realized that kingo root would be the solution to go with, and used it with immediate success. After getting access, I immediately removed the kingo application and several leftovers which are mentioned everywhere, went with super root, and felt safe.
However, I now realize that vital system files have been tampered with at some time in this procedure, among them /system/lib/libc.so, which really makes me nervous. Anyone has a clue? A better description follows.
Since I knew I was going to uninstall kingo root later, I started by saving the current configuration accessible to the shell user for reference via a command line like
./adb shell /data/local/tmp/busybox tar -cvf /sdcard/backup.tar --exclude proc --exclude storage --exclude mnt --exclude sys --exclude dev /
I then downloaded the android version of kingo root, started it, and bingo, it went root. That felt strange. Think of a userland program getting administrator rights on LInux or Windows - people would go berserk. In this case, no one really seems committed to closing this gap. Anyway, I had what I wanted. I saved the current configuration again using the command line above.
I then downloaded the kingoroot removal shellscript from //androidmtk.com/replace-kinguser-with-supersu and more or less followed its removal instructions for kingo root. At some point, you uninstall the kingo app - and it tells you, it will not be able to restore your phone to the old state and might actually brick it. Again, that feels strange, I can hardly think of changes that cannot be undone, unless you don't want to undo them. I then installed supersu via the play store, all went smoothly, and I saved the third configuration with the command line above.
On my Linux desktop, I then extracted all three tarfiles and detected the differences. Of course, those files mentioned everywhere had been added and showed up (like install_recovery.sh and so on). I didn't care too much about these. But there were more. In fact, the differences between the original Android version and the kingoroot-version included vital libraries:
Binary files old/system/lib/libLLVM.so and new/system/lib/libLLVM.so differ
Binary files old/system/lib/libc.so and new/system/lib/libc.so differ
Binary files old/system/lib/libharfbuzz_ng.so and new/system/lib/libharfbuzz_ng.so differ
Binary files old/system/lib/libicuuc.so and new/system/lib/libicuuc.so differ
Binary files old/system/lib/libsqlite.so and new/system/lib/libsqlite.so differ
Comparing the first and third version, after kingoroot deinstallation and superroot installation, shows even more:
Binary files old/system/lib/hw/bluetooth.default.so and newest/system/lib/hw/bluetooth.default.so differ
Binary files old/system/lib/libEGL.so and newest/system/lib/libEGL.so differ
Binary files old/system/lib/libEnsembleEngine.so and newest/system/lib/libEnsembleEngine.so differ
Binary files old/system/lib/libLLVM.so and newest/system/lib/libLLVM.so differ
Binary files old/system/lib/libandroid_runtime.so and newest/system/lib/libandroid_runtime.so differ
Binary files old/system/lib/libc.so and newest/system/lib/libc.so differ
Binary files old/system/lib/libcameraservice.so and newest/system/lib/libcameraservice.so differ
Binary files old/system/lib/libeuclid.so and newest/system/lib/libeuclid.so differ
Binary files old/system/lib/libeuclidogre.so and newest/system/lib/libeuclidogre.so differ
Binary files old/system/lib/libharfbuzz_ng.so and newest/system/lib/libharfbuzz_ng.so differ
Binary files old/system/lib/libicui18n.so and newest/system/lib/libicui18n.so differ
Binary files old/system/lib/libicuuc.so and newest/system/lib/libicuuc.so differ
Binary files old/system/lib/libkinesis_service.so and newest/system/lib/libkinesis_service.so differ
Binary files old/system/lib/libnfc-nci.so and newest/system/lib/libnfc-nci.so differ
Binary files old/system/lib/libodl.so and newest/system/lib/libodl.so differ
Binary files old/system/lib/libsqlite.so and newest/system/lib/libsqlite.so differ
Binary files old/system/lib/libstagefright.so and newest/system/lib/libstagefright.so differ
Only in newest/system/lib: libsupol.so
Binary files old/system/lib/libwebviewchromium.so and newest/system/lib/libwebviewchromium.so differ
Binary files old/system/vendor/lib/libsc-a3xx.so and newest/system/vendor/lib/libsc-a3xx.so differ
And I can confirm, they really differ, I can see the differences byte by byte - meaning that at some point they have been tampered with. Creation and modification times did not change, though.
I have three choices now: An OTA update happened while I did the rooting. Or I really now have system libraries that "someone" (me) installed on my mobile. Honestly, I don't dare restoring the old files, unaware of what might happen. The usual thing I'd do in Linux: copy the old files back, mv -f oldfile newfile. However, there's never a fear of being locked out on a desktop. Or, last chance: I am stupid and lib files just don't look the same when you look at them as an ordinary user at different points in time...
Any advice? Should I overwrite the new versions with the originals? Or is it just "normal" on Android?
Best wishes, Frank
fwuebbel said:
I just bought a used fire phone (note that this is rather a general security question, though, so I'm posting it here). Let me say, I am not an experienced user with Android, rather Linux, so I figured that owning a device without root access would not make sense. I realized that kingo root would be the solution to go with, and used it with immediate success. After getting access, I immediately removed the kingo application and several leftovers which are mentioned everywhere, went with super root, and felt safe.
However, I now realize that vital system files have been tampered with at some time in this procedure, among them /system/lib/libc.so, which really makes me nervous. Anyone has a clue? A better description follows.
Since I knew I was going to uninstall kingo root later, I started by saving the current configuration accessible to the shell user for reference via a command line like
./adb shell /data/local/tmp/busybox tar -cvf /sdcard/backup.tar --exclude proc --exclude storage --exclude mnt --exclude sys --exclude dev /
I then downloaded the android version of kingo root, started it, and bingo, it went root. That felt strange. Think of a userland program getting administrator rights on LInux or Windows - people would go berserk. In this case, no one really seems committed to closing this gap. Anyway, I had what I wanted. I saved the current configuration again using the command line above.
I then downloaded the kingoroot removal shellscript from //androidmtk.com/replace-kinguser-with-supersu and more or less followed its removal instructions for kingo root. At some point, you uninstall the kingo app - and it tells you, it will not be able to restore your phone to the old state and might actually brick it. Again, that feels strange, I can hardly think of changes that cannot be undone, unless you don't want to undo them. I then installed supersu via the play store, all went smoothly, and I saved the third configuration with the command line above.
On my Linux desktop, I then extracted all three tarfiles and detected the differences. Of course, those files mentioned everywhere had been added and showed up (like install_recovery.sh and so on). I didn't care too much about these. But there were more. In fact, the differences between the original Android version and the kingoroot-version included vital libraries:
Binary files old/system/lib/libLLVM.so and new/system/lib/libLLVM.so differ
Binary files old/system/lib/libc.so and new/system/lib/libc.so differ
Binary files old/system/lib/libharfbuzz_ng.so and new/system/lib/libharfbuzz_ng.so differ
Binary files old/system/lib/libicuuc.so and new/system/lib/libicuuc.so differ
Binary files old/system/lib/libsqlite.so and new/system/lib/libsqlite.so differ
Comparing the first and third version, after kingoroot deinstallation and superroot installation, shows even more:
Binary files old/system/lib/hw/bluetooth.default.so and newest/system/lib/hw/bluetooth.default.so differ
Binary files old/system/lib/libEGL.so and newest/system/lib/libEGL.so differ
Binary files old/system/lib/libEnsembleEngine.so and newest/system/lib/libEnsembleEngine.so differ
Binary files old/system/lib/libLLVM.so and newest/system/lib/libLLVM.so differ
Binary files old/system/lib/libandroid_runtime.so and newest/system/lib/libandroid_runtime.so differ
Binary files old/system/lib/libc.so and newest/system/lib/libc.so differ
Binary files old/system/lib/libcameraservice.so and newest/system/lib/libcameraservice.so differ
Binary files old/system/lib/libeuclid.so and newest/system/lib/libeuclid.so differ
Binary files old/system/lib/libeuclidogre.so and newest/system/lib/libeuclidogre.so differ
Binary files old/system/lib/libharfbuzz_ng.so and newest/system/lib/libharfbuzz_ng.so differ
Binary files old/system/lib/libicui18n.so and newest/system/lib/libicui18n.so differ
Binary files old/system/lib/libicuuc.so and newest/system/lib/libicuuc.so differ
Binary files old/system/lib/libkinesis_service.so and newest/system/lib/libkinesis_service.so differ
Binary files old/system/lib/libnfc-nci.so and newest/system/lib/libnfc-nci.so differ
Binary files old/system/lib/libodl.so and newest/system/lib/libodl.so differ
Binary files old/system/lib/libsqlite.so and newest/system/lib/libsqlite.so differ
Binary files old/system/lib/libstagefright.so and newest/system/lib/libstagefright.so differ
Only in newest/system/lib: libsupol.so
Binary files old/system/lib/libwebviewchromium.so and newest/system/lib/libwebviewchromium.so differ
Binary files old/system/vendor/lib/libsc-a3xx.so and newest/system/vendor/lib/libsc-a3xx.so differ
And I can confirm, they really differ, I can see the differences byte by byte - meaning that at some point they have been tampered with. Creation and modification times did not change, though.
I have three choices now: An OTA update happened while I did the rooting. Or I really now have system libraries that "someone" (me) installed on my mobile. Honestly, I don't dare restoring the old files, unaware of what might happen. The usual thing I'd do in Linux: copy the old files back, mv -f oldfile newfile. However, there's never a fear of being locked out on a desktop. Or, last chance: I am stupid and lib files just don't look the same when you look at them as an ordinary user at different points in time...
Any advice? Should I overwrite the new versions with the originals? Or is it just "normal" on Android?
Best wishes, Frank
Click to expand...
Click to collapse
Nothong to worry about man its completely ok
Sent from my SM-G800H using XDA-Developers mobile app