+++ /dev/null
-#+OPTIONS: html-link-use-abs-url:nil html-postamble:auto
-#+OPTIONS: html-preamble:t html-scripts:t html-style:t
-#+OPTIONS: html5-fancy:nil tex:t toc:2
-#+CREATOR: <a href="http://www.gnu.org/software/emacs/">Emacs</a> 24.4.1 (<a href="http://orgmode.org">Org</a> mode 8.2.10)
-#+HTML_CONTAINER: div
-#+HTML_DOCTYPE: xhtml-strict
-#+HTML_HEAD:
-#+HTML_HEAD_EXTRA:
-#+HTML_LINK_HOME:
-#+HTML_LINK_UP:
-#+HTML_MATHJAX:
-#+INFOJS_OPT:
-#+LATEX_HEADER:
-
-* Doable
-** robust binary support
-*** TODO understanding _start
-
- If we do not have symbols, the only known entry point is _start
- and that does only call a library function. However it has a
- regular structure and one can find the address if main by being
- smart. Unfortunately it's not necessarily possible to do that
- portably so I kind of want to move it out of the core.
-
- http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html
-
-*** TODO finding _start for !ELF
-
- COFF / MacO has an entry point. unfortunately LLVM doesn't
- directly let me access this information so currently it does some
- magic for ELF but not others. Might be possible to find something
- in LLDB which we might want to have long-term anyway to add
- debugging capabilities
-
-*** TODO finding plausible function prologs
-
- Some nice heuristices (implemented as plugins) to get something
- even if we can't properly find function calls.
-
-** serializing
-*** TODO routing data through serializing point
-
- Send all relevant data to some management instance. The management
- instance then notifies all stakeholders of the update. This would
- make sure the resulting state of the system is reproducible from
- the serialized stream and is network-streamable.
-
- One will need to take care of potential performance issues.
-
-*** TODO read/write files
-
- What we actually want is a bag of transactions and a logical
- (semi) order on them. Idea is to mostly store xml in a zip
- container.
-
-*** TODO network stuff
-
- If we can serialize to zip containers we can stream them over the
- network. Idea is to use XMPP as transport, a central instance that
- supplies new participants with all past information and a MUC
- where updates are sent to.
-
- Master/slave setups should be easy. Also normal editing should be
- almost conflict free. Probably needs some locking to not cause
- conflicts when scripts runn over the whole binary and add
- information everywhere.
-
-** graph layouting
-*** TODO special entry (exits?) points
-
- B0 with metainformation about the function. also gives a ⊤ and ⊥
- for the graph which is nice for all kind of algorithms
-
-*** TODO routing edges
-
- Edges skipping on layer of blocks sometimes get through (below)
- other blocks. Fixing that makes the whole thing a complex problem
- while currently it's a set of rather simple heuristics
-
-*** TODO Dominator -> anordnung untereinander falls total dominiert
-
- Currently blocks are ordered by address. Sometimes blocks are
- semantically strictly after another but seen before in the address
- space. Would be visually nicer to have a semantical order so
- backward (upward) edges really only happen in loops
-
-** Scripting
-*** TODO design reasonable API
-
- SWIG? We really want a API that looks native for all supported
- scripting languages and we want a API that is semantically the
- same for all languages
-
-*** TODO python
-
- We have guile implemented and working. Python seems to be highly
- popular so we will want to have it as well some time not to
- distant in the future.
-
-** Non-.text stuff
-*** TODO finding data and strings
-
- identify data types by interpreting the instruction sequence
- referencing a datum. Probably we want to have all instructions
- referencing a address in data segments and do some type narrowing
- based on that. Probably also function calls
-
-** Anotating stuff
-*** TODO notification of annotations to stakeholders
-
-** TODO Configuration stuff
-** Bugfixes
-*** TODO build up instruction analysis for !arm !x86
-*** TODO instruction alignment on RISC
-*** TODO stop on decoding error?
-*** TODO hlt in _start / general
-*** TODO do not create functions for plt entries
-*** TODO blocks not displayed in i4/cip
-
-
-* Advanced
-** Deduce structure
-*** TODO Natural loops
-*** TODO trivial control-flow-split
-** Non-.text stuff
-*** TODO plt stuff and finding API via parsing /usr/include
-
- We already have a C parser (clang) so if we see a call to
- function@plt we can see for potential prototypes for that function
- in /usr/include which would give nice type information for C
- libraries. We also want to display manpage for that function if available
-
-
+++ /dev/null
-* Disassembler Factory
-
-How exactly does that qt plugin stuff work? We probably need some
-factory where all disassemblers can register and we can take one by
-name when opening a binary.
-
-* Data Postprocessing
-** Cleanup Chain
-
-** Anotation Chain
-
-* API plugins
-
-IDA has some nice annotations for all kinds of API functions also
-naming parameters and stuff. We should implement the same leveraging
-some data sources already present.
-
-** MAN plugin
-
-** Info plugin
-
-* File Format
-
-We're going to store transactions in XML files and zip the result
-up. Could be facts (like the region 0xAA to 0xFF is a basic
-block), deletion of such facts or changes to the binary. These facts
-can then be sent over XMPP to implement some multiplayer frida.
-
-Ideally scripting foo would then generate such transactions which are
-stored by some transaction manager and applied to the runnign data
-structure using them as a interface everywhere.
-
-* Decompiler
-
-Do natural loop detection, build some (lispy?) intermediate code and
-"optimize" sideeffects (like flags) away from instructions where not
-needed. Then reverse-apply fancy arithmetic tricks and format it as
-normal C code.
--- /dev/null
+#+OPTIONS: html-link-use-abs-url:nil html-postamble:auto
+#+OPTIONS: html-preamble:t html-scripts:t html-style:t
+#+OPTIONS: html5-fancy:nil tex:t toc:2
+#+CREATOR: <a href="http://www.gnu.org/software/emacs/">Emacs</a> 24.4.1 (<a href="http://orgmode.org">Org</a> mode 8.2.10)
+#+HTML_CONTAINER: div
+#+HTML_DOCTYPE: xhtml-strict
+#+HTML_HEAD:
+#+HTML_HEAD_EXTRA:
+#+HTML_LINK_HOME:
+#+HTML_LINK_UP:
+#+HTML_MATHJAX:
+#+INFOJS_OPT:
+#+LATEX_HEADER:
+
+* Doable
+** robust binary support
+*** TODO understanding _start
+
+ If we do not have symbols, the only known entry point is _start
+ and that does only call a library function. However it has a
+ regular structure and one can find the address if main by being
+ smart. Unfortunately it's not necessarily possible to do that
+ portably so I kind of want to move it out of the core.
+
+ http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html
+
+*** TODO finding _start for !ELF
+
+ COFF / MacO has an entry point. unfortunately LLVM doesn't
+ directly let me access this information so currently it does some
+ magic for ELF but not others. Might be possible to find something
+ in LLDB which we might want to have long-term anyway to add
+ debugging capabilities
+
+*** TODO finding plausible function prologs
+
+ Some nice heuristices (implemented as plugins) to get something
+ even if we can't properly find function calls.
+
+** serializing
+*** TODO routing data through serializing point
+
+ Send all relevant data to some management instance. The management
+ instance then notifies all stakeholders of the update. This would
+ make sure the resulting state of the system is reproducible from
+ the serialized stream and is network-streamable.
+
+ One will need to take care of potential performance issues.
+
+*** TODO read/write files
+
+ What we actually want is a bag of transactions and a logical
+ (semi) order on them. Idea is to mostly store xml in a zip
+ container.
+
+*** TODO network stuff
+
+ If we can serialize to zip containers we can stream them over the
+ network. Idea is to use XMPP as transport, a central instance that
+ supplies new participants with all past information and a MUC
+ where updates are sent to.
+
+ Master/slave setups should be easy. Also normal editing should be
+ almost conflict free. Probably needs some locking to not cause
+ conflicts when scripts runn over the whole binary and add
+ information everywhere.
+
+** graph layouting
+*** TODO special entry (exits?) points
+
+ B0 with metainformation about the function. also gives a ⊤ and ⊥
+ for the graph which is nice for all kind of algorithms
+
+*** TODO routing edges
+
+ Edges skipping on layer of blocks sometimes get through (below)
+ other blocks. Fixing that makes the whole thing a complex problem
+ while currently it's a set of rather simple heuristics
+
+*** TODO Dominator -> anordnung untereinander falls total dominiert
+
+ Currently blocks are ordered by address. Sometimes blocks are
+ semantically strictly after another but seen before in the address
+ space. Would be visually nicer to have a semantical order so
+ backward (upward) edges really only happen in loops
+
+** Scripting
+*** TODO design reasonable API
+
+ SWIG? We really want a API that looks native for all supported
+ scripting languages and we want a API that is semantically the
+ same for all languages
+
+*** TODO python
+
+ We have guile implemented and working. Python seems to be highly
+ popular so we will want to have it as well some time not to
+ distant in the future.
+
+** Non-.text stuff
+*** TODO finding data and strings
+
+ identify data types by interpreting the instruction sequence
+ referencing a datum. Probably we want to have all instructions
+ referencing a address in data segments and do some type narrowing
+ based on that. Probably also function calls
+
+** Anotating stuff
+*** TODO notification of annotations to stakeholders
+
+** TODO Configuration stuff
+** Bugfixes
+*** TODO build up instruction analysis for !arm !x86
+*** TODO instruction alignment on RISC
+*** TODO stop on decoding error?
+*** TODO hlt in _start / general
+*** TODO do not create functions for plt entries
+*** TODO blocks not displayed in i4/cip
+
+
+* Advanced
+** Deduce structure
+*** TODO Natural loops
+*** TODO trivial control-flow-split
+** Non-.text stuff
+*** TODO plt stuff and finding API via parsing /usr/include
+
+ We already have a C parser (clang) so if we see a call to
+ function@plt we can see for potential prototypes for that function
+ in /usr/include which would give nice type information for C
+ libraries. We also want to display manpage for that function if available
+
+
--- /dev/null
+* Disassembler Factory
+
+How exactly does that qt plugin stuff work? We probably need some
+factory where all disassemblers can register and we can take one by
+name when opening a binary.
+
+* Data Postprocessing
+** Cleanup Chain
+
+** Anotation Chain
+
+* API plugins
+
+IDA has some nice annotations for all kinds of API functions also
+naming parameters and stuff. We should implement the same leveraging
+some data sources already present.
+
+** MAN plugin
+
+** Info plugin
+
+* File Format
+
+We're going to store transactions in XML files and zip the result
+up. Could be facts (like the region 0xAA to 0xFF is a basic
+block), deletion of such facts or changes to the binary. These facts
+can then be sent over XMPP to implement some multiplayer frida.
+
+Ideally scripting foo would then generate such transactions which are
+stored by some transaction manager and applied to the runnign data
+structure using them as a interface everywhere.
+
+* Decompiler
+
+Do natural loop detection, build some (lispy?) intermediate code and
+"optimize" sideeffects (like flags) away from instructions where not
+needed. Then reverse-apply fancy arithmetic tricks and format it as
+normal C code.
projects / frida / frida.git / commitdiff