]> git.siccegge.de Git - frida/web.git/blob - src/todo.txt
somewhat improve css
[frida/web.git] / src / todo.txt
1 restindex
2 page-title: TODO
3 include: yes
4 /restindex
5
6 Doable
7 ======
8
9 robust binary support
10 ~~~~~~~~~~~~~~~~~~~~~
11
12 TODO understanding _start
13 -------------------------
14
15 If we do not have symbols, the only known entry point is _start and
16 that does only call a library function. However it has a regular
17 structure and one can find the address if main by being
18 smart. Unfortunately it's not necessarily possible to do that portably
19 so I kind of want to move it out of the core.
20
21 [http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html]
22
23
24 TODO finding _start for !ELF
25 ----------------------------
26
27 COFF / MacO has an entry point. unfortunately LLVM doesn't directly
28 let me access this information so currently it does some magic for ELF
29 but not others. Might be possible to find something in LLDB which we
30 might want to have long-term anyway to add debugging capabilities
31
32
33 TODO finding plausible function prologs
34 ---------------------------------------
35
36 Some nice heuristices (implemented as plugins) to get something even
37 if we can't properly find function calls.
38
39
40 serializing
41 ~~~~~~~~~~~
42
43 TODO routing data through serializing point
44 -------------------------------------------
45
46 Send all relevant data to some management instance. The management
47 instance then notifies all stakeholders of the update. This would make
48 sure the resulting state of the system is reproducible from the
49 serialized stream and is network-streamable.
50
51 One will need to take care of potential performance issues.
52
53
54 TODO read/write files
55 ---------------------
56
57 What we actually want is a bag of transactions and a logical (semi)
58 order on them. Idea is to mostly store xml in a zip container.
59
60
61 TODO network stuff
62 ------------------
63
64 If we can serialize to zip containers we can stream them over the
65 network. Idea is to use XMPP as transport, a central instance that
66 supplies new participants with all past information and a MUC where
67 updates are sent to.
68
69 Master/slave setups should be easy. Also normal editing should be
70 almost conflict free. Probably needs some locking to not cause
71 conflicts when scripts runn over the whole binary and add information
72 everywhere.
73
74
75 graph layouting
76 ~~~~~~~~~~~~~~~
77
78 TODO special entry (exits?) points
79 ----------------------------------
80
81 B0 with metainformation about the function. also gives a ⊤ and ⊥ for
82 the graph which is nice for all kind of algorithms
83
84
85 TODO routing edges
86 ------------------
87
88 Edges skipping on layer of blocks sometimes get through (below) other
89 blocks. Fixing that makes the whole thing a complex problem while
90 currently it's a set of rather simple heuristics
91
92
93 TODO Dominator -> anordnung untereinander falls total dominiert
94 ---------------------------------------------------------------
95
96 Currently blocks are ordered by address. Sometimes blocks are
97 semantically strictly after another but seen before in the address
98 space. Would be visually nicer to have a semantical order so backward
99 (upward) edges really only happen in loops
100
101
102 Scripting
103 ~~~~~~~~~
104
105 TODO design reasonable API
106 --------------------------
107
108 SWIG? We really want a API that looks native for all supported
109 scripting languages and we want a API that is semantically the same
110 for all languages
111
112
113 TODO python
114 -----------
115
116 We have guile implemented and working. Python seems to be highly
117 popular so we will want to have it as well some time not to distant in
118 the future.
119
120
121 Non-.text stuff
122 ~~~~~~~~~~~~~~~
123
124 TODO finding data and strings
125 -----------------------------
126
127 identify data types by interpreting the instruction sequence
128 referencing a datum. Probably we want to have all instructions
129 referencing a address in data segments and do some type narrowing
130 based on that. Probably also function calls
131
132
133 Anotating stuff
134 ~~~~~~~~~~~~~~~
135
136 TODO notification of annotations to stakeholders
137 ------------------------------------------------
138
139
140 TODO Configuration stuff
141 ~~~~~~~~~~~~~~~~~~~~~~~~
142
143
144 Bugfixes
145 ~~~~~~~~
146
147 TODO build up instruction analysis for !arm !x86
148 ------------------------------------------------
149
150
151 TODO instruction alignment on RISC
152 ----------------------------------
153
154
155 TODO stop on decoding error?
156 ----------------------------
157
158
159 TODO hlt in _start / general
160 ----------------------------
161
162
163 TODO do not create functions for plt entries
164 --------------------------------------------
165
166
167 TODO blocks not displayed in i4/cip
168 -----------------------------------
169
170
171 Advanced
172 ========
173
174 Deduce structure
175 ~~~~~~~~~~~~~~~~
176
177 TODO Natural loops
178 ------------------
179
180
181 TODO trivial control-flow-split
182 -------------------------------
183
184
185 Non-.text stuff
186 ~~~~~~~~~~~~~~~
187
188 TODO plt stuff and finding API via parsing /usr/include
189 -------------------------------------------------------
190
191 We already have a C parser (clang) so if we see a call to function@plt
192 we can see for potential prototypes for that function in /usr/include
193 which would give nice type information for C libraries. We also want
194 to display manpage for that function if available