gitoleg on master
tweaks the print plugin The pr… fixes a bug in adt printer (whi… (compare)
Hi, I have a question about Words. I created a word with width 3 from an int -2, casted it to signed, then converted it to an int. In 1.6 I would get -2, but in 2.0 I would get 6. Why does this happen?
utop # let n_two = Word.of_int (-2) ~width:3;; val n_two : word = <abstr> utop # n_two |> Word.signed |> Word.to_int_exn;; - : int = -2
utop # let n_two = Word.of_int (-2) ~width:3;; val n_two : word = <abstr> utop # n_two |> Word.signed |> Word.to_int_exn;; - : int = 6
Hello, and congrats on releasing BAP 2! I'm new to BAP and reading through the docs. My question - the existing BAR docs (annotated reference) are still 1.6, right? Are there any docs for 2.0 out already or is it still WIP?
We didn't upload 2.0 docs yet, and they are still WIP. With all that said, BAP 1.6 is subsumed by BAP 2.0, so everything that is said in the currently uploaded documentation is still valid for the latest release.
llvm-configtool available in your path, so that BAP can find LLVM.
@fortunac, please see the #983 it should restore the old behavior of the
Word.to_intX functions, they will now extend the sign bit if the passed value is marked as unsigned (a previously undocumented feature).
However, I would advise against relying on fragile native integers. The mere fact that your code depends on the fact that
-2 is very suspicious. If you need arithmetics then you should use
Word module for that everywhere. I don't think, that there is a need (or legit use cases) for translating a bitvector to the host integer, especially if such use cases depend on the sign (so that you end up treating 110 differently in different contexts). The word data type is indexable, comparable, printable, efficient, etc.
f:('d -> 'n -> 'e -> 'd)), then you have to compute the node transition either for each incoming edge or for each outgoing edge. Both would be inefficient for graphs with lots of edges. Am I missing something here?
let transfer data node = let data = compute_genkill node data in fun _edge -> data
transferfunction has type
'd -> Node.t -> Edge.label -> 'dbut the heavy
compute_genkillis called only once per block.
So a user may explicitly tell whether his transfer function depends on a node, an edge, or both.
[ | `node of Node.t -> 'd -> 'd | `edge of Edge.label -> 'd -> 'd | `both of Node.t -> Edge.label -> 'd -> 'd ]
Something like this
type ('n,'e,'d) transmittance val transfer_identity : (_,_,_) transmittance val transfer_node : ('n -> 'd -> 'd) -> ('n,_,'d) transmittance val transfer_edge : ('e -> 'd -> 'd) -> ('_,'e,'d) transmittance val transfer : ('n -> 'e -> 'd -> 'd) -> ('n,'e,'d) transmittance (* and the following type of `Solution.compute` *) module Solution : sig ... val compute : (module Graph with type t = 'c and type node = 'n and type Edge.label = 'e) -> ?steps:int -> ?start:'n -> ?rev:bool -> ?step:(int -> 'n -> 'd -> 'd -> 'd) -> init:('n,'d) Fixpoint.t -> equal:('d -> 'd -> bool) -> merge:('d -> 'd -> 'd) -> f:('n,'e,'d) transmittance -> 'c -> ('n,'d) Fixpoint.t end
in fact, we can even make
f optional and default it to
for that case we can add a yet another variant... can't come up with a proper name right now, but something like this:
implementation (underneath the hood the transmittance type is a simple GADT)
type (_,_,_) transmittance = | Identity : ('n,'e,'d) transmittance | ... | Distributive : ('n -> 'd -> 's) * ('e -> 's -> 'd) -> ('n,'e,'d) transmittance | General : ('n -> 'e -> d -> 'd) -> ('n,'e,'d) transmittance
Note, that for the distributive case we have an existential
's type representing the partially computed result from the node only (this could be the
'd of course)
apply_transmittancefunction in the implementation, that will just dispatch the user-provided transmittance. A very minimal change. The good thing is that we will also get a concrete notion of the transmittance where we can explain all cons and pros of different variants)
I expect most cases to be distributive. And the ones that are not can probably be handled by transforming the input graph.
Well, the whole point is that in case of a non-distributive version it could not be solved by transferring the graph, this is the why the problem is non-distributive, i.e., in that case your transfer function could not be expressed in terms of one node. That's why we need to support the general case.
By the way: Are you still interested in a minimal and backwards-compatible version now or do you want to wait until I get around writing a more powerful one?
I'm thinking of the solution with different transmittances as the minimal and backward-compatible (provided that we will put the new function in the Solution namespace, and left the old one for backward compatibility (marking as deprecated)).
vagrant@ubuntu-bionic:~ opam depext bap # Detecting depexts using vars: arch=x86_64, os=linux, os-distribution=ubuntu, os-family=debian # The following system packages are needed: binutils-multiarch clang debianutils libgmp-dev libzip-dev llvm-6.0-dev m4 perl pkg-config zlib1g-dev The following command needs to be run through "sudo": apt-get install binutils-multiarch clang debianutils libgmp-dev libzip-dev llvm-6.0-dev m4 perl pkg-config zlib1g-dev
So it's quite weird that in your case
opam depext bap suggests you to install
llvm-3.8. So first things first, to be sure that we're on the same page, let's do the following:
and make sure that
opam --version is 2.0 or later
LLVM_CONFIG=llvm-config-8 opam install conf-bap-llvmand then
opam depext bapand
opam install bap
I want translate to BIL by asm(x86, arm, ...) on IDAPython script, or is there any other way? Thank very much.
I'm not sure I understand what do you want, but you definitely don't need a loader for that :)