fergarrui/custom-bytecode-analyzerJSON 규칙으로 사용자 정의할 수 있는 Java 바이트코드 분석기
JSON 규칙을 통해 사용자 지정이 가능한 Java 바이트코드 분석기입니다. 하나 이상의 Jar 또는 War 파일이 포함된 경로를 입력받아, 제공된 규칙을 사용하여 분석하고 결과를 HTML 보고서로 생성하는 명령줄 도구입니다.
usage: java -jar cba-cli.jar [OPTIONS] -a DIRECTORY_TO_ANALYZE
-a,--analyze <pathToAnalyze> 분석을 실행할 디렉터리의 경로입니다.
-c,--checks <checks...> 분석에서 실행할 사용자 지정 검사 목록입니다.
(공백으로 구분)
-f,--custom-file <customFile> 사용자 지정 규칙을 실행하기 위한 JSON 형식 파일을
지정합니다. 자세한 내용은
https://github.com/fergarrui/custom-bytecode-analyzer
에서 확인하세요.
-h,--help 이 메시지를 출력합니다.
-i,--items-report <maxItems> 보고서당 최대 항목 수입니다. 발견된 문제 수가 이 값을
초과하면 보고서가 여러 파일로 분할됩니다. 보고서에
문제가 너무 많을 것으로 예상될 때 유용합니다.
기본값: 50.
-o,--output <outputDir> 보고서를 저장할 디렉터리입니다. 경고 – 이 디렉터리에
이미 저장된 보고서가 있으면 덮어씁니다.
기본값은 "report"입니다.
-v,--verbose-debug 상세 정보를 디버그 모드로 증가시킵니다.
-vv,--verbose-trace 상세 정보를 추적 모드로 증가시킵니다. 속도가 느려지므로
필요할 때만 사용하세요.
규칙 파일은 -f,--custom-file 인수를 사용하여 지정할 수 있습니다. 파일은 JSON 형식이며 다음과 같은 구조를 가집니다:
final인 경우에만 지원됨net.nandgr.cba.custom.model.Rules.java 파일을 확인하여 Java 코드에서 구조를 볼 수도 있습니다.
examples 디렉터리 아래에 이미 여러 규칙이 있습니다. 아래에는 각 규칙에 대한 예제가 나열되어 있습니다.
사용자 지정 역직렬화를 수행하는 클래스를 찾아야 한다면, 아주 쉽게 할 수 있습니다. 클래스는 private void readObject(ObjectInputStream in)을 구현하여 사용자 지정 역직렬화를 정의합니다. 따라서 해당 메서드가 정의된 모든 클래스만 찾으면 됩니다. 다음과 같이 규칙을 정의하는 것만으로 충분합니다:
{
"rules": [{
"name": "Custom deserialization",
"methods": [{
"name": "readObject",
"visibility": "private",
"parameters" : [{
"type" : "java.io.ObjectInputStream"
}]
}]
}]
}
private 가시성, readObject 이름, java.io.ObjectInputStream 타입의 매개변수를 가진 메서드를 보고합니다. 매개변수는 배열이며, 둘 이상이 지정된 경우 모두 일치해야 보고됩니다. 규칙이 하나뿐이므로 custom-deserialization-0.html이라는 보고서가 생성됩니다.
이 경우 두 개의 메서드를 가진 하나의 규칙을 정의해야 합니다. 역직렬화를 위한 첫 번째 예제와 동일한 규칙, 그리고 private void writeObject(ObjectOutputStream out)에 일치하는 새로운 규칙입니다. 위의 JSON 구조에서 보듯이 rules.rule.methods 속성은 메서드의 배열이므로 다음과 같은 규칙을 작성할 수 있습니다:
{
"rules": [{
"name": "Custom serialization and deserialization",
"methods": [{
"name": "readObject",
"visibility": "private",
"parameters" : [{
"type" : "java.io.ObjectInputStream"
}]
},{
"name": "writeObject",
"report": "false",
"visibility": "private",
"parameters" : [{
"type" : "java.io.ObjectOutputStream"
}]
}]
}]
}
report 속성을 false로 설정하여 동일한 규칙에 대해 두 번 보고되지 않도록 했습니다. 두 번째 메서드는 조건으로만 사용하고, readObject 메서드만 보고하는 것이 이 규칙의 목적에 충분합니다.
속성이 정의되지 않으면 항상 true로 일치합니다. 예를 들어, 이 규칙은 모든 메서드 정의를 반환합니다:
{
"rules": [{
"name": "Method definitions",
"methods": [{
}]
}]
}
메서드 호출도 찾을 수 있습니다. 이 경우 JSON은 다음과 같습니다:
{
"rules": [{
"name": "String equals",
"invocations": [{
"owner": "java.lang.String",
"method": {
"name": "equals"
}
}]
}]
}
owner 속성은 메서드를 포함하는 클래스를 지정합니다.
이전 예제보다 조금 더 유용한 또 다른 메서드 호출 예제입니다:
{
"rules": [{
"name": "Method invocation by reflection",
"invocations": [{
"owner": "java.lang.reflect.Method",
"method": {
"name": "invoke"
}
}]
}]
}
메서드 호출과 동일하지만, 이 경우 메서드 이름은 <init>이어야 합니다.
{
"rules": [{
"name" : "String instantiation",
"invocations" : [{
"owner" : "java.lang.String",
"method" : {
"name" : "<init>"
}
}]
}]
}
이 규칙은 다음 코드에서 발생하는 경우를 찾습니다:
[...]
String s = new String("foo");
[...]
이 예제에서는 역직렬화 사용(이전 예제처럼 직렬화 동작을 정의하는 클래스가 아닌)을 찾고자 합니다. 역직렬화는 ObjectInputStream.readObject()가 호출될 때 발생합니다. 예를 들어 다음 코드 조각에서:
ObjectInputStream in = new ObjectInputStream(fileInputStream);
Object o = in.readObject();
따라서 ObjectInputStream에서 readObject라는 메서드 호출을 찾아야 합니다. 하지만 연구 맥락에서 많은 가양성(false positive)이 발생할 수 있습니다. 클래스가 사용자 지정 역직렬화를 정의할 때 private void readObject(ObjectInputStream in) 메서드 내부에서 이 메서드를 호출하기 때문입니다. 이로 인해 보고서가 너무 오염될 수 있습니다. 이러한 경우를 제외하고 진정한 역직렬화만 유지하려면 notFrom 속성을 사용할 수 있습니다:
{
"rules": [{
"name": "Deserialization usage",
"invocations": [{
"owner": "java.io.ObjectInputStream",
"method": {
"name": "readObject"
},
"notFrom": {
"name": "readObject",
"visibility": "private"
}
}]
}]
}
이 파일은 호출이 private void readObject(ObjectInputStream in) 메서드 내에서 이루어지지 않은 경우 java.io.ObjectInputStream.readObject() 호출을 찾습니다.
다음 코드로 컴파일된 클래스는 보고되지 않습니다:
private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
Object o = in.readObject();
}
하지만 다음 코드는 보고됩니다:
public Object deserializeObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
Object o = in.readObject();
return o;
}
from 속성도 notFrom과 정확히 같은 방식으로 호출에 설정할 수 있지만, 결과는 반대입니다: 정의된 메서드에서 호출이 이루어진 경우에만 일치합니다.
이 경우 superClass 속성을 사용할 수 있습니다. javax.servlet.http.HttpServlet을 확장하는 모든 클래스를 찾으려면 다음과 같은 규칙을 사용할 수 있습니다:
{
"rules": [{
"name": "Java servlets",
"superClass" : "javax.servlet.http.HttpServlet"
}]
}
인터페이스 배열을 구현하는 클래스를 찾기 위해 규칙을 작성할 수 있습니다. 규칙에 둘 이상의 인터페이스가 정의된 경우 클래스는 이들 모두를 구현해야 보고됩니다. javax.net.ssl.X509TrustManager를 구현하는 클래스를 찾으려면 규칙은 다음과 같습니다:
{
"rules": [{
"name": "X509TrustManager implementations",
"interfaces" : ["javax.net.ssl.X509TrustManager"]
}]
}
interfaces는 배열이므로 문자열을 대괄호 안에 추가해야 합니다. 예: ["interface1", "interface2", ...]
어노테이션도 지원됩니다. 규칙(클래스 어노테이션 찾기), 메서드 또는 변수(매개변수 또는 지역 변수)에 여러 어노테이션 속성을 정의할 수 있습니다. 분석된 클래스에서 모두 발견되면 보고됩니다.
예를 들어, Spring 엔드포인트를 찾으려면 org.springframework.web.bind.annotation.RequestMapping으로 어노테이션된 클래스 또는 메서드를 검색합니다. 따라서 규칙은 다음과 같습니다:
{
"rules": [{
"name": "Spring endpoint - class annotation",
"annotations" : [{
"type" : "org.springframework.web.bind.annotation.RequestMapping"
}]
},
{
"name": "Spring endpoint - method annotation",
"methods" : [{
"annotations" : [{
"type" : "org.springframework.web.bind.annotation.RequestMapping"
}]
}]
}]
}
rule.fields 속성을 사용하여 클래스 필드를 찾을 수 있습니다. 비공개 String 필드 중 패스워드 이름을 가진 필드를 찾으려면 다음과 같은 규칙을 사용할 수 있습니다:
{
"rules": [{
"name" : "Password fields",
"fields" : [
{
"visibility" : "private",
"type" : "java.lang.String",
"nameRegex" : "(password|pass|psswd|passwd)"
}
]
}]
}
변수를 찾으려면 rule.variables를 사용할 수 있습니다. 이 속성은 지역 변수와 메서드 인수 변수를 보고합니다.
javax.servlet.http.Part 타입의 모든 변수를 찾으려면 규칙은 다음과 같습니다:
{
"rules": [{
"name" : "Servlet upload file",
"methods" : [{
"variables" : [{
"type" : "javax.servlet.http.Part"
}]
}]
}]
}
동일한 JSON 파일에 여러 규칙을 정의할 수 있습니다. 이 규칙들은 별도로 처리되어 보고되며 서로 영향을 주지 않습니다. 위의 예제 규칙 중 일부를 결합할 수 있습니다:
{
"rules": [{
"name": "Custom deserialization",
"methods": [{
"name": "readObject",
"visibility": "private",
"parameters": [{
"type" : "java.io.ObjectInputStream"
}]
}]
},{
"name": "Method invocation by reflection",
"invocations": [{
"owner": "java.lang.reflect.Method",
"method": {
"name": "invoke"
}
}]
}]
}
여기에는 "Custom deserialization"과 "Method invocation by reflection"이라는 두 가지 규칙이 있습니다. 두 번의 개별 실행으로 처리되는 것처럼 처리되며, 규칙당 하나의 보고서가 생성됩니다. 규칙 이름이 동일하면 동일한 파일에 보고됩니다.
프로젝트를 다운로드하여 빌드하면 JSON 형식으로 다루지 않는 더 복잡한 사용자 지정 Java 규칙을 추가할 수 있습니다. 이미 net.nandgr.cba.visitor.checks 패키지 아래에 세 가지 예제가 있습니다: CustomDeserializationCheck, DeserializationCheck, InvokeMethodCheck입니다. net.nandgr.cba.custom.visitor.base.CustomAbstractClassVisitor를 확장하여 자신만의 규칙을 만들 수 있습니다.
위에서 언급했듯이 보고서는 기본적으로 report 폴더 아래에 생성됩니다. 각 규칙은 이름이 같지 않는 한 별도의 파일을 갖습니다.
보고서가 너무 크면 -i,--items-report <maxItems> 매개변수를 사용하여 분할할 수 있습니다. 각 파일은 지정된 인수 이하(마지막 파일인 경우)의 항목을 포함합니다.
보고된 각 항목은 발견된 jar, 클래스 이름 및 메서드 이름(해당되는 경우)을 지정합니다. 또한 클래스의 디컴파일된 버전을 표시하여 빠른 시각적 검사를 용이하게 합니다.
java.io.File 인스턴스화를 찾기 위한 규칙에 대해 항목이 표시되는 예시:
보안 버그를 검색할 때 호출 그래프는 매우 유용합니다. 현재 report 디렉터리 아래에 간단한 DOT 호환 파일이 생성됩니다.
그래프는 발견된 문제가 호출될 수 있는 모든 가능한 흐름을 포함합니다. 예를 들어 역직렬화를 찾는 규칙을 사용하는 경우, 역직렬화를 호출하는 메서드로 이어지는 모든 가능한 경로를 포함하는 그래프가 생성됩니다.
파일은 call-graph.dot이며 다음과 같이 보입니다(매우 간단한 예제):
graph callGraph {
"demo.callgraph.Class1:method1" -- "demo.callgraph.Class2:method2"
"demo.callgraph.Class3:method3" -- "demo.callgraph.Class2:method2"
}
시각적으로 표시하려면 DOT(또는 호환 소프트웨어)를 사용할 수 있습니다. 예를 들어, 파일을 svg로 변환하려면:
dot -Tsvg call-graph.dot -o call-graph.svg
시스템 PATH에 DOT가 있는 경우 기본적으로 자동으로 수행됩니다. 그렇지 않은 경우 Debian 기반 시스템에서 sudo apt-get install graphviz를 사용하여 DOT를 설치할 수 있습니다.
call-graph.svg라는 SVG 파일이 생성되며, inkscape나 firefox와 같은 프로그램을 사용하여 PNG로 변환하거나 시각화할 수 있습니다.
위의 call-graph.dot 파일의 매우 간단한 예제는 다음과 같습니다:
몇 가지 제한 사항이 있습니다. 예를 들어 검색된 항목이 java.lang.Runnable.run() 또는 유사한 메서드에 있는 경우 스레드가 실행되는 위치를 찾지 못합니다.
또한 그래프는 StackOverflowError를 방지하기 위해 순환을 정리하며, 대규모 디렉터리 분석 중 시스템 메모리가 소진되지 않도록 다소 보수적인 방식으로 만들어졌습니다.
향후 버전에서 더 많은 옵션이 추가될 예정입니다.
java -jar cba-cli-<version>.jar -a /path/with/jars -f /path/with/json/file/rules.json
사용자 지정 Java 규칙을 사용하려면 -c의 인수로 클래스 이름을 지정해야 합니다.
java -jar cba-cli-<version>.jar -a /path/with/jars -c DeserializationCheck
공백으로 구분된 목록을 허용하므로 여러 사용자 지정 규칙을 정의할 수 있습니다(각 규칙은 별도의 보고서를 생성합니다):
java -jar cba-cli-<version>.jar -a /path/with/jars -c DeserializationCheck InvokeMethodCheck CustomDeserializationCheck YourCustomRule
java -jar cba-cli-<version>.jar -a /path/with/jars -f /path/with/json/file/rules.json -c YourCustomRule1 YourCustomRule2
오류를 찾으려면 상세 정보를 증가시킬 수 있습니다. 디버그 레벨:
java -jar cba-cli-<version>.jar -a /path/with/jars -c YourCustomRule1 -v
추적 레벨:
java -jar cba-cli-<version>.jar -a /path/with/jars -c YourCustomRule1 -vv
현재 APK를 분석하려면 먼저 JAR로 변환해야 합니다.
d2j-dex2jar.sh -f -o app_to_analyze.jar app_to_analyze.apk-a 매개변수로 변환된 jar 파일이 포함된 디렉터리를 전달하여 평소처럼 cba-cli.jar 실행bin 디렉터리 아래에 이미 실행 가능한 jar 파일이 있습니다: https://github.com/fergarrui/custom-bytecode-analyzer/blob/master/bin/cba-cli-0.1-SNAPSHOT.jar . 수정하거나 사용자 지정 규칙을 추가하려면 다음을 수행하여 프로젝트를 빌드할 수 있습니다:
git clone https://github.com/fergarrui/custom-bytecode-analyzer.git
cd custom-bytecode-analyzer
mvn clean package
target 폴더 아래에 두 개의 jar 파일이 생성됩니다. cba-cli-<version>.jar에는 모든 종속성이 포함되어 있으며 실행 가능합니다. java -jar cba-cli-<version>.jar를 사용하여 실행할 수 있습니다.