GDA Vulnerability Scanner

Introduction

GDA vulnerability scanning engine consists of vulnerability detection engine and rule interpretation engine:

The vulnerability detection engine uses a two-level hash table to store methods for the rapid location of methods. At the same time, an efficient vulnerability detection engine is built by combining with GDA's unique high-speed decompiler kernel, HIRA (advanced intermediate representation analyzer), API chain detector, and other analysis modules.

The rule interpretation engine adopts the rule decision based on a stack-state machine and adopts a dynamic rule interpreter to interpret rules. The regular expression is stored in the stack by the lexical analyzer and Parser, and the rule interpreter is based on the stack to interpret and execute the rule expression. The reason for this is that once the parser calls the parser and the interpreter, it will not scan the whole stack and check the execution of the whole rule. A Boolean state value (more complex parameters are carried in the result). Similarly, GDA's rule interpretation engine does not wait for all expressions to execute before making a rule decision. Instead, it adopts a more efficient dynamic decision method.

Get started quickly

GDA vulnerability scanner is a rule-driven static scanner, so we should use it as long as we learn to define rules correctly. Here is a typical rule(more rules):

gda_vrule{   
	id=1;
	rule=api.match("getInstance","javax.crypto.Cipher")&&api.callors.refString^~".*/ECB/.*";
	type="crypto";
	vname="ECB Cipher Usage";
	vlevel="VULNERABILITY";
	description="ECB mode is an insecure encryption technique and prone to data leakage, getInstance should not be called with ECB as the cipher mode, as it is insecure.";
	suggestion="use the other secure encryption mode";
	returnType=callors;
}

Where id is the unique identifier of the rule (optional), the rule is the rule expression (defining the rule), type represents the type of the rule (such as remote command execution), vname is the and vulnerability name (custom), vlevel is the rule level (custom), description is the vulnerability description, suggestion is the vulnerability suggestion, and returnType includes callors (of the last matched result ) , methods (return matched method) and strings (return matched string).

The rule expression(rule) is composed of built-in functions and built-in variables. The case is used to detect whether unsafe encryption options are used in an app. The built-in function(api.match) is used to match the API functions from the currently analyzed app, and then store the matched functions in the api object. The second expression uses the callers property of the api object to instruct GDA to collect the callers of the matching results. The refString property collects the strings referenced by the callers and finally matches the subsequent regular expressions by regular inclusion operator.

In GDA, start the vulnerability rule test window through the menu Tools > vul tester.

Then click the ‘load rules’ button to load your custom rule file (Please store all rules in the. Rule file firstly). Then all rules will be displayed in the list on the left. Click each list to view the specific rule details. You can compile&run, delete, and modify the rules.

1. Start rule tester; 
2. Load rule file; 
3. Click rule view; 
4. Compile execution rule.

In addition, in GDA, you can directly load rule files to compile and execute custom rules through the menu: File > execute vul rule.

Here is a case study of rule scanning:

In the scanning results, we can also double-click the method or class between [] to directly locate the place where the vulnerability risk exists.

Complete built-in functions, built-in variables, and operators

built-in functions

Built-in functions can be called directly in rules.

Built-in functions	introduction
api.match(name,package,argn)	It is used to locate the location of API functions. After called, the execution result will be stored in an api object. Then, an built-in member of the api can be used to match a rule. The parameter "name" represents the method name of API, "package" is the package name of the API, and "argn" represents the number of parameters of the API. "name" and "package" support matching multiple objects at the same time (separated by '|'). The usage form ([] optional) is: api.match(“mname[|mname1|mname2|....]”)//match API function names only; api.match(“mname[|mname1|mname2|....]”,”package[|package1|package2|....]”)//match API function names and package names; api.match(“mname[|mname1|mname2|....]”,”package[|package1|package2|....]”,2)//match API function names and package names, The number of specified parameters is 2; api.match(“mname[|mname1|mname2|....]”,”package[|package1|package2|....]”,”2-5”)//match API function names and package names, specify the number of parameters in the range of 2-5 (including 2,5); api.match(“mname[|mname1|mname2|....]”,1)//match API function names, The number of specified parameters is 1; api.match(“mname[|mname1|mname2|....]”,”2-4”)//match API function names, specify the number of parameters in the range of 2-4 (including 2,4)
method.match(name,package,argn)	Similar to the above
apk.exposed(typename)	check the component exposure issues."typename" can only take the following values: "activity", "receive" and "service" respectively check whether the three kind of components have component exposure issues.

Built-in Variables

　　　The built-in variables include four categories: 'api' built-in variables, 'method' built-in variables, 'apk' built-in variables, and 'manifest' built-in variables. The 'api' and 'method' built-in variables are functional built-in variables, which represent all APIs or methods in memory, and all of them contain caller related attributes; 'apk' built-in variables represent APK files, which contain the version, string, etc. And the 'manifest' variable represents AndroidMainfest Relevant information. The details are as follows**(string variable can perform the operators:"^", "!^", "^~", and integer can perform operators: ">", "<", ">=", "<=", "!=")**:

built-in variables	type	usage
api.callors.body.len method.callors.body.len	int	Must be after the built-in function and filter out the results that meet the conditions specified by the built-in variable from the results of the function execution. This variable instructs the decompiler to decompile the caller of the resulting function, and then performs integer matching on the length of the caller's function body.
api.callors.body1 method.callors.body1	string	This variable instructs the decompiler to decompile the caller of the resulting function, and then performs string matching on the caller's function body(the operators:).
api.callors.body2 method.callors.body2	string	This variable directs the decompiler to extract the list of functions used by the caller and then matches the function list.
api.callors.refString method.callors.refString	string	This variable instructs the decompiler to extract the caller's reference string and do string matching.
method.body.len	int	This variable instructs the decompiler to decompile the method in the matching result, and then performs integer matching on the length of the method body.
method.body1	string	This variable instructs the decompiler to decompile the method in the matched result and then performs integer matching on the length of the method body.
method.body2	string	This variable instructs the decompiler to extract the list of functions called by the matched method, and then perform function name matching on the calling list.
apk.minsdk	int	This variable can perform integer matching on the minimum SDK version number of APK.
apk.refstrings	string	The string of all DEX references in APK.
apk.allstring	string	String of all Dex in APK.
apk.allstring.line	string	String of all Dex in APK, matching by line.
manifest.application	string	All string information of application in Android manifest.
manifest.body	string	All string information of Android manifest.
mainfest.permission	string	All string information of permission in Android manifest.

Operator

operators	priority	role
||	0	Statement OR
&&	0	Statement AND
^	1	String contains
!^	1	String un-contains
^~	1	String regular-contains
==	1	String / integer equality
!=	1	String / integer not equal
>	1	Integer greater than
<	1	Integer less than
>=	1	Integer greater than or equal to
<=	1	Integer less than or equal to
!	2	NOT
()	3	-