From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 7F8837FB73 for ; Mon, 26 Oct 2015 00:46:46 +0100 (CET) IronPort-PHdr: 9a23:Pnp66hXJ/TN/MLdvUtEZkOP6e9XV8LGtZVwlr6E/grcLSJyIuqrYZhyDt8tkgFKBZ4jH8fUM07OQ6PC9HzRYqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh730o8WbSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t4XXskz4TRaG5zMjW2MZ2k5XCg7K9xHnV5ag6nLSue902S3cNsrzG+MaQzOnuoRmThnllCdPHjIw9Snyi8h0gbgT9BGsoRpy347dbIiQMft6eq7HVdwfTGtFGM1WUnoSUcuHc4ITAr9Zbq5jpI7nqg5L9EPmCA== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=kennethadammiller@gmail.com; spf=Pass smtp.mailfrom=kennethadammiller@gmail.com; spf=None smtp.helo=postmaster@mail-yk0-f176.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.160.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.160.176 as permitted sender) identity=mailfrom; client-ip=209.85.160.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-yk0-f176.google.com) identity=helo; client-ip=209.85.160.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-yk0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BRAACLaS1WlLCgVdFTChaCU4EhYA8GhC2ob5AieAENgVojgkGBYIFZAoETBzgUAQEBAQEBAQEQAQEBAQcLCwkfMIIrggcBAQECAQESER0BGwwLBgEDAQsGBQsNIAoCAiEBAREBBQEcBhMJEgEGh3gBAwoIDaQWgTE+MYtJgWyCeYdbChknDVaEAAEBAQEBBQEBAQEBAQEBARQBBQ6EQIIqg3eBBoJQgWBZBAeCaYFFBZJig1SFHIJwgyGBdYFZhD+DJIskg1+CJBIjgRcRDgEBgkYjgXgiNAEBAQGHFAEBAQ X-IPAS-Result: A0BRAACLaS1WlLCgVdFTChaCU4EhYA8GhC2ob5AieAENgVojgkGBYIFZAoETBzgUAQEBAQEBAQEQAQEBAQcLCwkfMIIrggcBAQECAQESER0BGwwLBgEDAQsGBQsNIAoCAiEBAREBBQEcBhMJEgEGh3gBAwoIDaQWgTE+MYtJgWyCeYdbChknDVaEAAEBAQEBBQEBAQEBAQEBARQBBQ6EQIIqg3eBBoJQgWBZBAeCaYFFBZJig1SFHIJwgyGBdYFZhD+DJIskg1+CJBIjgRcRDgEBgkYjgXgiNAEBAQGHFAEBAQ X-IronPort-AV: E=Sophos;i="5.20,198,1444687200"; d="scan'208";a="151712255" Received: from mail-yk0-f176.google.com ([209.85.160.176]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 26 Oct 2015 00:46:40 +0100 Received: by yknn9 with SMTP id n9so168031606ykn.0 for ; Sun, 25 Oct 2015 16:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Awg7SD5X9/h+e2C97C1weM7mZ/RgkikvYhVH/+81LbQ=; b=HZ3hrRPr/p81XSIHGhmZJAjxOXW453I+GmSvAQy0Q2onbC9L7+u36b2AxFJar2HF/U Y+9udfUDOft7WzcS4M/JIeEhYvS9MzUvvqttly0uMNd0pew/BhX9UKJlz5thCGyB1x8f bz/xWVDNHeg26kAKnOpu7IZfl4/3CjKUijwFIj722vCm5CUOtQTaEkfpjXbkiaeo6bvs mvSC/OuoH+m/5o3mdfwcgNkg6wV/TaWjKaWzrThOjMTdLEQr8hDXFv6+z273uDPoDRWi N1WsWo9MYbhUrXD85JCZT278bghXF0P3wI0EtGwbaz7qeYLjN4emhE/xWMxbVdipfvV6 kZYg== MIME-Version: 1.0 X-Received: by 10.13.248.66 with SMTP id i63mr11855830ywf.272.1445816799711; Sun, 25 Oct 2015 16:46:39 -0700 (PDT) Received: by 10.37.65.143 with HTTP; Sun, 25 Oct 2015 16:46:39 -0700 (PDT) Received: by 10.37.65.143 with HTTP; Sun, 25 Oct 2015 16:46:39 -0700 (PDT) In-Reply-To: References: Date: Sun, 25 Oct 2015 19:46:39 -0400 Message-ID: From: Kenneth Adam Miller To: Shuai Wang Cc: caml users Content-Type: multipart/alternative; boundary=94eb2c07ee98c1f1c50522f67418 Subject: Re: [Caml-list] [ANN] Uroboros 0.1 --94eb2c07ee98c1f1c50522f67418 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No, that's right, but I was making a distinguishment in the two techniques, and I originally only mentioned stir because that and its companion papers is where the technique of retaining the original code region made its debut. Thanks I hadn't heard about dyn inst. On Oct 25, 2015 7:11 PM, "Shuai Wang" wrote: > I though "STIR" refers to Binary Stirring [1]. > > Leveraging coq to verify the instrumentation correctness sounds > very interesting to me, although I am not aware of any existing related > work. > Do you any existing work? > > I think there do exist some static rewriter, such as DynInst. > > [1] Binary Stirring: http://www.utdallas.edu/~hamlen/wartell12ccs.pdf > [2] DynInst : http://www.dyninst.org/ > > > > On Sun, Oct 25, 2015 at 5:23 PM, Kenneth Adam Miller < > kennethadammiller@gmail.com> wrote: > >> I'm quite sure we are thinking of different things. >> >> STIR is a binary randomization technique used to mitigate rop, and was >> developed in sitsu with the binary rewriting techniques. The technique of >> retaining the original code section is a failback to guard against errors >> in rewriting, but to my knowledge doesn't impose a performance penalty. >> Size required is a constant multiple, so I don't consider it an adoption >> hurdle. But everybody has different use scenarios. >> >> Right. Correctness is critical. I think co program proof methodologies >> with tools like coq will shine here in proofs to remove required trust t= hat >> a rewrtten binary is conformant to certain execution properties. >> >> I hadn't know static rewriters even existed. I presume you are you >> talking about dynamic tools. >> On Oct 25, 2015 4:49 PM, "Shuai Wang" wrote: >> >>> Hello Kenneth, >>> >>> Yes, I agree Binary Stirring system can eliminate symbolization false >>> positive as well. Actually I believe >>> many research work, and tools (DynInst, for instance) have implemented >>> this a so-called "replica-based" >>> binary instrumentation framework. This is a quite robust way to >>> instrument binary code, although size expansion and >>> performance penalty cannot be ignored in the instrumentation outputs. >>> >>> However, I found those solutions are all quite complex, and difficult to >>> understand. And it might not be inaccurate >>> to assume "aggressive" instrumentation methods can break the >>> functionality due to the limitation of design, >>> or challenges in bug-less implementation. I even found that some >>> the-state-of-the-art binary instrumentation tools >>> cannot preserve the correct functionality when employing them to >>> instrument some SPEC2006 test cases. >>> >>> I personally would like to find some cleaner solutions, which can >>> introduce very little overhead in terms of binary >>> size and execution. Besides, some research work reveals that binary >>> security applications built on top of previous >>> instrumentation framework do leave certain exploitable vulnerabilities >>> due to the design limitations. >>> >>> Sincerely, >>> Shuai >>> >>> >>> >>> >>> >>> >>> On Sun, Oct 25, 2015 at 3:25 PM, Kenneth Adam Miller < >>> kennethadammiller@gmail.com> wrote: >>> >>>> Replied inline >>>> >>>> On Sun, Oct 25, 2015 at 3:04 PM, Shuai Wang >>>> wrote: >>>> >>>>> Hello Kenneth, >>>>> >>>>> Sorry for the late reply. I have several deadlines during this >>>>> weekend. >>>>> >>>>> To answer your question, our current approach cannot ensure 100% >>>>> "reposition" correct. >>>>> The most challenging part is to identify code pointers in global data >>>>> sections, as we discussed >>>>> in our paper, it is quite difficult to handle even with some static >>>>> analysis techniques >>>>> (type inference, for instance). We do have some false positive, as >>>>> shown in the appendix of our paper [1]. >>>>> We will research more to eliminate the false positive. >>>>> >>>>> I believe it is doable to present a sound solution. It indeed requires >>>>> some additional >>>>> trampolines inserted in the binary code. You may refer to this paper >>>>> for some enlightens [2]. >>>>> >>>>> As for the disassembling challenges, we directly adopt a disassembly >>>>> approach proposed >>>>> by an excellent work [3]. You can check out their evaluation section, >>>>> and find that their approach >>>>> can correctly disassemble large-size applications without any error. >>>>> My experience is that Linux ELF >>>>> binaries are indeed easier to disassemble, and typical compilers (gcc; >>>>> icc; llvm) would not >>>>> insert data into code sections (the embedded data can trouble linear >>>>> disassembler a lot). >>>>> >>>>> >>>> I remember reading about [3] when it came out. That was a year after >>>> the original REINS system came out that proposed re-writing binaries, = along >>>> with it's companion STIR. Shingled disassembly originated with Wartell= et >>>> al.'s seminal Distinguishing Code and Data PhD thesis. I'm currently >>>> working on the integration of a sheering and PFSM enhanced Shingled >>>> Disassembler into BAP. But if you've already implemented something like >>>> that, what would be really valuable is if you were to review my shingl= ed >>>> disassembler implementation and I review yours that way we have some c= ross >>>> review feedback. >>>> >>>> Regarding the need for 100% accuracy, in the REINS and STIR papers, the >>>> approach taken is to obtain very very high classification accuracy, bu= t in >>>> the case that correctness cannot be established, to simply retain each >>>> interpretation of a byte sequence, so you are still correct in the ins= tance >>>> that it's code by treating it as such. Then, a companion technique is >>>> introduced wherein the code section is retained in order that should s= uch a >>>> data reference in code instance occur and interpretation was incorrect, >>>> such reference can read and write into the kept section. But if it's c= ode, >>>> it has been rewritten in the new section. Then it should remain correc= t in >>>> any scenario. >>>> >>>> >>>>> However, if I am asked to work on PE binaries, then I will probably >>>>> start from IDA-Pro. >>>>> We consider the disassembling challenge is orthogonal to our research. >>>>> >>>> >>>> It is good to have good interoperabiblity with IDA as a guided >>>> disassembler and the actual new research tools. One of the most valuab= le >>>> things I can think of is to write some plugin that will mechanize data >>>> extraction as needed in order to accelerate manual intervention with t= he >>>> newer tools, such as in the case of training. >>>> >>>> >>>>> >>>>> IMHO, our research reveals the (important) fact that even though >>>>> theoretically relocation issue >>>>> is hard to solve with 100% accuracy, it might not be as troublesome as >>>>> it was assumed by previous work. >>>>> Simple solutions can achieve good results. >>>>> >>>> >>>> Agreed; there are failback stratagems. >>>> >>>> >>>>> >>>>> I hope it answers your questions, otherwise, please let me know :) >>>>> >>>>> Best, >>>>> Shuai >>>>> >>>>> [1] Shuai Wang, Pei Wang, Dinghao Wu, Reassembleable Disassembling. >>>>> [2] Zhui Deng, Xiangyu Zhang, Dongyan Xu, BISTRO: Binary Component >>>>> Extraction and Embedding for Software Security Applications >>>>> [3] Mingwei Zhang, Sekar, R, Control Flow Integrity for COTS Binaries. >>>>> >>>>> >>>>> >>>> There's a good utility for working with white papers and interacting >>>> with colleagues; mendeley. >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Oct 23, 2015 at 6:31 PM, Kenneth Adam Miller < >>>>> kennethadammiller@gmail.com> wrote: >>>>> >>>>>> Well it's interesting that you've gone with a binary recompilation >>>>>> approach. How do you ensure that, statically, for any given edit, you >>>>>> reposition all the jump targets correctly? How do you deal with the >>>>>> difficulty of disassembly reducing to the halting problem? >>>>>> >>>>>> On Fri, Oct 23, 2015 at 4:59 PM, Shuai Wang >>>>>> wrote: >>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> I am glad that you are interested in our work!! >>>>>>> >>>>>>> Actually this project starts over 1.5 years ago, and I believe at >>>>>>> that time, BAP (version 0.7 I believe?) is still a research prototy= pe.. >>>>>>> >>>>>>> I choose to implement from the stretch is because I want to have a >>>>>>> nice tool for my own research projects, also I can have an opportun= ity >>>>>>> to learn OCaml... :) >>>>>>> >>>>>>> Yes, I definitely would like to unite our efforts!! >>>>>>> >>>>>>> Best, >>>>>>> Shuai >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Oct 23, 2015 at 1:30 PM, Ivan Gotovchits >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Shuai, >>>>>>>> >>>>>>>> Nice work! But I'm curious, why didn't you use [bap][1] as a >>>>>>>> disassembler? >>>>>>>> >>>>>>>> Do you know, that we have a low-level interface to disassembling, >>>>>>>> like [linear_sweep][2] or even >>>>>>>> lower [Disasm_expert.Basic][3] interface, that can disassemble on >>>>>>>> instruction level granularity. >>>>>>>> >>>>>>>> It will be very interesting, if we can unite our efforts. >>>>>>>> >>>>>>>> Best wishes, >>>>>>>> Ivan Gotovchits >>>>>>>> >>>>>>>> [1]: https://github.com/BinaryAnalysisPlatform/bap >>>>>>>> [2]: >>>>>>>> http://binaryanalysisplatform.github.io/bap/api/master/Bap.Std.htm= l#VALlinear_sweep >>>>>>>> [3]: >>>>>>>> http://binaryanalysisplatform.github.io/bap/api/master/Bap.Std.Dis= asm_expert.Basic.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Oct 23, 2015 at 1:05 PM, Shuai Wang >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Dear List, >>>>>>>>> >>>>>>>>> I=E2=80=99m glad to announce the first release of Uroboros: an i= nfrastructure >>>>>>>>> for reassembleable disassembling and transformation. >>>>>>>>> >>>>>>>>> You can find the code here: https://github.com/s3team/uroboros >>>>>>>>> You can find our research paper which describes the core technique >>>>>>>>> implemented in Uroboros here: >>>>>>>>> >>>>>>>>> https://www.usenix.org/system/files/conference/usenixsecurity15/s= ec15-paper-wang-shuai.pdf >>>>>>>>> >>>>>>>>> We will provide a project home page, as well as more detailed >>>>>>>>> documents in the near future. Issues and pull requests welcomed. >>>>>>>>> >>>>>>>>> Happy hacking! >>>>>>>>> >>>>>>>>> Sincerely, >>>>>>>>> Shuai >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > --94eb2c07ee98c1f1c50522f67418 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

No, that's right, but I was making a distinguishment in = the two techniques, and I originally only mentioned stir because that and i= ts companion papers is where the technique of retaining the original code r= egion made its debut.

Thanks I hadn't heard about dyn inst.

On Oct 25, 2015 7:11 PM, "Shuai Wang" = <wangshuai901@gmail.com>= ; wrote:
I though "STIR" refers to Binary Stirring [1].

Leveraging coq to verify the instrumentation correctness sounds=C2= =A0
very interesting to me, although I am not aware of any existi= ng related work.
Do you any existing work?

I think there do exist some static rewriter, such as DynInst.
=
[2] DynInst :=C2=A0http://www.dyninst.org/



On Sun, Oct 25, 2015 at 5:23 PM, Kenneth Adam Miller <ke= nnethadammiller@gmail.com> wrote:

I'm quite sure we are thinking of different thing= s.

STIR is a binary randomization technique used to mitigate ro= p, and was developed in sitsu with the binary rewriting techniques. The tec= hnique of retaining the original code section is a failback to guard agains= t errors in rewriting, but to my knowledge doesn't impose a performance= penalty. Size required is a constant multiple, so I don't consider it = an adoption hurdle. But everybody has different use scenarios.

Right. Correctness is critical. I think co program proof met= hodologies with tools like coq will shine here in proofs to remove required= trust that a rewrtten binary is conformant to certain execution properties= .

I hadn't know static rewriters even existed. I presume y= ou are you talking about dynamic tools.

On Oct 25, 2015 4:49 PM, "Shuai Wang" = <wangshuai90= 1@gmail.com> wrote:
Hello Kenneth,

Yes, I agree Bina= ry Stirring system can eliminate symbolization false positive=C2=A0as well.= Actually I believe=C2=A0
many research work, and =C2=A0tools (Dy= nInst, for instance) have implemented this a so-called "replica-based&= quot;=C2=A0
binary instrumentation framework. This is a quite rob= ust way to instrument=C2=A0binary code, although size expansion and=C2=A0
performance penalty cannot be ignored in the instrumentation outpu= ts. =C2=A0

However, I found those solutions are al= l quite complex, and difficult to understand. And it might not be inaccurat= e=C2=A0
to assume "aggressive" instrumentation methods = can break the functionality due to the limitation of design,=C2=A0
or challenges in bug-less implementation. I even found that some the-stat= e-of-the-art binary instrumentation tools=C2=A0
cannot preserve t= he correct functionality when employing them to instrument some SPEC2006 te= st cases.=C2=A0

I personally would like to find so= me cleaner solutions, which can introduce very little overhead in terms of = binary=C2=A0
size and execution. Besides, some research work reve= als that binary security applications built on top of previous=C2=A0
<= div>instrumentation framework do leave certain exploitable vulnerabilities = due to the design limitations.=C2=A0

Sincerely,
Shuai






On Sun, Oct 25, 2015 at 3:25 PM, Kenneth Adam Miller <ke= nnethadammiller@gmail.com> wrote:
Replied inline

On Sun, Oct 25, 2015 at 3:04 PM, Shuai Wang <wangshuai901@gmail.com> wrote:
Hello Kenneth,

Sorry for the lat= e reply. I have several deadlines during this weekend.=C2=A0

=
To answer your question, our current approach cannot ensure 100%= "reposition" correct.=C2=A0
The most challenging part = is to identify code pointers in global data sections, as we discussed=C2=A0=
in our paper, it is quite difficult to handle even with some sta= tic analysis techniques=C2=A0
(type inference, for instance). We = do have some false positive, as shown in the appendix of our paper [1].=C2= =A0
We will research more to eliminate the false positive.=C2=A0<= /div>

I believe it is doable to present a sound solution= . It indeed requires some additional
trampolines inserted in the = binary code. You may refer to this paper for some enlightens [2].=C2=A0
=C2=A0
As for the disassembling challenges, we directly ad= opt a disassembly approach proposed=C2=A0
by an excellent wor= k [3]. You can check out their evaluation section, and find that their appr= oach=C2=A0
can correctly disassemble large-size applications with= out any error. My experience is that Linux ELF=C2=A0
binaries are= indeed easier to disassemble, and typical compilers (gcc; icc; llvm) would= not=C2=A0
insert data into code sections (the embedded data can = trouble linear disassembler a lot).=C2=A0


I remember reading about [3] when it came = out. That was a year after the original REINS system came out that proposed= re-writing binaries, along with it's companion STIR. Shingled disassem= bly originated with Wartell et al.'s seminal Distinguishing Code and Da= ta PhD thesis. I'm currently working on the integration of a sheering a= nd PFSM enhanced Shingled Disassembler into BAP. But if you've already = implemented something like that, what would be really valuable is if you we= re to review my shingled disassembler implementation and I review yours tha= t way we have some cross review feedback.

Regardin= g the need for 100% accuracy, in the REINS and STIR papers, the approach ta= ken is to obtain very very high classification accuracy, but in the case th= at correctness cannot be established, to simply retain each interpretation = of a byte sequence, so you are still correct in the instance that it's = code by treating it as such. Then, a companion technique is introduced wher= ein the code section is retained in order that should such a data reference= in code instance occur and interpretation was incorrect, such reference ca= n read and write into the kept section. But if it's code, it has been r= ewritten in the new section. Then it should remain correct in any scenario.=
=C2=A0
However, if I am asked to work on PE binaries, then I wil= l probably start from IDA-Pro.=C2=A0
We consider the disassemblin= g challenge is orthogonal to our research.=C2=A0

It is good to have good interoperabiblity with IDA= as a guided disassembler and the actual new research tools. One of the mos= t valuable things I can think of is to write some plugin that will mechaniz= e data extraction as needed in order to accelerate manual intervention with= the newer tools, such as in the case of training.
=C2=A0

IMH= O, our research reveals the (important) fact that even though theoretically= relocation issue=C2=A0
is hard to solve with 100% accuracy, it m= ight not be as troublesome as it was assumed by previous work.
Si= mple solutions can achieve good results.=C2=A0

Agreed; there are failback stratagems.
=C2=A0

I hope it answers your questions, otherwise, please let me know :)= =C2=A0

