-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
137 lines (103 loc) · 3.14 KB
/
README
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 reversing platform for bsd/linux x86
it takes inspiration from secdev's python ptrace tool and vtrace and PAIMEI
libdasm + pydasm from nologin.org kicks ass
MAJOR TODO:
-> use secdevs ptrace interface, its much nicer
(could simplify it though)
TODO:
merge x86 helper functions and target interface: status =almost complete
halting problem
Features:
. hit trace debugging
. more useful disassembly
. major c++ features
. vtti
Dwarf
OS X support
Goals:
-> be resilient to failure and true to execution. gdb, ltrace fail on stripped binaries,
they depend on section headers + symbol information (which are independent of
data+execution)
most tools fail miserably with corrupted shdr information
...
-> Allow for flexible, interactive annotations
-> Allow active reversing from opcodez -> C
Contributions Wanted:
-> GUI
... annotations
... pretty graphs
-> user config for colors
-> scripting interface for annotating functions and code patterns
(IL representation may be needed)
------------
Code guidelines
target.py
-> abstracted interface for dealing with binary formats and
architectures
elf.py
-> everything ELF related
platform specific ELF things go in here as well (and may be messy)
keep code related stuff out of here, this is just for the file format
x86.py
-> lower level implementations for x86
:: finding functions
:: making graphs
:: disassembling
:: resolving extended info
(the format itself should do most of symbols)
breakpoints.py
-> abstracted interface for dealing with debugging information
things to fully support on each architecture
1) Breakpoints
hardware (debug registers) and software (int3s)
single-stepping [if supported]
2) Reading/Writing to another processes' memory space
3) Hooks
Support for hooking the entry and exit points
of routines or specified memory addresses.
platforms.py
platform implementations of things
-> breakpoints.py support
-> ?
trace.py
-> use the above functionality to trace a process
(and fuzz input / monitor code coverage/ or whatever the goal may be)
main.py
-> does some stuff
-----------------------------------
A Target() should implement the following
data
.segments list of memory segments
.mem sliceabley accessible memory (read-only for a file, rw for a running proc)
.functions list of function code blocks
.blocks XXX
.imports XXX list of imported functions (from libraries, etc)
.exports XXX list of exported functions
.symbols XXX list of all symbols
.format XX binary format of the target
add_func(addr)
has_func(addr)
find_func(addr)
find_functions() scan for all functions
resolve_symbols() use resolver info/debugging data to find symbols
disas(addr, sz=0) dump code starting at memory address until a reasonable end or specified end
dump_symbols() XXX
dump_code() display all code to stdout, make it pretty and useful if possible
-=-=-
Active targets
mem[] array is writeable :: XXX todo
TESTING TODO: DONE , seems to work
FreeBSD
attach()
detach()
start()
end()
cont()
stop()
read()
write()
getregs()
setregs()
getpc()
setpc()
get_events()