Introduction to Android Anti-Analysis and JEB Scripting
The landscape of Android application security is a constant cat-and-mouse game between developers and reverse engineers. Malicious actors, and even legitimate developers protecting intellectual property, frequently employ sophisticated anti-analysis techniques to deter static and dynamic investigation. These techniques can range from code obfuscation and anti-debugging mechanisms to anti-tampering checks and control-flow flattening. While manual analysis in a decompiler like JEB is powerful, tackling these defenses efficiently often requires automation. This guide delves into leveraging JEB Decompiler’s robust scripting capabilities to bypass common Android anti-analysis methods, streamlining your reverse engineering workflow.
JEB Decompiler provides a powerful Python API that allows reverse engineers to programmatically interact with the loaded application’s internal representation. This means you can write scripts to automate tedious tasks, identify complex patterns, modify the analyzed artifact, and ultimately accelerate the bypass of intricate protections.
Common Android Anti-Analysis Techniques
Before we dive into scripting, let’s briefly review some prevalent anti-analysis techniques you might encounter:
- Code Obfuscation: Renaming classes, methods, and fields; string encryption; control-flow flattening; instruction substitution.
- Anti-Debugging: Detecting the presence of a debugger (e.g., using
Debug.isDebuggerConnected(), checking /proc/self/status).
- Anti-Tampering: Verifying the app’s integrity (e.g., checking package signature, checksums of code sections).
- Emulator/Root Detection: Identifying virtualized environments or rooted devices to prevent analysis in controlled settings.
- Dynamic Code Loading/Decryption: Encrypting parts of the DEX file and decrypting/loading them at runtime.
Our focus will be on using JEB scripts to automate the identification and neutralization of these obstacles.
Getting Started with JEB Scripting
JEB’s scripting environment is accessible via File -> Scripting -> New Script or by opening the Python console. Scripts are written in Python and interact with JEB’s API via the jeb.api module. Key objects you’ll often use include IUnit (for loaded files), IDexUnit (for Android specific units), IJavaMethod, IJavaClass, IJavaInstruction, and IJavaField.
from jeb.api import IScript, IDecompilerUnit, IJavaMethod, IJavaInstruction, J, ReferenceTo, INativeInstruction
class BypassAntiAnalysis(IScript):
def run(self, ctx):
# Get the current focused unit (e.g., a DEX file)
unit = ctx.get_current_unit()
if not isinstance(unit, J.IDexUnit):
ctx.log('Please open an Android DEX unit.')
return
ctx.log(f'Analyzing unit: {unit.get_name()}')
# Example: Iterate through all classes and methods
for c in unit.get_classes():
for m in c.get_methods():
if m.is_external(): # Skip external (library) methods
continue
# Add your analysis logic here
# ctx.log(f' Method: {m.get_signature()}')
Case Study 1: Automating String Decryption
String obfuscation is a common technique where meaningful strings are encrypted and decrypted at runtime. Manually identifying and decrypting these strings can be incredibly time-consuming. We can write a JEB script to automate this.
Consider a scenario where strings are decrypted by a specific helper method, say com.example.app.Utils.decrypt(byte[] encryptedBytes, int key). Our goal is to find calls to this method, execute the decryption logic within our script, and replace the original encrypted string reference with the decrypted plaintext.
Identifying the Decryption Pattern
First, manually identify the decryption method. Let’s assume its signature is Lcom/example/app/Utils;decrypt([BI)Ljava/lang/String;. You’ll often see a sequence like:
- Loading an encrypted byte array (e.g.,
const-string, sget-object of a static field).
- Loading an integer key.
- Calling the decryption method (
invoke-static).
- Storing the result.
JEB Script for String Decryption
from jeb.api import IScript, IDecompilerUnit, IJavaMethod, IJavaInstruction, J, ReferenceTo, INativeInstruction
from array import array
class DecryptStrings(IScript):
def run(self, ctx):
unit = ctx.get_current_unit()
if not isinstance(unit, J.IDexUnit):
ctx.log('Please open an Android DEX unit.')
return
target_decrypt_method_sig = 'Lcom/example/app/Utils;decrypt([BI)Ljava/lang/String;'
decrypt_method = unit.find_method(target_decrypt_method_sig)
if not decrypt_method:
ctx.log(f'Decryption method {target_decrypt_method_sig} not found.')
return
ctx.log(f'Found decryption method: {decrypt_method.get_signature()}')
# Iterate through all cross-references to the decrypt method
for ref_to in decrypt_method.get_references_to():
if ref_to.get_type() == ReferenceTo.TYPE_METHOD_CALL:
caller_method = unit.get_method(ref_to.get_address().get_method_address())
if not caller_method:
continue
# Get the instruction that makes the call
call_instr_addr = ref_to.get_address()
call_instr = unit.get_instruction(call_instr_addr)
# In DEX, 'invoke' instructions typically use registers V0 to VN for arguments
# We need to trace back to get the arguments to the decrypt method
# This requires more complex data-flow analysis, simplified here for illustration
# --- Simplified Argument Extraction (requires more sophisticated logic for real cases) ---
# Assume arguments are directly preceding the invoke instruction in specific registers
# For this example, we'll manually provide dummy data that mimics the pattern
encrypted_bytes_dummy = array('B', [0x78, 0x61, 0x6e, 0x76, 0x22]) # Example for 'hello'
key_dummy = 0x12 # Example key
# --- Emulate Decryption (replace with actual logic for your target) ---
decrypted_string = self.perform_decryption(encrypted_bytes_dummy, key_dummy)
ctx.log(f'Decrypted: {decrypted_string}')
# Apply a comment to the instruction or rename a variable
ctx.add_comment(call_instr_addr, f'Decrypted: "{decrypted_string}"', True)
# A more advanced script would rename the variable holding the result
# For example, caller_method.rename_variable(var_id, new_name)
def perform_decryption(self, encrypted_bytes, key):
# This is a placeholder for your actual decryption logic
# In a real script, you would replicate the logic of the target_decrypt_method_sig
# For this example, let's assume a simple XOR decryption with a fixed key for illustration
decrypted_list = []
for byte_val in encrypted_bytes:
decrypted_list.append(byte_val ^ key)
return bytes(decrypted_list).decode('utf-8')
Explanation: The script finds all references to our target decryption method. For each call, it would ideally perform data-flow analysis to extract the actual encrypted byte array and key. For simplicity, our example uses dummy data. The core idea is to then execute the decryption logic (mimicking the original method) and use ctx.add_comment() to annotate the call site with the plaintext string. More advanced scripts could rename variables that hold the decrypted result for better readability.
Case Study 2: Defeating Anti-Debugging Checks
Anti-debugging checks often involve calling methods like android.os.Debug.isDebuggerConnected() or inspecting /proc/self/status. Our goal is to patch the bytecode to bypass these checks, making the application believe no debugger is attached.
Identifying Anti-Debugging Logic
Search for calls to Landroid/os/Debug;isDebuggerConnected()Z. When this method returns true, the application might exit or trigger anti-analysis routines. We want to ensure it always returns false.
JEB Script for Anti-Debugging Bypass (Dynamic Patching)
We can achieve this by modifying the instruction that *uses* the return value of isDebuggerConnected(), or by directly patching the method call itself to load a constant 0 (false) instead of its actual return value.
from jeb.api import IScript, IDecompilerUnit, IJavaMethod, IJavaInstruction, J, ReferenceTo
class BypassDebuggerCheck(IScript):
def run(self, ctx):
unit = ctx.get_current_unit()
if not isinstance(unit, J.IDexUnit):
ctx.log('Please open an Android DEX unit.')
return
target_method_sig = 'Landroid/os/Debug;isDebuggerConnected()Z'
debugger_method = unit.find_method(target_method_sig)
if not debugger_method:
ctx.log(f'Debugger check method {target_method_sig} not found.')
return
ctx.log(f'Found debugger check method: {debugger_method.get_signature()}')
# Iterate through all cross-references to the debugger check method
patched_count = 0
for ref_to in debugger_method.get_references_to():
if ref_to.get_type() == ReferenceTo.TYPE_METHOD_CALL:
call_instr_addr = ref_to.get_address()
call_instr = unit.get_instruction(call_instr_addr)
if call_instr and call_instr.get_mnemonic() == 'invoke-static':
# The result of invoke-static Landroid/os/Debug;isDebuggerConnected()Z
# is typically stored in V0 (or another register, depending on usage).
# We want to make it appear as if V0 always contains 0 (false).
# A robust way is to replace the 'invoke-static' with 'const/4 v0, #0'
# Get the method and instruction index where the call happens
method_address = call_instr_addr.get_method_address()
instr_index = call_instr_addr.get_instruction_index()
# Get the register where the return value is expected (usually V0 for invoke-static Z)
# This can be tricky to determine generically without data flow analysis.
# For simplicity, let's assume it's always V0 in our target scenarios.
target_reg = 0 # Corresponds to v0
# Create bytecode for 'const/4 v0, #0' (0x1200) - Loads 0 into v0
# Dalvik Opcode 0x12 is 'const/4', which takes a register and a nibble value.
# 0x1200 means const/4, target register 0, value 0.
patch_bytecode = bytearray([0x00, 0x12]) # In little-endian, it's 0x1200
try:
# Apply the patch
unit.set_instruction_bytecode(call_instr_addr, patch_bytecode)
ctx.log(f' Patched invoke-static at {call_instr_addr}: replaced with const/4 v{target_reg}, #0')
ctx.add_comment(call_instr_addr, 'DEBUGGER CHECK BYPASS: Patched to return false', True)
patched_count += 1
except Exception as e:
ctx.log(f' Failed to patch instruction at {call_instr_addr}: {e}')
ctx.log(f'Finished patching. Total patched calls: {patched_count}')
Explanation: This script identifies calls to isDebuggerConnected(). Instead of letting the original method execute, it replaces the invoke-static instruction with a const/4 v0, #0 instruction. This effectively hardcodes the return value to false (0) in register v0, making any subsequent conditional checks believe no debugger is present. The set_instruction_bytecode() method is crucial for modifying the loaded DEX bytecode.
Advanced Scripting Considerations
- Data Flow Analysis: For complex argument extraction (like in the string decryption example), you’ll need to implement or utilize JEB’s internal data-flow analysis capabilities to accurately trace register values and static field contents.
- Class Hierarchy Traversal: Scripts can traverse class hierarchies to find overridden methods or inherited fields, useful for polymorphic obfuscation.
- Decompiler Output Manipulation: Beyond comments, you can rename variables, methods, and classes using methods like
IJavaMethod.rename_variable() or IJavaClass.rename_element() to improve readability of decompiled code.
- Dynamic Code Execution (within JEB): For some types of decryption or obfuscation, you might be able to create a small Java reflection sandbox within your script to execute parts of the target application’s logic, or use a Python emulator for specific instruction sets.
Conclusion
JEB Decompiler’s scripting engine transforms a powerful disassembler into an extensible, automated analysis platform. By learning to write custom scripts, reverse engineers can dramatically reduce the time and effort required to bypass complex Android anti-analysis techniques. From automating tedious string decryption to dynamically patching anti-debugging checks, scripting empowers you to not just observe, but actively manipulate and understand heavily protected applications. Mastering these advanced scripting techniques is an essential skill for anyone serious about Android reverse engineering.