Best,
Shuai

<= div>[1] Shuai Wang, Pei Wang, Dinghao Wu, Reassembleable Disassembling.
[2]=C2=A0Zhui Deng, Xiangyu Zhang, Dongyan Xu, BISTRO: Bi= nary Component Extraction and Embedding for Software Security Applications<= /span>
[3]=C2=A0Mingwei Zhang, Sekar, R, Control Flow = Integrity for COTS Binaries.



There's a good utility for wo= rking with white papers and interacting with colleagues; mendeley.
=C2=A0





On F= ri, Oct 23, 2015 at 6:31 PM, Kenneth Adam Miller <kennethadammil= ler@gmail.com> wrote:
Well it's interesting that you've gone with a binary re= compilation approach. How do you ensure that, statically, for any given edi= t, you reposition all the jump targets correctly? How do you deal with the = difficulty of disassembly reducing to the halting problem?
<= div class=3D"gmail_extra">
On Fri, Oct 23, 20= 15 at 4:59 PM, Shuai Wang <wangshuai901@gmail.com> wrot= e:
Hi guys,

I am glad that you are interested in our work!!=C2=A0

=
Actually this project starts over 1.5 years ago, and I believe a= t that time, BAP (version 0.7 I believe?) is still a research prototype..

I choose to implement from the stretch=C2=A0is beca= use I want to have a nice tool for my own research projects, also I can hav= e an opportunity
to learn OCaml... :)

