Executables and Shared Libraries
So i’ve known about Windows DLL’s and shared objects in Linux/Unix but hadn’t realized that the concept exists in MacOS also. I haven’t owned any Apple products, so clearly i have poor insight into the OS
Terminology:
- Windows -> DLL’s (Dynamic Link Libraries)
- Linux -> .so files (Shared Objects)
- MacOS -> Dylib’s (Dynamic libraries) and Frameworks
They seem to serve the same purpose in general, but I suppose each has their own particular intricacies tied to the way the OS uses executables.
On DLL Hijacking:
Unexpected loading DLL’s from expected/ unexpected locations
- Using web locations
- Hijacking DLL loading order
- Hijacking paths
If you control the binary, you can control the DLL’s.
You can still control the DLL’s, even if you don’t control the binary, if the binary does not enforce / check the paths or the signatures of the DLL’s.
Current solutions:
- DLL signing
- Binary/Executable Signing
References:
https://superuser.com/questions/228309/macos-dll-equivalent
https://stackoverflow.com/questions/1212477/creating-a-dll-on-a-mac-dylib-or-framework
https://attack.mitre.org/techniques/T1038/
https://attack.mitre.org/techniques/T1157/
Windows Common Processes
Conhost.exe – Console Window Host process (Remember: Not ‘connection’)
Taskhost.exe – Task Host (Host for DLL based services)
svchost.exe – Services Host Process
ceip.exe – Customer Experience Improvement Program
RuntimeBroker.exe – Runtime Service Broker
Werfault.exe – Windows Error Reporting
wmic.exe – Windows Management Instrumentation Command-line-utility
Sources:
https://www.howtogeek.com/howto/4996/what-is-conhost.exe-and-why-is-it-running/
https://www.howtogeek.com/howto/windows-vista/what-is-svchostexe-and-why-is-it-running/
https://www.howtogeek.com/268240/what-is-runtime-broker-and-why-is-it-running-on-my-pc/
https://www.groovypost.com/howto/groovytip/what-is-taskhost-exe-and-should-it-be-running/
https://support.microsoft.com/en-gb/help/290216/a-description-of-the-windows-management-instrumentation-wmi-command-li
Windows CMD / Powershell / DOS command -fu
Operating System related Information
- View OS / System information:
CMD:
systeminfo wmic qfe
- Is there anything interesting in the Environment Variables:
CMD:
set
Powershell:
Get-ChildItem Env: | ft Key,Value
- Are there any connected drives (Network or Local):
CMD:
net use wmic logicaldisk get caption,description,providername
Powershell:
Lots of other DOS/Powershell wmic.exe related commands:
Get Manufacturer
wmic baseboard get product,manufacturer
Get Bios and Version
wmic bios get name
Get software, services, process information
wmic product list brief
wmic service list brief
wmic process list brief
wmic startup list brief
Put services in a HTML document
wmic service get /format:hform > c:\folder\services.html
Uninstall:
wmic product get name
wmic product where name=”Product name exactly as appears in above command” call uninstall
Kill a process:
wmic process where name=”iexplore.exe” call terminate
Change a process’s priority:
wmic process where name=”notepad.exe” call setpriority 64
Run commands on a remote node:
wmic /node:steve-pc service list brief
References:
https://www.sploitspren.com/2018-01-26-Windows-Privilege-Escalation-Guide/
Android: Installing an Android App (APK) as a System App on the Android Emulator (v26) [Android 5.1+]
I wanted to install a couple of APKs on the /system partition so that if I clear out the apps installed in the user partition, or I format/delete the user partition, i don’t lose my stuff.
NB: Installing to the /system partition also seems to have some extra benefits in terms of permissions, but I have not read into the details of what exactly happens. Also uninstalling via the GUI is not available (as far as i can see) once the app is installed on the /system partition
So the basic idea is that we want to get the given APK onto the /system partition and according to most tutorials and explanations i’ve found online it seems to be as easy as just copying the file onto the system partition and rebooting the device. But there are a few caveats that one needs to know. I’ll go through these below while also going through the steps that I used to eventually get my APK’s installed to the /system partition.
Common Steps across all methods:
You need to have the /system partition writable, this is done by first starting up the emulator with the -writable-system directive
emulator -avd -writable-system
The next step is to remount the AVD disks with the adb remount directive (I haven’t looked into what exactly happens here, but it seems to be needed, and works)
adb -e remount
After this, I noticed that there are 2 main methods, either copying the APK directly to the system partition, or installing the APK first to the user partition then “moving” it to the system partition.
The first method is useful for small APK files (i don’t have a specific definition of precisely what “small” means, but read on and you’ll get the idea); while the 2nd method is more appropriate for larger APKs. In general I noticed that larger APK files have other files in them and in the installation process the original APK gets split into a “base.apk” file, library dependencies (into a directory) and a couple of other “split files” derived from the APK. The best way to discover if this will happen to your APK is by using Method 2 (i.e. installing to the user partition, then “moving” the files to the system partition). The libraries and split files have an effect on the way things are installed on the system partition.
Method 1: Directly copying into the /system partition
The basic idea here is to just copy the given APK file either from your computer disk directly to the /system partition, or to copy it first to the SD Card (if available), or from some other writable location on your Android device (e.g. /usr/data/temp).
My suggestion is to create a folder in the /system/app/ directory with the package name of the APK. (it seems it is not entirely necessary, but for the sake of keeping the /system/app directory as clean as possible, i suggest this.)
This is done by going into the /system/app/ directory and using the mkdir command:
adb -e shell cd /system/app mkdir <PACKAGE_NAME>
The next step is to copy the APK from it’s original location into the /system/app directory. This can be done as follows:
If the APK is on your computer disk in some location:
adb -e push <APK_FILE_PATH> /system/app/<PACKAGE_NAME_DIR>/<APK_FILE_NAME>
E.g:
adb -e push C:\Users\user1\Desktop\myApp.apk /system/app/com.myPackage.package_name/myApp.apk
Since the directory is created as root it will likely have permissions set to 777 i.e. rwxrwxrwx . For security reasons it’s better to change these to something lower. I’m not exactly sure because some resources suggest 644 (i.e. r-xr–r–), while I think 755 is what is needed. All the same, change them:
chmod 755 /system/app/<PACKAGE_NAME_DIR>
If it copied successfully, you can reboot the device either with the Emulator Power button on the GUI, or using the adb -e reboot command
Method 2: Installing the APK to the User partition and then “moving” it to the System partition
Step 1: Similar to Method 1, for the sake of cleanliness, I suggest creating a folder in the /system/app partition. Use the mkdir command as described at the beginning of the instructions for Method 1. (Obviously, before doing this, you should ensure that you started the emulator with the -writable-system directive, and used adb -e remount so that you can eventually have the /system partition as writable)
Step 2: Install the APK normally (from wherever it is, e.g on your computer, the SD Card etc) into the User partition of your device, using adb.
adb -e install <APK_FILE_PATH>
E.g: adb -e install C:\Users\user1\Desktop\myApp.apk
Step 3: Using adb get into the application installation directory and view how the APK was installed.
adb -e shell cd /data/data/<APK_PACKAGE_NAME> ls -al
E.g. adb -e /data/data/com.myPackage.package_name
In this directory you will probably see a couple of things including a /cache directory, a files directory, “split files” and a /lib directory (sym link) either to the /data/app-lib/ directory /vendor/lib/ or /system/lib/. You might also see /logs, /requests, /no_backup and /shared_prefs directories.
In my case i had a “base.apk” file, a /lib directory and lots of “split files” labelled split-lib-dependencies_apk.apk and split-lib-slice_0_apk.apk (numbered 0 to 9)
Step 4: Copy all the files from the installation directory in the User partition to the installation directory in the /system partition
In this step i opted to copy (using cp), rather than move (using mv) because mv was causing some unknown errors and i’ve read in some places something about problems with mv when trying to move directories across different partitions.
Since i was using cp i also elected to delete the directories and files in the user partition just after the copy was complete so as to mimic what i think should happen in a “move” operation.
Assuming you’re still in the installation directory in the User partition (from the previous step)
cp *.* /system/app/<APK_PACKAGE_NAME>/
E.g.:
cp *.* /system/app/com.myPackage.package_name/
If you want, you can check both the directories just to confirm that they look the same in terms of the copy being complete. In general if there were no errors, then the copy should have happened successfully.
cd /data/data/<APK_PACKAGE_NAME>/ ls -al cd /system/app/<APK_PACKAGE_NAME>/
Since the directory in the system partition is created as root it will likely have permissions set to 777 i.e. rwxrwxrwx . For security reasons it’s better to change these to something lower. I’m not exactly sure to what exactly, because some resources suggest 644 (i.e. rw-r--r--), while I think 755 (i.e rwxr-xr-x)is what is needed. All the same, change them:
chmod 755 /system/app/<PACKAGE_NAME_DIR>
Note on Native Libraries:
If you have some native libraries built and deployed with your code (or in the APK that you’re trying to install as a system app), you will need to copy them either from within the APK file, by unzipping it’s contents, going into the /lib directory, into the folder that is named after the CPU architecture that your emulator or device is using (i.e. x86, x86-64, armeabi, etc); or from your compiled code (probably in <PROJECT_DIR>/app/build/intermediates/cmake/debug/obj if it’s a normal shared object library, or <PROJECT_DIR>/app/src/main/assets/ if it is bundled as an ‘asset’) [*not sure if this asset part is actually true or necessary, but the *.so file for sure]
Alternatively if you had a /data/app-lib directory when you installed the APK in the user partition, you might find the library there.
The location you will probably have to copy the library to is either /system/lib/ or /vendor/lib/ (in some recent versions it is /system/vendor/lib ). You’ll notice in these directories the shared object library files (*.so) just sit there directly (no directory named according to the a package name)
You can copy from your device to the emulator using the adb -e push command
E.g:
adb -e push C:\Users\user1\Desktop\Unzipped_APK_Dir\lib\sharedlib.so /system/lib/sharedlib.so
or
adb -e shell cp /data/app-lib/sharedlib.so /system/lib/sharedlib.so
or from wherever else, probably with cp
Once you are happy that all the copy events completed successfully, you can go to the APK installation in the user directory , list the contents of the APK installation directory in order to see the package that you want to remove and use that name when deleting the directory
cd /data/data/ ls -al rm -r <APK_PACKAGE_NAME>
E.g.:
rm -r com.myPackage.package_name
Now you can reboot your device either with the adb -e reboot command, or through the Power Button, on the Emulator GUI.
On reboot your app should be installed. Try opening it. If it opens successfully (which was my case), then we’re all good. You can also try holding the App’s icon and if it is installed as a system app then you shouldn’t be able (as a normal user) to see the Remove/Uninstall dialog that usually appears at the top for other apps.
Extra Note: From the Android Platform Code documentation on Github [3]:
Parser for package files (APKs) on disk. This supports apps packaged either as a single “monolithic” APK, or apps packaged as a “cluster” of multiple APKs in a single directory.
Apps packaged as multiple APKs always consist of a single “base” APK (with a {@code null} split name) and zero or more “split” APKs (with unique split names). Any subset of those split APKs are a valid install, as long as the following constraints are met:
- All APKs must have the exact same package name, version code, and signing certificates.
- All APKs must have unique split names.
- All installations must contain a single base APK.
References:
[1]. https://android.stackexchange.com/questions/27/how-do-i-properly-install-a-system-app-given-its-apk
[2]. https://www.isunshare.com/android/2-ways-to-convert-user-app-to-system-app.html
[4]. https://gist.github.com/chrislacy/3e09dda8e88a064d32fc634254fb4c9f
[5]. http://projectmaxs.org/documentation/systemapp.html
[6]. http://www.androidauthority.com/install-user-app-as-system-app-how-to-93522/
[8]. https://developer.android.com/guide/topics/data/install-location.html
[9]. https://justus.berlin/2015/02/make-persistent-changes-to-system-in-android-emulator/
[11]. http://stackoverflow.com/questions/6066030/read-only-file-system-on-android
[12]. http://stackoverflow.com/questions/15417105/forcing-the-android-emulator-to-store-changes-to-system
Rooting the Android Emulator – on Android Studio 2.3 (Android 4.4+)
Having struggled to easily find instructions on how to run apps as root on the Android Emulator, I’ve decided to document what worked for me. I’ve tested this on the emulator bundled in Android Studio 2.3 with an emulator running Android 4.4 (Kitkat)and 7.1.1 (Nougat).
NB: Basically, through ADB (the Android debug bridge) you can get root access to the filesystem (only). This means you can access privileged directories, change file/directory permissions, put apps and binaries in certain (many?) locations (not in the system partition, unless you make it writable), and run them via the command line interface. However, this does not mean that you will be able to run apps in the emulator directly as root.
Getting access to the filesystem as root is as easy as running:
adb root
or getting into the emulator and using su , i.e.:
adb -e shell
su root
Notice the # telling you that you are root. (The -e just means to direct the adb connection to the emulator)
Now this is NOT exactly what I wanted, I wanted more!!
Rooting the Emulator:
Tl;dr: The basic idea is to get the correct su (superuser) binary from the SuperSu project by Chainfire (Jorrit Jongma), put it in the right directory, change the permissions. Install the SuperSu app, turn off SELinux policies and set up a daemon. I won’t claim I understand the whole process (particularly the daemon part), but i’ll document below what worked for me.
I’ll assume we’re using a Windows machine as the host. (Running these on Ubuntu, or some other Linux /Unix flavour should not be too different).
Step 0: Installing the SuperSu app
Ideally this step could come first before everything else, or last, after everything else. If you install it now you, and try to run it, very likely it would indicate that the su binary was not installed. If you try to run it after all the steps below, it should open error free and (without the dialog telling you that the binary is not installed).
Install the Supersu app either from Google Play or sideload it through adb. The links are available at the SuperSu downloads section.
Install the Supersu.apk file through sideloading as follows:
adb -e install supersu.apk
Step 1: Start up the emulator with a writable system partition.
emulator.exe -avd [emulator_name] -writable-system
Step 2: Get the SU binary and put it in the right directory
You can download the Superuser binary from the supersu downloads section. Download the latest ZIP files. (As of writing this is Recovery Flashablev2.79). Unzip the archive. Locate the su binary for the correct architecture of the emulator that you are using. In my case i’m running an emulator with Android x86 (on a Windows device), so i look under the x86 directory of the SuperSu ZIP archive. NB: If you are using Android 5.1 and above (or if you are getting some errors about Position Independent Executables [PIE]), what you need is the su.pie binary, rather than the plain su binary.
We now need to put the binary into the correct location as follows:
Make sure you are running adb as root using. Not sure why you need to remount, but for some reason it enables writing to the system partition, (after having used the -writable-system directive).
adb root adb remount adb -e push C:\SuperSU-v2.79\x86\su.pie /system/xbin/su
Remember that if you are using an Android emulator with a version lower than Android 5.1 you likely will have to use the plain su binary (not the su.pie)
adb -e push C:\SuperSU-v2.79\x86\su /system/xbin/su
Not sure why, but some resources suggest that you need to push the binary to /system/bin/ for some Android versions. For good measure you can just do it, just incase.
Now we need to get into the emulator device through adb and change the permissions of the su binary.
adb -e shell su root cd /system/xbin/su chmod 06755 su
For good measure, if you also put the binary in /system/bin/su you can also traverse into that directory and put the permissions of 06755 on the su binary there in. (I can’t remember exactly whether i used 06755, or just 755 as the permissions, but I seem to vaguely remember the former as what I used). Also i noticed that originally the permissions on the su binary in the emulator had rwsr_x_x permissions if i remember correct.
Step 3: Set the install directive on the su binary and set a daemon
I’m not entirely sure what is going on in this step, but it looks like the su binary may have a --install directive to install some more things (maybe??). I just followed [1] (from Android StackExchange).
su --install
Now we set up the daemon, (also taken from the same StackExchange post)
su --daemon&
Notice the ampersand (&) at the end of the line with no space before. This indicates that the daemon (service) should run in the background.
Step 4: Set SELinux to Permissive (i.e. turn off SELinux)
This step essentially turns off SELinux. Logically this step sounds like it should have come earlier, but for some reason it came at the end and still worked.
setenforce 0
In my situation, at this point the emulator seems to have hung/crashed. I just terminated it.
Now you can restart the emulator via the command line, or via Android Studio. It should start up successfully. If you had installed the SuperSu app then you can just run the app and it might prompt you that there is a new version of the binary. Install it via the “Normal” option (if prompted).
At this point everything should be working well, and you can test some other app that requires root permissions to verify that the su binary is installed correctly and that the SuperSu (Gatekeeper) app fires correctly to “Grant” or “Deny” access to the requesting app.
References:
[2]. http://www.supersu.com/download
[4]. https://fedoraproject.org/wiki/SELinux/setenforce
[5]. https://www.cyberciti.biz/faq/howto-turn-off-selinux/
Windows Command line – CMD – fu : Notes
So i haven’t used the Windows Command (DOS) Prompt for many things until I realized that Android / Android Studio / Android SDK and the emulator (with the HAXM driver) work pretty well on Windows.
Long story short, there seems to be a lot of powerful things in this “predecessor” to Powershell.
Viewing and Saving Command History:
One of the things i wanted to do was to view my command line history. This can be easily done by pressing F7 and lo and behold a smaller dialog within the cmd window will appear with the command history.
Now, the F7 trick doesn’t really allow you to save the history, nor to copy-paste it, so i needed another solution. The command below provides this solution.
doskey /history > history.txt
Essentially, this copies (redirects) the cmd history of only the current session into a text file named history.txt or whatever you’d like to name your text file .
Sources:
[1]. http://www.computerhope.com/tips/tip189.htm
[2]. http://serverfault.com/questions/95404/is-there-a-global-persistent-cmd-history
[3]. http://www.howtogeek.com/119386/5-windows-command-prompt-tricks-you-probably-dont-know/
Android App Developer Guide – My Own Beginner Notes
Various notes (adapted) from the Android SDK Developer Docs (for creating one’s first App):
The at sign (@) is required when you’re referring to any resource object from XML. It is followed by the resource type (id in this case), a slash, then the resource name (edit_message). [Source]
The plus sign (+) before the resource type is needed only when you’re defining a resource ID for the first time. When you compile the app, the SDK tools use the ID name to create a new resource ID in your project’s R.java file that refers to the EditText element. With the resource ID declared once this way, other references to the ID do not need the plus sign. Using the plus sign is necessary only when specifying a new resource ID and not needed for concrete resources such as strings or layouts. See the sidebox for more information about resource objects. [Source]
The default weight for all Views is 0, so if you specify any weight value greater than 0 to only one View, then that view fills whatever space remains after all Views are given the space they require. [Source]
It’s a good practice to define keys for Intent “extras” using your app’s package name as a prefix. This ensures the keys are unique, in case your app interacts with other apps [Source]
The XML layout generated by previous versions of Android Studio might not include the android:id attribute. The call findViewById() will fail if the layout does not have the android:id attribute. If this is the case, open the relevant .xml file in the /res/layout directory (in this case activity_display_message ) and add the attribute android:id="@+id/activity_display_message" to the layout element. [Source]
Android categorizes device screens using two general properties: size and density. [Source]
- There are 4 generalized sizes: small, normal, large, xlarge
- And 4 generalized densities: low (ldpi), medium (mdpi), high (hdpi), extra high (xhdpi)
- Also be aware that the screens orientation (landscape or portrait) is considered a variation of screen size, so many apps should revise the layout to optimize the user experience in each orientation.
Information about the relative number of devices that share a certain characteristic, such as Android version or screen size [Source]
Using the appcompat Toolbar makes it easy to set up an app bar that works on the widest range of devices, and also gives you room to customize your app bar later on as your app develops [Source]
You should always externalize application resources such as images and strings from your code, so that you can maintain them independently. You should also provide alternative resources for specific device configurations, by grouping them in specially-named resource directories [Source]
Installing the Google Play Store App (APK) on the Android Emulator
This has been tested on the Android Emulator that comes default installed with the Android SDK with Android Studio 2.2.3.
The Android OS version used was the latest Android 7.1.1 (Nougat) and the Google Play APK version was 10.0.84 from OpenGapps (although I think any latest versions of the APK should work).
The basic idea from this post was adapted from a StackOverflow post [1] that had good ideas, but I had to tweak them to get it to work for my case.
TL;DR: The basic idea is that you need to get the APK files put them in the right location of the system partition (after getting it to be writable). Then giving the APK’s the right permisions (I gave them all 777, i don’t know why, i just wanted it to work, but perhaps not so good for security. May be 755 will also work.). Then reboot, once rebooted shutdown the instance, delete the Emulator instance from the Android Virtual Device manager, and clone another image out of the one that was written to. (If you didn’t get that … all the details are below…)
Intro:
To get just the Google Play APK and it’s related services select the Pico version from the OpenGapps website. If you want other Google Apps also e.g. Gmail, Google Now, Google Music, Calendar, Youtube, etc you’ll have to select one of the other OpenGapps packages that has the apps you want.
Getting the APKs out of the OpenGapps ZIP (and TAR.LZ) archive
For this part you’ll need something that can open ZIP files and decompress the LZIP format. On Windows i used 7Zip and Lzip
I used the Windows batch script below found at the StackOverflow question cited[1] and created a batch file called unzip_gapps.bat. Make sure to change the line lzip -d GAPPS\Core\gmscore-x86_64.tar.lz to the file for which ever version of architecture you’re using, in my case it was x86 instead of x86_64
Put all the files (open_gapps-*.zip, 7z.exe, lzip.exe, unzip_gapps.bat) into a single directory and run the batch file.
@echo off echo. echo ################################# echo Extracting Gapps... echo ################################# 7z x -y open_gapps-*.zip -oGAPPS echo Extracting Lzips... lzip -d GAPPS\Core\gmscore-x86_64.tar.lz lzip -d GAPPS\Core\gsfcore-all.tar.lz lzip -d GAPPS\Core\gsflogin-all.tar.lz lzip -d GAPPS\Core\vending-all.tar.lz move GAPPS\Core\*.tar echo. echo ################################# echo Extracting tars... echo ################################# 7z e -y -r *.tar *.apk echo. echo ################################# echo Cleaning up... echo ################################# rmdir /S /Q GAPPS del *.tar echo. echo ################################# echo All done! Press any key to close. echo ################################# pause>nul
The APK files should now be extracted and “automagically” appear in the directory.
Putting the APK’s in the right place on the Android device
NB: This needs some form of getting the /system partition (directory) to be writable, or to have root access in order to make the /System partition writable. I’ve seen some form of attempt at rooting the emulator here, in order to make the /system partition writable, but this didn’t do the trick for me.
Assuming that you have Android Studio, the SDK and an Emulator instance created with Android 7.1.1 (API 25), I had to start the emulator from the CLI with the directive writable-system
Windows:
emulator.exe -avd <Emulator_Instance_Name> -writable-system
Ubuntu:
./emulator -avd <Emulator_Instance_Name> -writable-system
Now the APK’s need to be put into the /system/priv-app/ directory, inside directories, each with the specific name of the APK it contains. You’ll probably need root privileges to write to the system/priv-app directory. I used adb root to grant me root access. For some reason I also needed to to adb remount to make sure that the /system partition becomes writable (Not sure why, if i already asked the emulator to have a writable /system partition, but this had to be done). For subsequent accesses you can also get into the shell using adb shell and then from there switch user to root with su root.
NB: You might already have the directories PrebuiltGmsCore, GoogleServicesFramework, GoogleLoginService. (Unlikely you’ll have Phonesky). But create whichever ones you need as seen below.
adb root adb remount adb shell cd /system/priv-app mkdir PrebuiltGmsCore mkdir GoogleServicesFramework mkdir GoogleLoginService mkdir Phonesky
Exit the ADB shell. Now we need to Push the right APK files to the right directories:
adb push <APK_file_path> /system/priv-app/<Destination_dir>/
e.g:
On Windows:
adb push C:\OpenGapps\PrebuiltGmsCore.apk /system/priv-app/PrebuiltGmsCore/ adb push C:\OpenGapps\GoogleServicesFramework.apk /system/priv-app/GoogleServicesFramework/ adb push C:\OpenGapps\GoogleLoginService.apk /system/priv-app/GoogleLoginService/ adb push C:\OpenGapps\Phonesky.apk /system/priv-app/Phonesky/
On Ubuntu:
./adb push ~/User1/OpenGapps/PrebuiltGmsCore.apk /system/priv-app/PrebuiltGmsCore/ ./adb push ~/User1/OpenGapps/GoogleServicesFramework.apk /system/priv-app/GoogleServicesFramework/ ./adb push ~/User1/OpenGapps/GoogleLoginService.apk /system/priv-app/GoogleLoginService/ ./adb push ~/User1/OpenGapps/Phonesky.apk /system/priv-app/Phonesky/
Changing the Permissions of the APKs
Now you’ll need root access again to change the APK permissions. As mentioned earlier, i gave the permissions 777 to the files, but i’m not sure whether such high permissions are needed for all users, i think 755 might be more appropriate, but i haven’t tested this.
adb root adb shell chmod 777 /system/priv-app/PrebuiltGmsCore/PrebuiltGmsCore.apk chmod 777 /system/priv-app/GoogleServicesFramework/GoogleServicesFramework.apk chmod 777 /system/priv-app/GoogleLoginService/GoogleLoginService.apk chmod 777 /system/priv-app/Phonesky/Phonesky.apk
At this point the APK’s might start installing themselves and you might get an error saying the Play Services have stopped or com.google.Gmscore has stopped, or something close to that. Ignore it.
[Before April 2017, the rest of this guide was relevant, from April 2017, you don’t need to do the rest. Restarting the emulator should work.]
Restarting and Creating another Image
(For Emulator versions, below v25, that is: Before April 2017)
Restart the Emulator and even now you’ll probably still be getting the Play Services have stopped or com.google.Gmscore has stopped or something close to that.
Now shutdown the emulator normally, using the power button long-press.
After it has shutdown, go to the Android Virtual Device (AVD) manager through Android Studio (Tools > Android > AVD Manager). Delete the Virtual Device Instance and create a new one (this sounds counter intuitive, but if you check the time-stamps of the system image where these devices are cloned from [ {android_version_home_dir}/sdk/system-images/{android-version-number}/system.img> ] you’ll notice that the system was written to pretty recently). This is because we had the writable-system directive when we were making the changes, thus the Play Store APK got installed to /system partition “permanently”, so any new AVD created for this particular version of Android, it will have the Google Play Store APK installed properly.
Create a new AVD from the modified system-image android version and you’ll see the Play Store App installed, ready and waiting on the home screen.
Sources:
Android Debug Bridge (adb): Useful commands – Notes
- Accessing an Android Device or Emulator […and getting Shell access]
adb devices -l
adb -e
adb -e shell
TThe -e directive initiates a connection to the Emulator, if there is only one emulator instance, otherwise it will throw an error
adb -d
adb -d shell
The -d directive initiates a connection to a Physical Android Device connected, if there is only one device connected, otherwise it will throw an error.
adb -s <device_serial_identifier>
adb -s <device_serial_identifier> shell
If there are multiple emulators, or multiple devices, or multiple of both connected, then the -s directive needs to be used to specify the specific “device/emulator” to connect to.
- Installing and Uninstalling APKs
adb -e install <APK_file_path>
adb -e uninstall <package_name>
- Errors when installing APKs:
- INSTALL_FAILED_NO_MATCHING_ABIS
- When the APK has native librariues that were built for a different architecture than what you are trying to run it on e.g. x86 and trying to run it on an ARM device, or built for ARM64 and trying to run it on ARM or x64; or ARM and trying to run it on x86 [1]
- INSTALL_FAILED_NO_MATCHING_ABIS
- Getting ADB Root Permissions i.e. Root on the device
adb root
- Listing packages (and file install locations)
adb -e shell pm list packages -f
adb -d shell pm list packages -f
- Getting 3rd party packages only:
adb shell pm list packages -f -3
Sources:
[1] http://stackoverflow.com/questions/24572052/install-failed-no-matching-abis-when-install-apk
Android Process Memory Dumps with Memdump – Android 4.4+ (on Ubuntu 16.04)
Memdump: [a little more straightforward than Memfetch … in my opinion]
Basically the idea is to get the code and cross-compile it using the Android NDK (Native Develpment Toolkit) toolset on Ubuntu, then getting the binary and transferring it onto your device and running it with the right permissions.
Update [2017-01-16]: I’m not sure whether this will work for Android on both x86 and ARM architectures. I tested it on an ARM architecture (physical device), and it worked. I’m yet to test it on an x86 architecture. Will update after testing. (My feeling is that it should). I forgot that there are multiple folders in the /libs directory that are created. One for each of the architectures. Pick the right executable from the right folder for your architecture, and it should work.
Update [2017-01-18]: I tested this entire thing on an Android 7.1.1 (Nougat) emulator, and eventually got it working. It seems that from Android 5.0 you will probably get an error like “error: only position independent executables (PIE) are supported“. From what i’ve read here this is is due to a security feature implemented from Android 5.0 onwards. The Android.mk file has to be modified a bit (i’ve added the modifications needed) to enable PIE for any executables from Android 5.0 onwards. (Truth is it seems the PIE feature is available from 4.1, but it is disabled, and from 5.0 it is enabled by default)
Getting the code and setting it up:
Find the code here – http://security.stackexchange.com/questions/62300/memory-dumping-android (hoping that the link is still alive, it’s among the answers by Tal Aloni)
Create a directory in an appropriate location of your choice. I created one called memdump on my Desktop. Then create a directory with the name jni in that directory (this is important for using ndk-build later).
cd ~/Desktop mkdir memdump cd memdump mkdir jni cd jni
Create a file in the jni directory and copy-paste the code from the link provided above into the file. Name the file memdump.c. I’ve put the code here below also, just for completeness:
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <sys/ptrace.h>
#include <sys/socket.h>
#include <arpa/inet.h>
void dump_memory_region(FILE* pMemFile, unsigned long start_address, long length, int serverSocket)
{
unsigned long address;
int pageLength = 4096;
unsigned char page[pageLength];
fseeko(pMemFile, start_address, SEEK_SET);
for (address=start_address; address < start_address + length; address += pageLength)
{
fread(page, 1, pageLength, pMemFile);
if (serverSocket == -1)
{
// write to stdout
fwrite(page, 1, pageLength, stdout);
}
else
{
send(serverSocket, &page, pageLength, 0);
}
}
}
int main(int argc, char **argv) {
if (argc == 2 || argc == 4)
{
int pid = atoi(argv[1]);
long ptraceResult = ptrace(PTRACE_ATTACH, pid, NULL, NULL);
if (ptraceResult < 0)
{
printf("Unable to attach to the pid specified\n");
return;
}
wait(NULL);
char mapsFilename[1024];
sprintf(mapsFilename, "/proc/%s/maps", argv[1]);
FILE* pMapsFile = fopen(mapsFilename, "r");
char memFilename[1024];
sprintf(memFilename, "/proc/%s/mem", argv[1]);
FILE* pMemFile = fopen(memFilename, "r");
int serverSocket = -1;
if (argc == 4)
{
unsigned int port;
int count = sscanf(argv[3], "%d", &port);
if (count == 0)
{
printf("Invalid port specified\n");
return;
}
serverSocket = socket(AF_INET, SOCK_STREAM, 0);
if (serverSocket == -1)
{
printf("Could not create socket\n");
return;
}
struct sockaddr_in serverSocketAddress;
serverSocketAddress.sin_addr.s_addr = inet_addr(argv[2]);
serverSocketAddress.sin_family = AF_INET;
serverSocketAddress.sin_port = htons(port);
if (connect(serverSocket, (struct sockaddr *) &serverSocketAddress, sizeof(serverSocketAddress)) < 0)
{
printf("Could not connect to server\n");
return;
}
}
char line[256];
while (fgets(line, 256, pMapsFile) != NULL)
{
unsigned long start_address;
unsigned long end_address;
sscanf(line, "%08lx-%08lx\n", &start_address, &end_address);
dump_memory_region(pMemFile, start_address, end_address - start_address, serverSocket);
}
fclose(pMapsFile);
fclose(pMemFile);
if (serverSocket != -1)
{
close(serverSocket);
}
ptrace(PTRACE_CONT, pid, NULL, NULL);
ptrace(PTRACE_DETACH, pid, NULL, NULL);
}
else
{
printf("%s <pid>\n", argv[0]);
printf("%s <pid> <ip-address> <port>\n", argv[0]);
exit(0);
}
Now create another file in the same jni directory and name the file Android.mk
The instructions in the Android.mk file should look like the following:
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) # [Update 2017-01-18]: These 4 lines below, including the comments. # Enable PIE manually. Will get reset on $(CLEAR_VARS). This # is what enabling PIE translates to behind the scenes. LOCAL_CFLAGS += -fPIE LOCAL_LDFLAGS += -fPIE -pie LOCAL_MODULE := memdump LOCAL_SRC_FILES := memdump.c include $(BUILD_EXECUTABLE)
Setting up Android Build Environment:
I used Android Studio (version 2.2.3) to get to the Android SDK Manager GUI and install the NDK from there. You can install Android Studio in Ubuntu using umake. Install umake as follows:
sudo apt-get install umake
The install Android Studio:
umake install android
Run Android Studio and find the Android SDK Settings ( > > >). Under the SDK Tools tab click the CMake, LLDB and NDK checkboxes.
Click Apply or OK. A dialog should appear where you accept the license conditions and then the requisite tools should begin installing.
(For our case here, we will use only ndk-build since it was what worked. Ideally, you could use CMake … and actually the latest Android documentation suggests using CMake henceforth since i think they plan to retire / deprecate ndk-build eventually … All the same, i think the Android.mk file I found on StackExchange was written for ndk-build so that’s what we’ll use. Also i’m not yet sure how to use CMake for this task. If i figure it out i’ll write another blog post.) Also you could use Android Studio directly for this entire task of building/compiling the C code to get an Android/ ARM executable, but i don’t know how to configure it correctly yet.
Once you have the NDK installed, navigate to the ~/Desktop/memdump directory and while there execute ndk-build , which you can find under /home/Android/Sdk/ndk-bundle/
cd ~/Desktop/memdump /home/Android/Sdk/ndk-bundle/ndk-build
If you happen to be on a Windows machine, you can get ndk_build.cmd to do the job for you. Navigate to the folder where you have memdump and you can run:
e.g:
C:\Users\user1\Desktop\memdump> C:\Users\user1\AppData\Local\Android\sdk\ndk-bundle\ndk-build.cmd
At this point the code should build and compile creating a /libs directory an an /obj directory. Navigate into the libs directory and you will see directories for various architectures. Under each directory there is an executable for that specific architecture. We’re mainly concerned at this moment with the one under armeabi
Installing the Memdump executable on an Android device:
In order to use the Memdump executable, we need to get it onto an Android device in a place that allows execution, give the executable execute permissions and run it.
NB: We assume that the Android device is rooted properly and that the specific Superuser management app allows root access from the adb shell. (I haven’t tested it on an unrooted device, but i still suspect that the device needs to be rooted first)
Navigate to the directory containing the adb executable. Get into the adb shell and navigate to the /data/local/tmp (since execution of binaries is allowed there). We want to put the memdump executable in a directory in here. Create a directory here called mem_dump_tools (or whatever you’d like to call it). This is where we will put the memdump executable
cd ~/Android/Sdk/platform-tools ./adb devices -l ./adb shell su root cd /data/local/tmp mkdir mem_dump_tools
Now push the memdump executable from the Ubuntu machine into the Android devices:
./adb push ~/Desktop/memdump/libs/armeabi/memdump /data/local/tmp/mem_dump_tools
Navigate into the mem_dump_tools directory on the Android device and give the memdump executable permissions to execute:
./adb shell cd /data/local/mem_dump_tools sudo chmod 755 memdump
(or you can use sudo chmod+x memdump)
Verify that it has got the executable permisions by running ls -al to list the files with their properties.
Executing the memdump tool:
The memdump script has two execution formats. One to dump to a directory and the other to dump over a network network port
memdump <pid> > /Path/to/Directory/to/dump/to memdump <pid> <ipaddress> <port>
NB: Make sure you don’t forget the “>” to direct the output of stdout to a file (or elsewhere)
Hack: (For those interested in Forensics & Reversing). If you get the Position Independent Executables (PIE) error here because you missed the lines LOCAL_CFLAGS += -fPIE and LOCAL_LDFLAGS += -fPIE -pie in the Android.mkfile, there is an interesting hack (credit to Koorosh Ghorbani ) that i found on Stackoverflow. You can open the executable with your favourite Hex Editor and you just have to change the 17th byte from 02 to 03 and the executable should now work without the PIE error.
We want to dump the process memory of a an application E.g. Chrome, Facebook, Whatsapp …etc. into a directory on the SDCard. Let’s use Chrome for now
Let’s first create a directory where the dumps should go.
./adb shell su root cd /storage/extSdcard mkdir MEM_DUMPS
Now let’s get the process id of the process that we want to target
ps | grep chrome
Pick the pid from this. You should get 3 processes (one with sandbox , another with privileged affixed and another just plain com.android.chrome … pick this last one with nothing affixed to the name)
Then run memdump as follows:
./memdump <pid> > /storage/extSdcard/MEM_DUMPS/<mem_dump_file_name>
E.g.: ./memdump 1234 > /storage/extSdcard/MEM_DUMPS/chrome.dmp
The dumping process should now begin (there’s no real progress report, just the cursor blinking, or hanging), but it should take some seconds to minutes depending on your phone’s processing capabilities (for Chrome i got an 800MB dump file so give it some time and it tool like 2min, or try some less memory intensive app that might result in a smaller process memory dump file)
Sources:
http://corochann.com/build-executable-file-with-android-ndk-after-lollipop-android-api-21-388.html
http://stackoverflow.com/questions/30498776/position-independent-executables-and-android-lollipop
infosectrek 