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 D14177FB5F for ; Mon, 26 Oct 2015 00:11:38 +0100 (CET) IronPort-PHdr: 9a23:hkZyCRyp+G7t2U3XCy+O+j09IxM/srCxBDY+r6Qd0eISIJqq85mqBkHD//Il1AaPBtWGraocw8Pt8IneGkU4qa6bt34DdJEeHzQksu4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2WVTerzWI4CIIHV2nbEwudrmzQtaapv/0/t7x0qWbWx9Piju5bOE6BzSNhiKViPMrh5B/IL060BrDrygAUe1XwWR1OQDbxE6ktY+YtaRu+CVIuv8n69UIEeCjJ/x5HvRkC2EFPmYz6dHr/TDPRA7Hw3oYVmgM2k5LDg7D4Q36V5v4ty77su5wwgGVOMT3SfY/XjH0vIlxTxq9sycaPj9xz2jRhYQkk6tdrwmhuhV+ktaNSI6QPft6OKjaeIVJFiJ6Qs9NWnkZUcuHZIwVAr9EZL4Aog== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=wangshuai901@gmail.com; spf=Pass smtp.mailfrom=wangshuai901@gmail.com; spf=None smtp.helo=postmaster@mail-ob0-f172.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of wangshuai901@gmail.com) identity=pra; client-ip=209.85.214.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="wangshuai901@gmail.com"; x-sender="wangshuai901@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of wangshuai901@gmail.com designates 209.85.214.172 as permitted sender) identity=mailfrom; client-ip=209.85.214.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="wangshuai901@gmail.com"; x-sender="wangshuai901@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-ob0-f172.google.com) identity=helo; client-ip=209.85.214.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="wangshuai901@gmail.com"; x-sender="postmaster@mail-ob0-f172.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BRAABgYS1WlKzWVdFTChaCU4EhYA8GhC2ob5AieAENgVojgkGBYIFZAoETBzgUAQEBAQEBAQEQAQEBAQcLCwkfMIIrggcBAQECAQESER0BGwwLBgEDAQsGBQsNIAoCAiEBAREBBQEcBhMJEgEGh3gBAwoIDaQVgTE+MYtJgWyCeYdbChknDVaEAAEBAQEBBQEBAQEBAQEBARQBBQ6EQIYhgQaCUIFgWQQHgmmBRQWSYoNNB4UcgnCDIYF1gVmEP4MkiySDX4IkEiOBFxEOAQGCRiOBeCI0AQEBAYcUAQEB X-IPAS-Result: A0BRAABgYS1WlKzWVdFTChaCU4EhYA8GhC2ob5AieAENgVojgkGBYIFZAoETBzgUAQEBAQEBAQEQAQEBAQcLCwkfMIIrggcBAQECAQESER0BGwwLBgEDAQsGBQsNIAoCAiEBAREBBQEcBhMJEgEGh3gBAwoIDaQVgTE+MYtJgWyCeYdbChknDVaEAAEBAQEBBQEBAQEBAQEBARQBBQ6EQIYhgQaCUIFgWQQHgmmBRQWSYoNNB4UcgnCDIYF1gVmEP4MkiySDX4IkEiOBFxEOAQGCRiOBeCI0AQEBAYcUAQEB X-IronPort-AV: E=Sophos;i="5.20,198,1444687200"; d="scan'208";a="151711435" Received: from mail-ob0-f172.google.com ([209.85.214.172]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 26 Oct 2015 00:11:34 +0100 Received: by obbwb3 with SMTP id wb3so130405984obb.0 for ; Sun, 25 Oct 2015 16:11:33 -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=Sxj74nUzH1WNq/zAFDO07LKmjtoMacyI5WmSX3ea2rA=; b=HOZs/F96/8hCFFxHW/hsFdl7CUHfLSUZ1/rogpWMuSPD7pblV7JHN27vidfgHk7SRE uGSYq1IWTil2vJVC1Vv2WUjvQ+Zmx2cqTVoyblATPVxi4XR82rodQVTTdPUx0Hne3XST a8yZoASxSI/ocoTI/Bs2JrpDuHOc94lqZiI6LzIDo0NXzOvEf+p65uII2h2heEJuKuTz CvQlHNGH2kvjX0KqvCMX4hteniWn6dVmdosK5sNfGLxndXkEFTmjF0sDt4++Ha/kPKmj WjHEJ5LlWyFO6WiFA4+mP5IA126QhG3noHiFYNbpARd6navKIBKdDMhF8/rL35Qd03Lx 1WkQ== MIME-Version: 1.0 X-Received: by 10.60.144.231 with SMTP id sp7mr23560096oeb.7.1445814692821; Sun, 25 Oct 2015 16:11:32 -0700 (PDT) Received: by 10.202.102.77 with HTTP; Sun, 25 Oct 2015 16:11:32 -0700 (PDT) In-Reply-To: References: Date: Sun, 25 Oct 2015 19:11:32 -0400 Message-ID: From: Shuai Wang To: Kenneth Adam Miller Cc: caml users Content-Type: multipart/alternative; boundary=047d7b47225e2d41c30522f5f7ef Subject: Re: [Caml-list] [ANN] Uroboros 0.1 --047d7b47225e2d41c30522f5f7ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 th= at > 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 shingled >>> disassembler implementation and I review yours that way we have some cr= oss >>> 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, but= in >>> the case that correctness cannot be established, to simply retain each >>> interpretation of a byte sequence, so you are still correct in the inst= ance >>> 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 su= ch 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 co= de, >>> it has been rewritten in the new section. Then it should remain correct= 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 valuable >>> things I can think of is to write some plugin that will mechanize data >>> extraction as needed in order to accelerate manual intervention with the >>> 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 prototyp= e.. >>>>>> >>>>>> 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 opportuni= ty >>>>>> 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.html= #VALlinear_sweep >>>>>>> [3]: >>>>>>> http://binaryanalysisplatform.github.io/bap/api/master/Bap.Std.Disa= sm_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 in= frastructure >>>>>>>> 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/se= c15-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 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> --047d7b47225e2d41c30522f5f7ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 a= ny existing 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, 201= 5 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 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







--047d7b47225e2d41c30522f5f7ef--