Full analysis of Android security strengthening technology (Part 2)

01 Anti-hijacking

Principle

Among the security strengthening technologies provided, the anti-hijacking function is particularly aimed at the scenario where malicious programs try to cover or control the protected application. When a strengthened application is being used in the foreground by the user, if any unauthorized background process tries to push or overlay the interface of the application, the system will automatically trigger the warning mechanism.

The specific implementation method is that the security strengthening module continuously monitors the status of the application to ensure that it runs in the foreground of the device. Once it is detected that the application suddenly switches to the background, while the user has not actively switched the application, the system will immediately judge that this behavior may be hijacking or malicious attack. At this time, a warning dialog box will pop up to inform the user that 'the application has gone to the background', reminding them that they may be under attack, and suggesting that users take appropriate measures, such as checking the recently installed applications or updates, and confirming the security of the current network environment.

This feature greatly enhances the security protection of the application, avoiding security issues such as phishing attacks and identity theft, thereby protecting users' privacy and data from being exploited by malicious software. At the same time, it also improves users' trust and satisfaction in the products of the strengthened technology company.

Technical description:

By judging whether the process displayed in the foreground is the application itself and whether it is the interface set for anti-hijacking. If it is the interface set for anti-hijacking, a warning prompt pops up once it enters the background; otherwise, there is no prompt. Anti-hijacking is mainly carried out in the onStop() lifecycle method of activity, when the onStop() method is executed, it is judged whether the package name of the activity at the top of the activity stack is consistent with the package name of the application. In Android 5.0 and later versions, it is judged whether the activity is in the foreground. However, this method does not work well in some customized systems, and this anti-hijacking SDK perfectly solves it by adding verification and other means. It is safer than other anti-hijacking SDKs.

By providing an interface anti-hijacking SDK package, it monitors the system environment in real-time during runtime and listens to sensitive APIs to achieve the purpose of alerting users; a warning box pops up when the phishing interface starts.

02 Anti-emulator

Technical description

The implementation principle of App protection against emulators mainly involves multiple levels of technical strategies, aiming to prevent attackers from executing and analyzing applications in the emulator environment, thereby protecting the logic and data of the application from illegal acquisition and copying.

1. Environment detection:The protection system detects the characteristics of the running environment, including the processor, operating system version, system settings, etc., to determine whether the current environment is an emulator. For example, some emulators may have different device model and manufacturer information when running Android applications, which may differ from real devices.
2. Hardware feature check:The sensor data or processor instruction set of real devices is often different from that of emulators. Apps can identify whether they are running in a simulated environment by checking these hardware features.
3. Performance and resource difference analysis:The performance of CPU and GPU, memory, and storage access speed of real devices is usually significantly different from that of emulators. By evaluating these parameters, Apps may detect the use of emulators.
4. System API and feature differences:By using API calls or functions specific to real devices, design operations that cannot be executed on emulators. For example, certain real camera or GPS functions are not available on emulators.
5. Battery information check:The battery capacity and usage of real devices are different from those of emulators. Apps can check this information to identify whether they are in a simulated environment.
6. Network environment detection:The network connection of emulators may be different from that of real devices, such as IP address range, network latency, and other features.
7. Cross-platform behavior detection:Some emulators allow Apps to run on different operating systems. Whether an App can run simultaneously on multiple operating systems can serve as a basis for identification.

ROOT detection

In the use of mobile devices today,permissions increase the risk of the device being attacked by malware, especially when malicious programs obtainThe acquisition and use of permissions has become a double-edged sword. On the one hand, users通过获取permissions increase the risk of the device being attacked by malware, especially when malicious programs obtainBy obtainingpermissionspermissions increase the risk of the device being attacked by malware, especially when malicious programs obtaincan customize the device, uninstall unnecessary pre-installed applications, and optimize device performance; on the other hand,permissions increase the risk of the device being attacked by malware, especially when malicious programs obtainRoot

permissions, they can bypass the security restrictions of the operating system and perform more advanced malicious operations.

1. After obtaining root:

• System File and Directory CheckCheck for specific flags in system files and directories, such as,/system/bin/su,/system/xbin/su/system/sbin/su
• Check.etc., these files exist on rooted devices./etc/install.log
• Files, if this file is detected during the boot process, it may mean that the system has been rooted.

2. Check for the existence of some typical root management applications, such as SuperSU, Magisk, etc.:

• System Property CheckCheck whether certain flags related to root have been set in the system properties, such asro.secure, on a rooted device, this may beCheck whether the value of the property is, on a rooted device, this may be0
• Check.ro.debuggableCheck whether the property is1, which indicates that the device is in debug mode and may be rooted.

3. Attempt to execute privileged commands:

• By executing commands requiring high privileges and checking their output, such asgetprop,idetc., to determine whether the current application has root permissions.
• Usetry-catchCapture exceptions thrown when executing commands, if the command execution is successful but no exceptions are thrown, it may mean that the device is rooted.

4. Exploit system vulnerabilities:

• Attempt to obtain root permissions by exploiting known system vulnerabilities; if successful, it indicates that the device has been rooted.

5. Monitor system behavior:

• Monitor system settings, application lists, and other sensitive operations to detect whether any applications or processes have obtained root permissions without user authorization.

Application Scenario Description

1. Uninstall system pre-installed applications

• User Needs:To free up storage space or remove unnecessary applications, users may choose to root the device to uninstall system pre-installed applications that cannot be uninstalled normally.
• Security Risks:Once a device is rooted, all applications are potentially capable of requesting and obtaining root permissions. If there are no appropriate protective measures, malicious applications can use this permission to perform unauthorized operations.

2. Malware Attacks

• Attack Method: