From: Christoph Egger Date: Mon, 12 Oct 2015 15:46:55 +0000 (+0200) Subject: move doc/ out of the way X-Git-Url: https://git.siccegge.de//index.cgi?p=frida%2Ffrida.git;a=commitdiff_plain;h=ccf5cf76644917f2e7ce92753dd9caa02db2a67c move doc/ out of the way --- diff --git a/doc/TODO.org b/doc/TODO.org deleted file mode 100644 index 7fd6a37..0000000 --- a/doc/TODO.org +++ /dev/null @@ -1,133 +0,0 @@ -#+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: Emacs 24.4.1 (Org 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 - - diff --git a/doc/ideas.org b/doc/ideas.org deleted file mode 100644 index 182c26a..0000000 --- a/doc/ideas.org +++ /dev/null @@ -1,38 +0,0 @@ -* 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. diff --git a/old-doc/TODO.org b/old-doc/TODO.org new file mode 100644 index 0000000..7fd6a37 --- /dev/null +++ b/old-doc/TODO.org @@ -0,0 +1,133 @@ +#+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: Emacs 24.4.1 (Org 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 + + diff --git a/old-doc/ideas.org b/old-doc/ideas.org new file mode 100644 index 0000000..182c26a --- /dev/null +++ b/old-doc/ideas.org @@ -0,0 +1,38 @@ +* 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.