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
Related
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.
I'm just curious about how the whole FOTA process works on the skyrocket, so I started digging around in logs, source code, and the wssyncmldm binary.
Here's what I've found so far:
The FOTA update is downloaded by Device Management (aka: wssyncmldm) to: /data/data/com.wssyncmldm/2400258.cfg along with some other file:2355.cfg (not sure what that is yet.)
2400258.cfg is a binary munge of all of the delta files and contains a 64 byte header with a signature, a copy of the update agent (ua), and the byte offset of each delta.zImage, delta.modem, delta.lte, delta.platform in the file. the update file can contain several other image delta, like fota_delta_dp1, and fota_delta_dp2.
The delta files are binary patch files, which explains why the update fails if your running a custom rom, kernel, mode, etc -- the patch can't be applied successfully if the current rom isn't the exact stock version that the update agent is expecting.
Next, wssyncmldm then splits out the delta.xxx files and places them in either /data/fota or /sdcard/fota (I'm not exactly sure which, but pretty sure it's /data/fota.) It appears that the delta.xxx files are created when the user clicks ok to initiate the update and reboot.
Next, when the user clicks 'ok' to apply the update, wssyncmldm issues the command: reboot arm11_fota which reboots the system into update mode, then /fota.rc runs to set things up and then executes /sbin/ua_loader which does some checking, copies the working delta files from /data/fota to /cache/fota and then executes the downloaded update agent at /cache/fota/ua.
Then ua then takes the delta files from /cache/fota and performs the update as follows:
The update agent runs through the delta files (zImage, modem, lte, and platform) twice, the first time in op_mode[2] which tests the update, but doesn't actually flash it. If all 4 deltas are successful in test mode, then it runs through a second time in op_mode[0] which actually flashes the update(s).
After an update the update delta and log files remain in /cache/fota.
I'm sure there is more to this process, still doing some tinkering-- but if anyone can offer additional insight that would be great.
I see those files sitting in my cache/fota folder.
Sent from my SAMSUNG-SGH-I727 using xda premium
Thanks for the information, it helped me fill out some missing pieces during my research. The procedure to trigger update by having only the OTA .bin file is described here: http://forum.xda-developers.com/showthread.php?t=1882209
thanks fo this
Welcome. Today I am going to teach you how to modify your android boot logo!
Modify at your own risk! I strongly recommend that you do not try this. But if your going to attempt this, make a BACKUP! I will explain the backup process down the page!
This method has been tested on the Galaxy S6. I RECOMMEND you do NOT attempt this method on any other smartphone other than the S6!
I own a Samsung Galaxy S6 [SDK21 ARM64] and my carrier is Straighttalk. This method might possibly work with the newer Android smartphones. In other words, attempting to do my method will probably not work with androids running 4.4.2 or lower. I will first explain why.
According to what I researched, there is a file in the root directory of the Android system that contains a file called "initlogo.rle". That is your boot logo. Older Android phones had this. The .rle is a bitmap extension and cannot be edited with Android. Actually, let me rephrase that, the .rle COULD MAYBE possibly be edited if you were to download the right tools off of the Play Store but computers can identify .rle as a bitmap very easily and can be opened. Windows computers can open .rle according to what I researched.
The initlogo.rle is also part of the boot.img. The boot.img contains the kernel and the boot files (like init.rc), that are necessary for the phone to boot up. Modifying your boot.img requires a computer. You can't just replace the initlogo.rle with another one. To make changes to a boot.img, you need to unpack the ramdisk, replace or modify the files, repack, and THEN flash the modified boot.img to make the changes.
Newer Android smartphones don't have initlogo.rle. Or at least MINE doesn't. Instead, I had to search for my boot logo which took my quite a while. After searching deep into the android system and messing around with the files, I came accross PARAM.
If you were to go in the /dev/block/platform directory, you would come accross a file called PARAM. Mine was in the directory /dev/block/platform/15577000.ufs/by-name. Inside that directory is basically the whole system. You will find files like BOOT, EFS, OTA and all that. You will also notice that all those files look empty. They all show 0.00B. I don't know exactly why that is, but they aren't really empty files.
My official boot logo was in the file "PARAM". What I did was copied it to my internal directory and attempted to extract it. After trying different extensions, I founded out that .tar is the correct extension. So to extract it, I renamed "PARAM", to "PARAM.tar". After doing that, you will be able to actually extracted it and be left with files with .jpg. Basically pictures inside it. I used root browser. :good:
Inside, you should find "logo.jpg". And whatta ya know! It's your boot logo!
I used PicArt to create a custom boot logo. It is a really great app! You can get it off the Play Store. Then I renamed it to logo.jpg and replaced the original logo.jpg with my newer one. Make sure it is named "logo.jpg" or there will be errors!
Now the last step is to archive the files through .tar format. I used root browser to do that. To correctly archive the files, multi-select the .jpg files. In other words, DON'T SELECT THE "PARAM" FOLDER!!!
When archiving the files, use LZMA compression option along with tar.(Look for that with root browser). This will not compress the files as much which will reduce the risk of errors.
Once it's archived, rename the new archive file to just "PARAM".
LAST STEP! Before overwriting your PARAM, copy your modified PARAM into the /system folder and set the correct attributes (PERMISSIONS) to -rwxrwxrwx. Now you are ready. Copy "PARAM" to the same director where you originally got your unmodified PARAM file. It will ask you if you want to overwrite. Say yes.
I was now introduced with a different boot logo. My phone never got bricked during the process. However, with Android, ANYTHING can happen, so I will give you some advice. If you have a custom recovery, you can easily restore PARAM. Make a copy of your original PARAM and put it in your internal directory. If something ever goes wrong, you can use the file manager (like with TeamWin) and replace the currupt PARAM with your backup PARAM. Then set the permissions to -rwxrwxrwx or 0777
I strongly recommend that you do not try this. Yes, I took the risk and was able to safely change my boot logo. However, not all Android devices are the same so be very careful if you are attempting to do this one an Android device OTHER than the Galaxy S6.
Leave comments if you have any questions!
I was looking for a similar topic but I did not find one. Refers to problems with running applications added to "system.img".
I bought UMIDIG S for my father-in-law. It is based on a mediatec chipset. Unfortunately, soft is tragic, and there is no full translation, so I decided to bury it a bit in "system.img".
I can easily install the file in Linux and make changes in it. I can delete applications, I can make changes in configuration files and "buikd.prop".
Unfortunately, all APK files were uploaded to "system.img" even though I set permissions 755 for directories, and 644 for directories. Although the files are root: root, after uploading such "system.img" none of these applications works for the phone. The system sees them and tries to load. Unfortunately, applications hang because of errors. The system informs that the application hangs, and does not load its window. The icons of these applications and the names do not appear either (applications have green robocik as icon, and domain name, e.g. com.android.clock ....)
I am asking for advice. How to add APK files to the unzipped "system.img" so that after packing and uploading to the phone there were no errors ???
Do you have found how add app in system.img?
It's all around, but you can replace apps with others. In the linux system, unpack the img, and mount them. Then you can freely rename files as well as move files within the .img mount point
I chose the applications or other files I did not need, and moved them to the directories (which I named my applications). If the application needed libraries, you also had to get files in a similar way, and place them in arm or arm64 directories.
Then prepared files "stuffed" with data, using the command DD. That is, dd if = (source file) of = (the recipient file at the system.img mount point).
Thanks for reply, so this only on Linux? For Windows there is something?
Markosv76 said:
Thanks for reply, so this only on Linux? For Windows there is something?
Click to expand...
Click to collapse
I do not know, I do not use Windows. Certainly you can in a similar way from BSD systems, probably from Android and MacOS. I read something that Microsoft can somehow support linux shell, but I do not know the details. You can always use some distribution that works with a pendrive.
Thanks, I will try again
Markosv76 said:
Thanks, I will try again
Click to expand...
Click to collapse
You can use Virtual Box to run a Linux distro inside Windows or you can try using Cygwin.
Sent from my LGL84VL using Tapatalk
jaroslawstrauchmann said:
I was looking for a similar topic but I did not find one. Refers to problems with running applications added to "system.img".
I bought UMIDIG S for my father-in-law. It is based on a mediatec chipset. Unfortunately, soft is tragic, and there is no full translation, so I decided to bury it a bit in "system.img".
I can easily install the file in Linux and make changes in it. I can delete applications, I can make changes in configuration files and "buikd.prop".
Unfortunately, all APK files were uploaded to "system.img" even though I set permissions 755 for directories, and 644 for directories. Although the files are root: root, after uploading such "system.img" none of these applications works for the phone. The system sees them and tries to load. Unfortunately, applications hang because of errors. The system informs that the application hangs, and does not load its window. The icons of these applications and the names do not appear either (applications have green robocik as icon, and domain name, e.g. com.android.clock ....)
I am asking for advice. How to add APK files to the unzipped "system.img" so that after packing and uploading to the phone there were no errors ???
Click to expand...
Click to collapse
did you find a solution to this? please reply if yes, I am having the same problem
Greets. On several different phones I have had no trouble copying my blocked numbers list from one phone to another, but it hasn't worked on my U11. The one time I tried it, it blew up Android and I had to do a TWRP restore from a fresh backup (yes I always backup before I start messing with system files).
It has worked without a hitch on multiple Moto, Samsung and LG phones by copying the "blockednumbers.db" file, located in:
/data/user_de/0/com.android.providers.blockednumber/databases/
... and then pasting blockednumbers.db to the same folder on another phone. I use Root Explorer with root access, which has always worked like a champ for anything involving root.
The above folder contains the following SQL file structure:
- android_metadata
- blocked
- sqlite_sequence
The "blocked" file contains a complete (readable) list of all blocked numbers, and sqlite_sequence maintains a count. I just copy and paste the entire folder "blockednumbers.db" into its parent folder.
I have a database of more than 200 blocked numbers and really hate it that I can't get it copied to my U11. I'm on Android Nougat, 1.28.617.30. Any help? TIA!