forked from CalebFenton/simplify
-
Notifications
You must be signed in to change notification settings - Fork 0
/
ideas.txt
137 lines (90 loc) · 5.04 KB
/
ideas.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
This is a scratch pad for ideas.
Many of them are too undercooked or too broad to be articulated as issues on github.
Emulate System.exit() to halt the thread
During execution, the context has no awareness of the current method or the call stack. Knowing these things allows for:
1.) illegal access checks on fields, right now, no way to tell if the field is in the same class as the current method
2.) contextualized exception throwing with stack trace
* update - execution context of first op in method has callerContext and callerAddress, which can be traced back up to rebuild call stack
Beef up whitelist:
many Class.is*
Emulate:
Ljava/lang/reflect/Method;->invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
invoke ourselves or run emulated method
Android class lifecycle initialization
sometimes it can be assumed onCreate has been called
or just give a list of methods to be called before whatever else
java -jar simplify/build/libs/simplify-0.1.0-all.jar -i 7604399 -it 'PornApplication;->i2c1cqop3faop3cdhokggmd97ce\(\)'
ArrayLists are initialized in onCreate, but since that's not known, everything fails
Emulate / spoof stack traces - requires call stack in context or similar
new-instance v1, Ljava/lang/Exception;
invoke-direct {v1}, Ljava/lang/Exception;-><init>()V
invoke-virtual {v1}, Ljava/lang/Exception;->getStackTrace()[Ljava/lang/StackTraceElement;
invoke-virtual {v1}, Ljava/lang/StackTraceElement;->getMethodName()Ljava/lang/String;
move-result-object v2
invoke-direct {v0, v2}, Ljava/lang/StringBuffer;-><init>(Ljava/lang/String;)V
invoke-virtual {v1}, Ljava/lang/StackTraceElement;->getClassName()Ljava/lang/String;
invoke-static {}, Ljava/lang/Thread;->currentThread()Ljava/lang/Thread;
move-result-object v2
invoke-virtual {v2}, Ljava/lang/Thread;->getStackTrace()[Ljava/lang/StackTraceElement;
Fail stories:
* 6494727's phone/b;->a([Ljava/lang/String;)
doesn't work and looks like it should
* inner classes are not always resolved properly, should add tests for this, look at base64$coder
* methods with arrays, like anything in 8748278, don't optimize correctly
Success stories:
* java -jar simplify/build/libs/simplify-0.1.0-all.jar -i 6247332 -it 'Configs;-><clinit>'
* java -Xmx6g -jar simplify/build/libs/simplify-0.1.0-all.jar -i 7958300/smali -it '/smv;'
NOTES TO MYSELF (good luck understanding)
remove array data payloads that are unreferenced :D
Obfuscated example does this in reflected field lookups
what if?
get stack trace, first element
from inside a method that's being optimized from main
the call stack *should* be ambiguous
but if it's not, could give away it's being virtually executed
*get first element would be a string, that would get constantized during optimization
wasRegisterRead unit test possibility!
# make sure v0 is not removed
const/4 v2, 0x5
invoke-static {v2}, Ljava/lang/Integer;->valueOf(I)Ljava/lang/Integer;
move-result v0
move-object v1, v0
invoke-static {v1}, Ldoes/not/exist;->howdy(Ljava/lang/Integer;)V
# make sure v0 IS REMOVED
const/4 v2, 0x5
invoke-static {v2}, Ljava/lang/Integer;->valueOf(I)Ljava/lang/Integer;
move-result v0
invoke-static {v2}, Ljava/lang/Integer;->valueOf(I)Ljava/lang/Integer;
move-result v1
invoke-static {v1}, Ldoes/not/exist;->howdy(Ljava/lang/Integer;)V
look for all instanceof unknownvalue, replace with isUnknown if possible
tests for binary math op
2 * different types (int, long, etc) tests - lhs or rhs unknown makes unknown int for int ops
test fill array data payload by making sure it creates bytes, ints or longs or whatever is needed
fillednewarrayop should handle partial unknown
test switch works for integer, short, byte, etc. types
assumeMaxUnknown for invokeop wont work for LocalInstance.isInitialized == false, add tests
boolean isInitializing = methodDescriptor.contains(";-><init>(") && ((value instanceof UninitializedInstance));
new-array op looks buggy when determing if it's local. input smali should override framework.
LocalTypes should not need to contain what kind of type they are?
test aput for non-Number values, e.g. boolean and character into an int array, but see if dalvik handles it properly first
simple test
throw an exception and catch it
inheritence test
throw a child exception and see if caught by exception parent
complex inheritence
throw a child exception, catch parent and grandparent and make sure parent handles
finally test
simple value set + test
unhandled exception + finally test
throw exception but make sure finally value set
handled exception + finally test
throw exception, handle it, make sure finally value set
consider unit testing
exceptionhandlerresolver - build unit with public method to resolve addresses given an
exception
current address
try catch blocks
catch unhandled virtual exceptions in invokeop
set THOSE as the exceptions, clear children, return
make notes saying that just because eomething is unhandled doesn't mean if there's an actual context for a method instead of just starting it at the root then it might be a handled exception