- 9.1 Android System Information acquisition
- 9.1.1 Android.os.Build
- 9.1.2 Systemproperty
- 9.1.3 Android System Information example
- 9.2 Android apk app info get Packagemanager
- 9.3 Android apk app info get Activitymanager
- 9.4 parsing Packages.xml getting system Information
- 9.5 Android security mechanism
- 9.5.1 Android Security Mechanism introduction
- 9.5.2 Android system security implications
- 9.5.3 Android apk Anti-compilation
- 9.5.4 Android APK Encryption
To obtain configuration information for a system, you can usually obtain it from the following two areas:
- Android.os.Build
- Systemproperty
This class contains a large number of device and configuration information at System compile time:
- Build.board: Motherboard
- Build.BRAND:Android System Customizer
- Build.SUPPORTED_ABIS:CPU instruction Set
- Build.device: Device Parameters
- Build.display: Display Parameters
- Build.fingerprint: Unique number
- Build.serial: Hardware serial number
- Build.id: Revised version list
- Build.manufacturer: Hardware manufacturer
- Build.model: Version
- Build.hardware: Hardware Name
- BUILD.PRODUCT: Mobile Phone Product Name
- Build.tags: The label that describes the build
- Build.TYPE:Builder type
- Build.VERSION.CODENAME: Current Development code
- Build.VERSION.INCREMENTAL: Source Control version number
- Build.VERSION.RELEASE: Version string
- Build.VERSION.SDK_INT: Version number
- Build.HOST:host value
- Build.USER:User Name
- Build.time: Compile time
Systemproperty contains a number of system configuration property values and parameters:
- Os.version:OS version
- Os.name:OS Name
- Os.arch:OS Architecture
- User.home:Home Property
- User.name:Name Property
- User.dir:Dir Property
- User.timezone: Time zone
- Path.separator: Path delimiter
- Line.separator: Line delimiter
- File.separator: File delimiter
- Java.vendor.url:Java vender URL Property
- Java.class.path:Java Class Property
- Java.class.version:Java class version
- Java.vendor:Java Vender Properties
- Java.version:Java version
- Java.home:Java Home Property
So many of them, let's get their system information through the code:
We can also view system information in command line mode:
- Command-line mode enters the System/build.prop file directory and uses the Cat Build.prop command to view file information
We can also get the corresponding property values through the getprop of the ADB shell:
- Enter adb shell and use getprop ro.build.id to get information
There is also a very important directory storage System information, that is the/proc directory:
- Command-line mode enter the/proc file directory and use the Cat Cpuinfo command to open the Cpuinfo file to view system Information
Looking at so many system information, you should look at the APK application information, in the ADB shell command, there are two very powerful assistants, PM and AM,PM dominate the application package management, and am dominate the application of the activity management
- Activityinfo
Activityinfo encapsulates all of the information between < activity > and < eceiver> in the Mainfest file, including name, icon, label, Launchmode, and so on.
- ServiceInfo
Similar to Activityinfo, ServiceInfo encapsulates all information between the < service>.
- ApplicationInfo
It encapsulates the information between < application>, in particular, ApplicationInfo contains a lot of flag
- Flag_system represents a System application
- Flag_external_storage is indicated as an application installed on the SDcard
- PackageInfo
PackageInfo, similar to the previous three info classes, is used to encapsulate the relevant node information for the manifest file, and Pageageinfo contains all the activity and service information.
- ResolveInfo
Resolveinfo contains information on the previous level of < intent> information, so it can return activityinfo, serviceinfo, etc. containing < intent>
- The method that is encapsulated in Packagemanager to obtain this information:
- Getpackagemanager (): This method allows you to return a Packagemanager object
- Getapplicationinfo (): Returns the applicationinfo of the specified package name in the form of ApplicationInfo
- Getapplicationicon (): Returns the icon for the specified package name
- Getinstalledapplications (): Return the installed app as a applicationinfo
- Getinstalledpackages (): Return the installed app as a PackageInfo
- Queryintentactivities (): Returns the Resolveinfo object, activity collection, of the specified intent
- Queryintentservices (): Returns the Resolveinfo object, service collection, of the specified intent
- Resolveactivity (): Returns activity for the specified intent
- Resolveservice (): Returns the service for the specified intent
The following is a practical example of screening different types of apps through Packagemanager, using the Flag_system in ApplicationInfo to determine:
- If the currently applied flags & Applicationinfo.flag_system!=0 is the system application
- If the flags & Applicationinfo.flag_system <=0 are third-party apps
- Special, when the system application is upgraded, it will become a third-party application: Flags & Applicationinfo.flag_updated_system_app!=0
- If the currently applied flags & Applicationinfo.flag_external_storage!=0 are installed on the SDcard application
We encapsulate a bean to hold the fields we need:
Next, judging the various types of applications by the above-mentioned judgment method:
Activitymanager Get application information encapsulates a number of bean objects:
- Activitymanager.memoryinfo
Memoryinfo has several very important fields: Availmem (System free Memory), Totalmem (total memory), threshold (low memory threshold, which is the critical value for distinguishing low memory), lowmemory (whether in low memory)
- Debug.memoryinfo
This memoryinfo is used to count the memory information of the process
- Runningappprocessinfo
Run process information, stored fields are: processName (process name), PID (Process pid), UID (process uid), pkgList (all packages under the process)
- Runningserviceinfo
Run the service information, in it also contains a number of service process information, while there are some other information, Activesince (the first time, the mode of activation), foreground (whether the service is executed in the background)
Here's an example of how to use Activitymanager, we encapsulate a bean to hold the fields we need:
Next, call the Getrunningappprocesses method, return the currently running process information, and save the information we care about in the bean:
When the system is initialized, Packagemanager's underlying implementation class Packagemanagerservice scans the system for specific directories and resolves the apk file, while Android saves the application information it obtains to the XML file, Make a roster of apps that will be updated when the APK is installed, removed, and upgraded in the system
The Packages.xml is located in the/data/system/directory, and we export it with the ADB pull command to view the analysis:
- < permissions> tags
The permissions tag defines all of the current system's permissions and is divided into two categories: system-defined and APK-defined
< package> tags
The package represents the properties of an APK, where the message meaning of each node is roughly
- NAME:APK's Package name
- CADEPATH:APK installation path, mainly in the System/app and Data/app two kinds, the former is a manufacturer-customized apk, the latter is a user-installed third-party APK
- UserID: User ID
- Version: Versions
< perms> tags
The < uses-permission> tag in the androidmanifest file corresponding to the APK, recording the APK's permission information
No knowledge points
- First line of Defense: code security Mechanism-code obfuscation Proguard
Proguard can confuse the key code, replace the name to make it difficult for the attacker to read, and also compress the code to optimize the compiled Java bytecode
- Second line of Defense: Application access Rights Control--manifest file permission statement, permission check mechanism
Any app that uses Android restricted resources needs to display the permissions required to declare to the system, and only when an app app has the appropriate permissions to request restricted resources, through the check of the permission mechanism and using the system binder object to complete the call to the system service. But this line of defense also has congenital deficiencies, such as the following:
- The granted permission cannot be stopped
- Users cannot restrict partial permissions when the app claims app usage rights
- The declarative mechanism of authority is related to the user's security concept
The Android system usually checks the operator's permissions in the following order:
- First, the permission name is judged, and if NULL it is returned directly permission_denied
- Second, the judgment uid, if 0 is the root permission, does not do the permission control, if the UID of the system service is the systems services, does not do the permission control, if the UID and the parameter request UID is different then returns permission_denied
- Finally, by calling the Packagemanageservice.checkuidpermission () method to determine whether the UID has the appropriate permissions, the method will go to the XML's permission list and the system-level platform.xml to find
- Third line of Defense: application signing mechanism a digital certificate
All apps in Android will have a digital certificate, which is the app's signature, which is used to protect the app's author and its app's trust, and only apps with the same digital signature will be considered the same app at the time of upgrade. And Android does not install unsigned apps.
- Fourth line of defense: Linux kernel Layer Security one by one UID access control
Animid Nature is based on the Linux kernel, so Android also inherits the security features of Linux, TOEFL and IELTS such as file system permissions control by User,group,other and read (R), write (W), execute (x) different combinations to achieve, again, Android also implements this mechanism, typically, only system, root users have access to systems files, and general users cannot access
- Fifth line of Defense: Android Virtual machine sandbox mechanism-sandbox flow
Android apps run in virtual machines, so there is a sandbox mechanism that allows applications to be isolated from each other, typically without access to each other, each app has its own UID, and each app runs in a separate virtual machine, completely isolated from other applications, In the implementation of security mechanisms, but also to allow the application between the non-impact, instant one application crashes, and does not cause other application exceptions
- Code vulnerability
- Root risk
- The security mechanism is not sound
- User Safety Awareness
- Android Development principles and security
A few points in the book, I believe we are all familiar with, so do not explain
Here's a personal blog with a simple introduction: Android Four components--activity switch effect, kill process, kill all activity, install and decompile
In order to be able to protect a compiled Javaclass file, the code is often confused with Proguard:
- Proguard: Renaming classes, fields, methods, and properties with meaningless letters
- Optimize bytecode files by removing useless classes, fields, methods, and properties, and deleting useless comments
Using Proguard is also simple, in Android Studio you can open Build.gradle (Module:app):
The minifyenabled here is to open the Proguard switch, Proguardfiles belongs to the configuration confusion file, divided into two parts:
- Use default obfuscation files, located in the < SDK directory >/tools/proguard/proguard-android.txt directory
- Using a custom obfuscation file, you can find this file in your project's app folder, where you can define the obfuscation rules for the incoming third-party dependency package.
Android Elite Biography-The Nineth Chapter: Android System Information and security mechanism