Ye= s, I definitely would like to unite our efforts!!=C2=A0

Best,
Shuai




On= Fri, Oct 23, 2015 at 1:30 PM, Ivan Gotovchits <ivg@ieee.org> wro= te:
Hi = Shuai,

Nice work! But I'm curious, why didn't yo= u use [bap][1] as a disassembler?=C2=A0

Do you kno= w, that we have a low-level interface to disassembling, like [linear_sweep]= [2] or even
lower [Disasm_expert.Basic][3] interface, that can di= sassemble on instruction level granularity.

It wil= l be very interesting, if we can unite our efforts.

Best wishes,
Ivan Gotovchits

[2]:=C2=A0<= a href=3D"http://binaryanalysisplatform.github.io/bap/api/master/Bap.Std.ht= ml#VALlinear_sweep" target=3D"_blank">http://binaryanalysisplatform.github.= io/bap/api/master/Bap.Std.html#VALlinear_sweep



<= br>
On Fri, Oct 23, 2015 at 1:05 PM, Shuai Wang <= span dir=3D"ltr"><wangshuai901@gmail.com> wrote:
Dear List,

I=E2=80=99m glad to=C2=A0anno= unce=C2=A0the first release of Uroboros: =C2=A0an infrastru= cture for reassembleable disassembling and transformation.

You can find the code here:=C2=A0https://github.com/s3team/uroboros= =C2=A0
You can find our re= search paper which describes the core technique implemented in Uroboros her= e:=C2=A0

We will provide a project home page, as w= ell as more detailed documents in the near future. =C2=A0Issues and pull requests welcomed.
<= div style=3D"font-size:12.8000001907349px">

Happy hac= king!

Sincerely,
Shuai







--94eb2c07ee98c1f1c50522f67418--