octopus-platform / bjoern Goto Github PK

It seems that all the information we need for functions is contained in the JSON output generated by radare.

Call edges currently go from instructions to address nodes. Having additional edges from functions to functions would be nice to obtain a classical call graph.

CFLOW_ALWAYS/CFLOW_TRUE/CFLOW_FALSE edges from the last instruction of a basic block to the first instruction of the next basic block would be nice, as that means an instruction level analysis can stay at that level without going back to the basic block level.

Try to reproduce example queries but it doesn't work :( :

bjoern ‹master›$ bjosh co -q 6002        
Connecting to database 'ls' on port 6002.
 _     _           _
| |__ (_) ___  ___| |__
| '_ \| |/ _ \/ __| '_ \
| |_) | | (_) \__ \ | | |
|_.__// |\___/|___/_| |_|
    |__/     bjoern shell

bjosh> getCallsTo('').map
[ODatabaseException] Database instance is not set in current thread. Assure to set it with: ODatabaseRecordThreadLocal.INSTANCE.set(db);
bjosh> queryNodeIndex('nodeType:Func').repr
[ODatabaseException] Database instance is not set in current thread. Assure to set it with: ODatabaseRecordThreadLocal.INSTANCE.set(db);

Hi,
when merging ml into master and executing gradle clean; gradle deploy, I get the following on a Debian Jessie with Gradle 1.5:

:projects:bjoern-plugins:alocs:jarWithDep FAILED

FAILURE: Build failed with an exception.

* Where:
Build file '/home/fabs/git/bjoern/build.gradle' line: 24

* What went wrong:
Execution failed for task ':projects:bjoern-plugins:alocs:jarWithDep'.
> No signature of method: org.gradle.api.internal.file.AbstractFileCollection$1.asCollection() is applicable for argument types: () values: []

@ml86 : any idea? Seems to me like we might be using a Gradle feature here that's not present in 1.5.

It's not clear to me how there can be unresolvable source nodes of edges when importing the data generated by the current radare exporter. This is probably a bug.

We can spare the user from the hassle of having to compile radare bindings by using r2pipe instead. With r2pipe, we simply communicate with an r2-instance via a pipe via r_core_cmd_str().

See https://github.com/radare/radare2-bindings/tree/master/r2pipe and
https://github.com/radare/radare2-bindings/blob/master/r2pipe/java/org/radare/r2pipe/R2Pipe.java

There is currently no way to prevent Gremlin steps defined in one shell to become visible in all other shells. The reason is that threads share classes, and in particular methods registered dynamically via $Class.metaClass.method. In practice, this means that a user can override steps used by another user.

While it seems to not be easily possible to host per-thread classes, we could at least ensure that users don't overwrite another user's steps by accident. A solution would be to create a catch-all handler for unknown steps, and redirect to functions by that name that are stored in the binding. This would have the nice side-effect that steps are now defined as closures, and thus, groovydoc will recognize them.

Right now, we expect that the user keeps track of the open shells that exist in the server, but it's unrealistic that they will. We should instead provide a listshells server command that can be used to get an overview of the shells currently running with their port, and the database they expose.

It can be useful to return to r2 after performing some queries, something like:

my()
.very_long()
.query()
.go_to_r2()

And it's simply perform s addr in r2 and gives an interactive shell

Java 8 features are used only in a few places. It might be worth considering to replace constructs with equivalent Java 7, in particular since Debian stable doesn't support Java 8 yet.

We eventually want to introduce an actual "root" node that can be used as a starting point to visit all nodes of the graph via hierarchy edges. We should therefore rename "Root nodes" to "Address nodes".

I followed the installation instructions closely and received the below error during "gradle deploy":

System:
OS: Debian Jessie
Gradle: 2.6 (Procedure wasn't clear what version of Gradle, so I went with the same as Joern)
OpenJdk: 1.8.0_162

:projects:bjoern-plugins:alocs:jarWithDep FAILED

FAILURE: Build failed with an exception.

* Where:
Build file '/home/osboxes/Desktop/bjoern/build.gradle' line: 48

* What went wrong:
Execution failed for task ':projects:bjoern-plugins:alocs:jarWithDep'.
> No signature of method: org.gradle.api.internal.file.AbstractFileCollection$1.asCollection() is applicable for argument types: () values: []

When trying to clone from https://github.com/a0x77n/bjoern-shell I get a fatal error. When trying to access this repo in the browser I get a 404 page not found error

We need a Gremlin step to query the lucene fulltext index similar to queryNodeIndex in joern.

It would be nice to have a server command that allows import progress to be monitored. Currently, we simply print a message to the server logs when the import has finished.

I'm just interested in the purposes of IS_ANNOTATED_BY and INTERPRETABLE_AS edges? It's look pretty useless

While following the first step tutorial http://bjoern.readthedocs.io/en/latest/firststeps.html I tried to import a binary using bjoern-import.sh after building successfully. However bjoern-import.sh does not exist. A find search after this file on the folder does not find anything.

The radare exporter currently considers one function at a time to reduce the memory footprint. This leads to situations where we cannot resolve the ids of destination nodes immediately. We write edges affected by this problem to unresolvedEdges.csv, so that they can be added once all nodes are indexed in the database. Code to import unresolvedEdges needs to be added to server.components.orientdbImporter.

One should either state that this project requires a Gradle version below 4.0 so 3.5 or rewrite the build file as with version 4.0 some of the statements used in this build file are now deprecated and throw now an exception instead of just a warning

$ ~/.local/bin/bjoern-import /bin/true
Project created.
File uploaded.
{
  "errors": [{
      "code": 505,
      "reason": 505,
      "content": "java.lang.NoClassDefFoundError: octopus/lib/structures/OctopusNodeProperties"
      }
  ]
}

And processes of radare2 don't close:

$ ps -e
...
109649 ?        00:00:00 radare2
109687 ?        00:00:00 radare2
109741 ?        00:00:01 konsole
109745 pts/1    00:00:00 zsh
109777 ?        00:00:00 radare2
109793 pts/1    00:00:00 ps

It is from my earlier attempts with other binaries

I create a small binary: a.zip for testing some queries.

And in bjosh:

> getCallsTo('c_memcpy')
v[#9:390]
v[#9:391]
> getCallsTo('c_memcpy').map
{repr=call sym.c_memcpy, childNum=12, code=e820000000, comment=, nodeType=Instr, addr=4195679, key=Instr_4195679, esil=rip,8,rsp,-=,rsp,=[],4195716,rip,=}
{repr=call sym.c_memcpy, childNum=, code=, comment=, nodeType=Instr, addr=4195679, key=Instr_4195679, esil=}

And in r2:

> axt sym.c_memcpy
call 0x40055f call sym.c_memcpy in sym.main

Need feature for delete shells because script like bjosh -p 6001 connect cannot (or maybe very long time) connect to shells. Or need use command:

bjosh connect -q 6001