I just noticed that the ELF-reader only accepts ELF-64 binary. Could you please add an ELF 32 support? Thanks.

ddisasm --version
1.6.0 (cfa30e8 2023-03-21) ARM64+IA32+X64+ARM32+MIPS32

The process is killed. I do not see the asm output yet.

$ ddisasm non-pie --asm PacketTracer.asm
Building the initial gtirb representation [ 2s]
Processing module: PacketTracer
disassembly load Killed

Hi, I have got some binaries which is failed to be recompiled.

My ddisasm is apt-installed on Ubuntu 18.04, and the version information is:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.5 LTS
Release:        18.04
Codename:       bionic

$ ddisasm --version
1.2.0 (2a4d260 2020-11-13)

Generally speaking, there are two types of errors.

1. The conflicts between the following code blocks could not be resolved

These errors occurs in boringssl, openssl-1.0.1f, and openssl-1.1.0c.

Taking boringssl as an example:

$ ddisasm --asm boringssl-2016-02-12.normal.s  --no-cfi-directives boringssl-2016-02-12.normal
Building the initial gtirb representation  (20ms)
Decoding the binary  (1s)
Disassembling (8520s)
Populating gtirb representation WARNING: Found integral symbol pointing into existing block: .L_4c6c44
 (2s)
Computing intra-procedural SCCs  (68ms)
Computing no return analysis  (44s)
Detecting additional functions  (7s)
Printing assembler WARNING: found overlapping element at address 420beb
The --layout option to gtirb-pprinter can fix overlapping elements.
WARNING: found overlapping element at address 420bec
The --layout option to gtirb-pprinter can fix overlapping elements.
WARNING: found overlapping element at address 420bed
The --layout option to gtirb-pprinter can fix overlapping elements.
 (3s)
The conflicts between the following code blocks could not be resolved:
420bea - 420beb
420bea - 420bec
420bea - 420bed
420bea - 420bee
420beb - 420bec
420beb - 420bed
420beb - 420bee
420bec - 420bed
420bed - 420bee
Aborting

I have done some exploration. It seems all these three binaries contain inlined data (e.g., some crypto stuff contained by hand-written assembly). And I found those conflicting addresses are actually the interleaving data, which may indicates ddisasm somehow misclassified data as code.

2. Segment fault for the recompiled binary

There are other three binaries, including lcms, libxml2, and wpantund.

Taking libxml2 as an example

$ ddisasm --asm libxml2-v2.9.2.normal.s --no-cfi-directives libxml2-v2.9.2.normal
Building the initial gtirb representation  (19ms)
Decoding the binary  (4s)
Disassembling (10322s)
Populating gtirb representation WARNING: Found integral symbol pointing into existing block: .L_50e654
 (13s)
Computing intra-procedural SCCs  (312ms)
Computing no return analysis  (346s)
Detecting additional functions  (102s)
Printing assembler  (3s)

$ gcc -no-pie libxml2-v2.9.2.normal.s -o libxml2-v2.9.2.normal.ddisasm -lm -lpthread -lz

$ ./libxml2-v2.9.2.normal seed    # exit without fault

$ ./libxml2-v2.9.2.normal.ddisasm seed
[1]    1576 segmentation fault (core dumped)  ./libxml2-v2.9.2.normal.ddisasm seed

More

I have attached all the six binaries. In each subdirectory, there is a cmd_line.txt file describing the problem.

I really want to provide the non-stripped version of these binaries, but it seems that they got lost somehow. I do apologize for the inconvenience. All of them come from Google FTS compiled with -O2.

Please let me know if there is anything I can help with. Thanks!

Did a quick test on a proxy dll, it struggled a bit with the import and export having the same name and produced:

EXTERN __imp__DirectDrawCreate_disambig_0_0:PROC
EXTERN _DirectDrawCreate_disambig_0_0:PROC
...
$L_100075d0:
DirectDrawCreate_disambig_0x100075d0_0 PROC EXPORT
DirectDrawCreate_disambig_0x100075d0_0 ENDP
            push EBP
            mov EBP,ESP
...
            jmp DWORD PTR __imp__DirectDrawCreate_disambig_0_0

So when rebuilding that into a dll it can't find the import nor is the export correct.
Removing the _disambig suffix everywhere fixes it (apart from a warning warning LNK4086: entrypoint '__EntryPoint' is not __stdcall with 12 bytes of arguments; image may not run).

ddisasm 1.5.4 (7026bf2 2022-07-07)
invoked like

ddisasm --asm d.asm --generate-import-libs ..\d.dll
ml /nologo /c /Zi d.asm
link /nologo /DLL /ENTRY:_EntryPoint /SUBSYSTEM:windows /DEBUG /OPT:REF /OPT:ICF d.obj

ls.zip
Please provide as much of the following information as possible:
ddisasm --version
1.6.0 (cfa30e8 2023-03-21) ARM64+IA32+X64+ARM32+MIPS32

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal

I can not reassemble the ls program with gcc.

$ ddisasm ls --asm ls.s
Building the initial gtirb representation [ 1ms]
Processing module: ls
disassembly load [ 359ms] compute [ 3s] transform [ 206ms]
SCC analysis compute [ 9ms] transform [ 0ms]
no return analysis load [ 11ms] compute [ 294ms] transform [ 0ms]
function inference load [ 35ms] compute [ 19ms] transform [ 7ms]
Printing assembler [ 150ms]

$ gcc -nostartfiles ls.s -o ls-out
/usr/bin/ld: warning: cannot create .note.gnu.build-id section, --build-id ignored
/usr/bin/ld: /tmp/cchpOuqm.o: in function FUN_16800': (.text+0x11a76): undefined reference to freecon'
/usr/bin/ld: /tmp/cchpOuqm.o: in function FUN_16870': (.text+0x11aba): undefined reference to getfilecon'
/usr/bin/ld: /tmp/cchpOuqm.o: in function FUN_16890': (.text+0x11ada): undefined reference to lgetfilecon'
/usr/bin/ld: /tmp/cchpOuqm.o: in function FUN_168b0': (.text+0x11afa): undefined reference to fgetfilecon'
/usr/bin/ld: /tmp/cchpOuqm.o: in function FUN_6f20': (.text+0x21ae): undefined reference to freecon'
collect2: error: ld returned 1 exit status

I am trying to reassemble windows dll using ddisasm. I am testing with a random repository on github https://github.com/RohitKumarPattanayak/Stack_CG_project

It's compiled with visual studio 2022. and binary is here (freeglut.dll) Debug.zip

Disassemble command:

ddisasm --asm=./freeglut_r.s --generate-import-libs --generate-resources ./freeglut.dll

Reassembled with:

ml /OUT:freeglut_r.dll .\freeglut_r.s /link /entry:_EntryPoint /DLL

but after I replaced original dll with the reassembled one, I got a prodcedure entry point __glutInitWithExit error when running original executable cg-final-stack.exe .

ddisasm version 1.5.5 (UNKNOWN 2022-10-29) ARM64+IA32+X64+ARM32+MIPS32

I just saw in an introduction of gtirb and ddisasm that they can perform "reduce" that remove some features in the binary, or debloat binary. How to use "reduce" and "debloating" with ddisasm???

I'm trying to write some analysis with datalog based on ddisasm, but it's not convenient to reuse the existing results when implementing a pass. Should I write some datalog program and include it from main.dl or are there any recommended ways?

Hi, thanks for this great work.

I am trying to use ddisasm to reassembly some my CTF programs. The file a.out is attached.

It is 64-bit position dependent code.

$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=a7ca5dae0321cb388b9e35b7e9237468ec95458c, stripped

$ readelf -h a.out
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2\'s complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x401080
  Start of program headers:          64 (bytes into file)
  Start of section headers:          103136 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         9
  Size of section headers:           64 (bytes)
  Number of section headers:         28
  Section header string table index: 27

$ md5sum a.out
c82373549ce71428dff66b22976c3e3a  a.out

The ddisasm version is shown as follows.

$ ddisasm --version
1.0.1 (453889a 2020-07-14)

When I try to disassemble it, it works well.

$ ddisasm a.out --asm a.s
Building the initial gtirb representation  (1ms)
Decoding the binary  (210ms)
Disassembling (271s)
Populating gtirb representation  (277ms)
Computing intra-procedural SCCs  (7ms)
Computing no return analysis  (5s)
Detecting additional functions  (7s)
Printing assembler  (73ms)

But when I try to reassemble it, it failed.

$ gcc a.s -o a.out.new
/usr/bin/ld: /tmp/ccDUmrVS.o: relocation R_X86_64_32S against \`.text\' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

I know it is possible that ddisasm makes some wrong symbolization. But may I know whether the failure is caused by the wrong symbolization or because I did something wrong?

Btw, the ddisasm works well on the example code.

$ readelf -h ex
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2\'s complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x400400
  Start of program headers:          64 (bytes into file)
  Start of section headers:          6400 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         9
  Size of section headers:           64 (bytes)
  Number of section headers:         29
  Section header string table index: 28

$ ddisasm ex --asm ex.s
Building the initial gtirb representation  (0ms)
Decoding the binary  (3ms)
Disassembling (32s)
Populating gtirb representation  (2ms)
Computing intra-procedural SCCs  (0ms)
Computing no return analysis  (631ms)
Detecting additional functions  (1s)
Printing assembler  (0ms)

$ gcc ex.s -o ex.out

$ ./ex.out
!!!Hello World!!!

Thanks.

These facts are analyzed to identify code location, symbolization, and function boundaries.

Yet in the resulting (edit: MASM) disassembly most functions are simple labels, indistinguishable from function-internal block labels.
Even an exported function is just an empty PROC EXPORT ENDP block in front of the function.
Is there a way to improve this or is it simply not implemented?

Also, are non-trivial differences in the assembly to be expected?
When comparing the original executable and the re-assembled one I saw NFCs like alignment or lea [x] vs lea [x+0], but also completely different registers and instructions sometimes.

Building the initial gtirb representation  (58ms)
Decoding the binary WARNING: Missing `alignment' AuxData table
 (51s)
Disassembling (424s)
Populating gtirb representation  (30s)
Computing intra-procedural SCCs  (3s)
Computing no return analysis  (43s)
Detecting additional functions  (8s)
Printing assembler WARNING: found overlapping element at address 1802e7919
The --layout option to gtirb-pprinter can fix overlapping elements.
WARNING: found overlapping element at address 1802e7925
The --layout option to gtirb-pprinter can fix overlapping elements.
WARNING: found overlapping element at address 1802e792d
The --layout option to gtirb-pprinter can fix overlapping elements.
WARNING: found overlapping element at address 1802e7934
The --layout option to gtirb-pprinter can fix overlapping elements.
 (22s)
The conflicts between the following code blocks could not be resolved:
1802e7915 - 1802e7919
1802e7919 - 1802e7921
1802e7924 - 1802e7925
1802e792c - 1802e792d
1802e7931 - 1802e7934
Aborting

This is with ddisasm 1.4 (1cbb62c)

You can find a copy of d3dcompiler_47.dll in http://ftp.mozilla.org/pub/firefox/nightly/2021/02/2021-02-26-21-45-01-mozilla-central/firefox-88.0a1.en-US.win64.zip

I was trying to create a PE32 parser modeled after the ELF parser, but got caught up with trying to figure out the PE32 equivalents of:

Module->addAuxData<gtirb::schema::ElfSectionIndex>(std::move(SectionIndex));
Module->addAuxData<gtirb::schema::ElfSectionProperties>(std::move(SectionProperties));

I'm not familiar with this project, and this is probably a feature best left to those who are.

OS: Ubuntu 16.04
Capstone version: 4.0.1
Souffle version: 1.5.1
Issue: In ddisasm/build directory, running make produces error:

/home/aditi/ddisasm/build/src/souffle_disasm.cpp: In lambda function:
/home/aditi/ddisasm/build/src/souffle_disasm.cpp:35309:34: error: redeclaration of ‘const souffle::ram::Tuple<long int, 4> key’
 const ram::Tuple<RamDomain,4> key({{env0[1],0,0,0}});
                                  ^
/home/aditi/ddisasm/build/src/souffle_disasm.cpp:35299:31: note: ‘const souffle::ram::Tuple<long int, 4> key’ previously declared here
 const ram::Tuple<RamDomain,4> key({{env0[0],0,0,0}});
                               ^~~
/home/aditi/ddisasm/build/src/souffle_disasm.cpp:35310:6: error: conflicting declaration ‘auto range’
 auto range = rel_346_block_points->equalRange_1(key,READ_OP_CONTEXT(rel_346_block_points_op_ctxt));
      ^~~~~
/home/aditi/ddisasm/build/src/souffle_disasm.cpp:35300:6: note: previous declaration as ‘souffle::range<souffle::detail::btree<souffle::ram::Tuple<long int, 4>, souffle::ram::index_utils::comparator<0, 1, 2, 3>, std::allocator<souffle::ram::Tuple<long int, 4> >, 256, souffle::detail::binary_search, true, souffle::ram::index_utils::comparator<0, 1, 2, 3>, souffle::detail::updater<souffle::ram::Tuple<long int, 4> > >::iterator> range’
 auto range = rel_346_block_points->equalRange_1(key,READ_OP_CONTEXT(rel_346_block_points_op_ctxt));
      ^~~~~
/home/aditi/ddisasm/build/src/souffle_disasm.cpp: In lambda function:
/home/aditi/ddisasm/build/src/souffle_disasm.cpp:35346:34: error: redeclaration of ‘const souffle::ram::Tuple<long int, 4> key’
 const ram::Tuple<RamDomain,4> key({{env0[0],0,0,0}});
                                  ^
/home/aditi/ddisasm/build/src/souffle_disasm.cpp:35336:31: note: ‘const souffle::ram::Tuple<long int, 4> key’ previously declared here
 const ram::Tuple<RamDomain,4> key({{env0[1],0,0,0}});
                               ^~~
/home/aditi/ddisasm/build/src/souffle_disasm.cpp:35347:6: error: conflicting declaration ‘auto range’
 auto range = rel_346_block_points->equalRange_1(key,READ_OP_CONTEXT(rel_346_block_points_op_ctxt));
      ^~~~~
/home/aditi/ddisasm/build/src/souffle_disasm.cpp:35337:6: note: previous declaration as ‘souffle::range<souffle::detail::btree<souffle::ram::Tuple<long int, 4>, souffle::ram::index_utils::comparator<0, 1, 2, 3>, std::allocator<souffle::ram::Tuple<long int, 4> >, 256, souffle::detail::binary_search, true, souffle::ram::index_utils::comparator<0, 1, 2, 3>, souffle::detail::updater<souffle::ram::Tuple<long int, 4> > >::iterator> range’
 auto range = rel_346_block_points->equalRange_1(key,READ_OP_CONTEXT(rel_346_block_points_op_ctxt));
      ^~~~~
src/CMakeFiles/ddisasm.dir/build.make:86: recipe for target 'src/CMakeFiles/ddisasm.dir/souffle_disasm.cpp.o' failed
make[2]: *** [src/CMakeFiles/ddisasm.dir/souffle_disasm.cpp.o] Error 1
CMakeFiles/Makefile2:124: recipe for target 'src/CMakeFiles/ddisasm.dir/all' failed
make[1]: *** [src/CMakeFiles/ddisasm.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2```

The ddisasm package from https://download.grammatech.com/gtirb/files/windows-release/ contains unnecessary huge files like ddisasm.ilk and test*.ilk. Removing them should save you some bandwidth.

Neither the readme document nor the CMake script indicate which version of Souffle to use. I do notice that the readme document is over a year old. The current version of Souffle is 2.0.0, and trying to compile against it throws a lot of operating overloading errors: ddisasm/src/DlOperandTable.cpp:34:76: error: ambiguous overload for ‘operator<<’ (operand types are ‘souffle::tuple’ and ‘const int’).

I fixed some of these by casting the variable to what I guessed to be the correct Ram... type:
DatalogUtils.cpp:184:
t << (RamUnsigned) inst.immediateOffset << (RamUnsigned) inst.displacementOffset;

However, there are a lot of these errors and I'm hesitant to go through all of them and find that this didn't work for some reason. How about updating the documentation?

Also, when running the configure script for souffle versions 2.0.0, 1.7.0, and 1.6.0, it says:
configure: WARNING: unrecognized options: --disable-provenance

/usr/local/include/souffle/SymbolTable.h:40:7: error: use of deleted function 'souffle::Lock::Lock(const souffle::Lock&)'
In file included from /usr/local/include/souffle/SymbolTable.h:21,
from /usr/local/include/souffle/SouffleInterface.h:21,
from /usr/local/include/souffle/CompiledSouffle.h:22,
from /home/cqwrteur/ddisasm/src/gtirb-decoder/DatalogProgram.h:26,
from /home/cqwrteur/ddisasm/src/gtirb-decoder/DatalogProgram.cpp:23:
/usr/local/include/souffle/utility/ParallelUtil.h:110:7: note: 'souffle::Lock::Lock(const souffle::Lock&)' is implicitly deleted because the default definition would be ill-formed:
110 | class Lock {
| ^~~~
/usr/local/include/souffle/utility/ParallelUtil.h:110:7: error: use of deleted function 'std::mutex::mutex(const std::mutex&)'
In file included from /usr/local/include/c++/12.0.0/mutex:43,
from /usr/local/include/souffle/SignalHandler.h:26,
from /usr/local/include/souffle/CompiledSouffle.h:21,
from /home/cqwrteur/ddisasm/src/gtirb-decoder/DatalogProgram.h:26,
from /home/cqwrteur/ddisasm/src/gtirb-decoder/DatalogProgram.cpp:23:
/usr/local/include/c++/12.0.0/bits/std_mutex.h:94:5: note: declared here
94 | mutex(const mutex&) = delete;
| ^~~~~
/home/cqwrteur/ddisasm/src/gtirb-decoder/DatalogProgram.cpp:65:43: error: 'class souffle::SymbolTable' has no member named 'resolve'
65 | Stream << SymbolTable.resolve(Tuple[I]);
| ^~~~~~~

vim compiled with gcc-7.5.0 fails with:

Printing assembler ddisasm: /root/gtirb-pprinter/src/gtirb_pprinter/ElfPrettyPrinter.cpp:195: void gtirb_pprint::ElfPrettyPrinter::printSymbolHeader(std::ostream&, const gtirb::Symbol&, bool): Assertion `!"unknown visibility in elfSymbolInfo!"' failed.

This is with ddisasm 1.4 (1cbb62c)

I've attached the binary
vim.zip

I ran into this while trying out ddisasm on https://github.com/pangine/disasm-benchmark

When I tested Ddisasm v1.5.3 (docker image digests a803c9, Apr. 2022) for my research, I found several interesting bug cases. 
 
First, I observe that Ddisasm incorrectly symbolize jump table. As an example, given the jump table entry ‘.long .L4895-.L4896’ found in addr2line.tar.gz of Binutils, Ddisasm recognized the value as a jump table entry but the label value is misidentified.

• Compiler-generated assembly 

.L3326:                       ; this jump table will be placed at 0x131830
    .long	.L3323-.L3326 ; the entry can be represented as .L_103630 - .L_131830
     #...

• Binary

 131830: 001efdff

• Reassembler-generated assembly 

.L_131830:
# data_access(4, 4, 1034ee), data_access(4, 4, 10360e), preferred_data_access(131830)
          131830: .long .L_10360c-.L_13180c
# preferred_data_access(131830)
          131834: .long .L_103660-.L_131830

Second, I found that Ddisasm omits some definitions of labels. For example, given the instruction ‘movl $default_quoting_options, %eax’ found in true.tar.gz (x64 non-pie binary) of Coreutils, Ddisasm reassembled the instruction as ‘mov EAX,OFFSET .L_40b2e0’. However, Ddisasm missed the definition of label ‘. L_40b2e0’ so it causes a compilation error.

• Reassembler-generated assembly 

  402bb5:   mov EAX,OFFSET .L_40b2e0

Third, I observed that Ddisasm makes wrong symbolic expressions so some recompiled binaries refer to incorrect addresses. As an example, given the disassembly code ‘.long .L1543@GOTOFF’ found in nm_new.tar.gz (x86 pie binary) of binutils, Ddisasm symbolized the pointer as ‘.long .L_e4b5-.L_785f1’

• Compiler-generated assembly

    .long	.L1543@GOTOFF       ; this entry can be represented as .L_95eb8

• Reassembler-generated assembly

0xc5fe4 : .long .L_e4b5-.L_785f1

Also, I observed that Ddisasm makes some mistakes when it generates got-relative labels. As an example, given the instruction ‘addl $yydefgoto@GOTOFF, %eax’ found in date.tar.gz (x86 pie binary) of coreutils, ddiasm the immediate value as ‘.L_11eca@GOTOFF’. However, the ‘yydefgoto’ is placed at 0x11ee6 not 0x11eca. Also, I calculated the got relative address and concluded that Ddisasm misidentified the label value.

• Compiler-generated assembly

      addl $yydefgoto@GOTOFF, %eax     

• Binary (non-stripped version)

$ readelf -s date | grep yydefgoto
   179: 00011ee6    26 OBJECT  LOCAL  DEFAULT   16 yydefgoto

$ objdump -d -M intel date | grep 6395
    6395:    81 c0 e6 be ff ff        add    eax,0xffffbee6

$ readelf -S date | grep got.plt
  [24] .got.plt          PROGBITS        00016000 015000 000128 04  WA  0   0  4

$ python3 -c 'print(hex(0xffffbee6 + 0x0016000 & 0xffffffff))'
0x11ee6

• Reassembler-generated assembly

          6395:   add EAX,OFFSET .L_11eca@GOTOFF

Lastly, I observed that Ddisasm fails on symbolization when it handles large size binary. For example, Ddisasm fails on symbolizing rip-relative addressing when it reassembled 416.gamess.tar.gz (delete link) of spec cpu 2006. As a result, it causes tremendous false negative errors. 

• Reassembler-generated assembly

main:
            sub RSP,8
            call FUN_13f0

            lea RSI,QWORD PTR [RIP+6413305]     ; fails on symbolization

The assembly file generated by ddisasm are in Intel. Is there any options to generate AT&T assembly files which can be (re)assembled back by GCC?

I want build ddisasm.
I follow

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:mhier/libboost-latest
echo "deb [trusted=yes] https://grammatech.github.io/gtirb/pkgs/bionic ./" | sudo tee -a /etc/apt/sources.list.d/gtirb.list
sudo apt-get update
sudo apt-get install libgtirb gtirb-pprinter ddisasm

And I can use ddisasm in command

 ddisasm --help
Usage: ddisasm [OPTIONS...] INPUT_FILE
Disassemble INPUT_FILE and output assembly code and/or gtirb.

Allowed options:
  -h [ --help ]                    produce help message
  --version                        display ddisasm version

However when I build it in cmake, the error occur

~/Desktop/ddisasm-master$ cmake ./ -Bbuild
CMake Error at CMakeLists.txt:149 (find_package):
  By not providing "Findgtirb.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "gtirb", but
  CMake did not find one.

  Could not find a package configuration file provided by "gtirb" (requested
  version 1.10.0) with any of the following names:

    gtirbConfig.cmake
    gtirb-config.cmake

  Add the installation prefix of "gtirb" to CMAKE_PREFIX_PATH or set
  "gtirb_DIR" to a directory containing one of the above files.  If "gtirb"
  provides a separate development package or SDK, be sure it has been
  installed.


-- Configuring incomplete, errors occurred!
See also "/home/qun/Desktop/ddisasm-master/build/CMakeFiles/CMakeOutput.log".
See also "/home/qun/Desktop/ddisasm-master/build/CMakeFiles/CMakeError.log".

could you tell me how to solve it since I could run ddisasm in command line (means I satisfy all requirements).

Hello,

Thank you for your work on this project, and for sharing it with the community.

The dockerfile fails to build on the aarch64 architecture, due to some wrong paths and outdated libraries.
I am pasting here a modified dockerfile that works only for aarch64; hopefully if it is useful for you guys.

dockerfile_aarch64.tar.gz

I realize this is more of a question / feature request.

I'm using the gtirb produced by ddisasm to perform some rewriting. The offsets of the instructions I'm rewriting are created by another tool, and the offsets are relative to the addresses of sections in the original ELF. I couldn't find this mapping information in the gtirb file, and I noticed that offsets of CodeBlocks in the gtirb do no match either. The only trick I found that allows me to map offsets in the original binary to the gtirb is by using the Function offsets since even if the function name is not retained, it is named with ".L_XXX" where XXX is an offset in the original binary. It's a bit cumbersome to keep track of the mapping like this, and it fails for code that's not in a function. Is there another way? Ideally CodeBlock would have an "originaloffset" set to the offset in the binary it was lifted from.

exim compiled with icc-19.1.1.219 fails with:

ddisasm ./exim --asm exim.s
Building the initial gtirb representation  (118ms)
Decoding the binary  (20s)
Disassembling (92s)
Populating gtirb representation  (11s)
Computing intra-procedural SCCs  (1s)
Computing no return analysis  (5s)
Detecting additional functions  (3s)
Printing assembler WARNING: found overlapping element at address 4fd492
The --layout option to gtirb-pprinter can fix overlapping elements.
 (es)
The conflicts between the following code blocks could not be resolved:
4fd490 - 4fd492
Aborting

This is with ddisasm 1.4 (1cbb62c)

I've attached the binary
exim.zip

I ran into this while trying out ddisasm on https://github.com/pangine/disasm-benchmark

Hi:
When I am reading souffle code in src/datalog/value_analysis.dl.

// mov DWORD from memory
value_reg_edge(EA,Reg,EA,"NONE",0,Val):-
    def_used_for_address(EA,Reg),
    arch.move_operation(Operation),
    instruction(EA,_,_,Operation,Op1,Op2,0,0,_,_),
    op_regdirect_contains_reg(Op2,Reg),
    op_indirect(Op1,"NONE","NONE","NONE",_,Offset,32),
    Offset_addr = as(Offset,address),                                           // here
    data_byte(Offset_addr,Byte0),
    data_byte(Offset_addr+1,Byte1),
    data_byte(Offset_addr+2,Byte2),
    data_byte(Offset_addr+3,Byte3),
    Byte3 <= 128,
    Val = as(Byte3*2^24+ Byte2*2^16 + Byte1*2^8 + Byte0,number).

I found in line 123, a variable has type number is casted to address(unsigned). ddisasm require enable 64bit domain when compiling souffle, so this casting will always make Offset_addr become a u64 address even when handling 32bit binary. For example, -1 will be converted into 18446744073709551615, while in 32bit mode it should be 4294967295.

Yihao

For instance, one fact from cfg_edge.facts is: 4248448 4273824 false false call.
According to the declaration of cfg_edge(src:address,dest:address,conditional:symbol,indirect:symbol,type:symbol), 4248448 is the source address and 4273824 is the destination address.
But I cannot find the corresponding address in the assembly code.
Could you please give some suggestions about how to find the corresponding address between the assembly code and the facts files?
Thanks!

Some symbolic_operand will be marked as both code and data. This can be observed in almost every test case. Is there any reason for this ambiguity?

Quickest question:
What should I set gtirb_DIR and gtirb_pprinter_DIR?
I can't seem to locate neither gtirbConfig.cmake nor gtirb-config.cmake
like cmake is asking me to.
Thanks!

Hi, I follow the README to install pre-built ddisasm on my ubuntu 18.04 machine.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.5 LTS
Release:        18.04
Codename:       bionic

I successfully installed ddisasm following the guidance.

$ sudo add-apt-repository ppa:mhier/libboost-latest
$ echo "deb [trusted=yes] https://grammatech.github.io/gtirb/pkgs/bionic ./" | sudo tee -a /etc/apt/sources.list.d/gtirb.list
$ sudo apt-get update
$ sudo apt-get install ddisasm

However, when I try to executable ddisasm, the following error message shows out.

$ ddisasm
ddisasm: error while loading shared libraries: libgtirb.so.1.8.7: cannot open shared object file: No such file or directory

I then check the dynamic library required by ddisasm:

 $ ldd /usr/bin/ddisasm
        linux-vdso.so.1 (0x00007ffcadb6e000)
        libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007ff729950000)
        libgtirb_pprinter.so.1 => /usr/lib/libgtirb_pprinter.so.1 (0x00007ff7296d0000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff7294b1000)
        libboost_filesystem.so.1.67.0 => /usr/lib/libboost_filesystem.so.1.67.0 (0x00007ff729296000)
        libboost_program_options.so.1.67.0 => /usr/lib/libboost_program_options.so.1.67.0 (0x00007ff729013000)
        libboost_system.so.1.67.0 => /usr/lib/libboost_system.so.1.67.0 (0x00007ff728e0e000)
        libgtirb.so.1.8.7 => not found
        libcapstone.so.5 => /usr/lib/libcapstone.so.5 (0x00007ff7283e8000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff72805f000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff727cc1000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff727aa9000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff7276b8000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff7274b4000)
        libgtirb.so.1.9.0 => /usr/lib/libgtirb.so.1.9.0 (0x00007ff727219000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff72b016000)
        libprotobuf.so.10 => /usr/lib/x86_64-linux-gnu/libprotobuf.so.10 (0x00007ff726dc0000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff726ba3000)

It seems there are two libgtirbs (libgtirb.so.1.8.7 and libgtirb.so.1.9.0), among which libgtirb.so.1.8.7 is missed.

Hi, thank you for making DDisasm open source. I'm trying to identify function boundaries with DDisasm, the expected result should be like

name, head, tail
func1, 0, 420
func2, 424, 516
...

At present, I disassemble the binary and then grep the string @function from the result. But I can not get the address of the function in this way. Is there any better way to get function boundaries? 😃

I'm experimenting with C code that has a large data segment and relatively little code. I'm happy to share the binaries with you, but I prefer not to post them publicly. If you want them, send me a ping, and I can email them. Hope this helps!

Issue 1, for gcc binaries (-O2 or not) ddisasm hangs

If I compile with gcc (Ubuntu 7.5.0-3ubuntu1~18.04), ddisasm will hang in the disassembling phase (with or without "-O2"). When I interrupt I see this:

$ gcc -O2 -Wall -o wbc_gcc wbc.c && ./wbc_gcc 00112233445566778899aabbccddeeff
255fb7f6c6456e0420de3aff5d1247b9
$ ddisasm  --ir retargeted_wbc_gcc.gtirb --asm retargeted_wbc_gcc.s wbc_gcc
Building the initial gtirb representation  (19ms)
Decoding the binary  (1s)
Disassembling ^CInterrupt signal in rule:
propagated_data_access((EA+Mult),Mult,EA_ref) :- 
   propagated_data_access(EA,Mult,EA_ref),
   data_byte( _tmp_0,_),
   possible_data_limit( _tmp_0),
   data_access_pattern( _tmp_0,S,0,From),
   data_access_pattern(EA_ref,S,Mult,From),
   last_data_access( _tmp_0,Last),
   data_access_pattern(Last,Size,Mult,_),
   Last > EA,
   (Last+Size) <= (EA+Mult),
    _tmp_0 = (EA+Mult).
in file data_access_analysis.dl [254:1-274:7]

Issue 2, for clang -O2 ddisasm produces a broken asm

If I compile with clang (6.0.0-1ubuntu2) and "-O2", ddisasm finishes but the assembly will not compile.

$ clang -O2 -Wall -o wbc_clang wbc.c && ./wbc_clang 00112233445566778899aabbccddeeff
255fb7f6c6456e0420de3aff5d1247b9
$ ddisasm  --ir retargeted_wbc_clang.gtirb --asm retargeted_wbc_clang.s wbc_clang
Building the initial gtirb representation  (27ms)
Decoding the binary  (1s)
Disassembling  (11s)
Populating gtirb representation  (68s)
Computing intra-procedural SCCs  (0ms)
Computing no return analysis  (186ms)
Detecting additional functions  (793ms)
Printing assembler  (24s)
$ gcc -o retargeted_wbc_clang retargeted_wbc_clang.s
/usr/bin/ld: /tmp/ccQujJfU.o: relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

Issue 3, for clang -O2 with relocations ddisasm finds no errors

On the clang with "-O2" binary for which ddisasm produces broken asm, I tried to run ddisasm with --self-diagnose, but it reports everything is fine. Attempting to compile the resulting assembly still leads to an error.

$ clang -O2 -Wall -Xlinker "--emit-relocs" -o wbc_clang_relocs wbc.c && ./wbc_clang_relocs 00112233445566778899aabbccddeeff
255fb7f6c6456e0420de3aff5d1247b9
$ ddisasm  --self-diagnose --ir retargeted_wbc_clang_relocs.gtirb --asm retargeted_wbc_clang_relocs.s wbc_clang_relocs
Building the initial gtirb representation  (45ms)
Decoding the binary  (1s)
Disassembling  (11s)
Populating gtirb representation  (72s)
Computing intra-procedural SCCs  (1ms)
Computing no return analysis  (185ms)
Detecting additional functions  (803ms)
Printing assembler  (26s)
Perfoming self diagnose (this will only give the right results if the target program contains all the relocation information)
Self diagnose completed: No errors found
$ gcc -o retargeted_wbc_clang_relocs retargeted_wbc_clang_relocs.s
/usr/bin/ld: /tmp/cc86oslH.o: relocation R_X86_64_32S against undefined symbol `_disambig_94898743884080' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

Clang without explicit optimization works!

If I compile with clang (6.0.0-1ubuntu2) and omit "-O2, all is well!

$ clang -Wall -o wbc_clang_noopt wbc.c && ./wbc_clang_noopt 00112233445566778899aabbccddeeff
255fb7f6c6456e0420de3aff5d1247b9
$ ddisasm  --ir retargeted_wbc_clang_noopt.gtirb --asm retargeted_wbc_clang_noopt.s wbc_clang_noopt
Building the initial gtirb representation  (23ms)
Decoding the binary  (1s)
Disassembling  (11s)
Populating gtirb representation  (69s)
Computing intra-procedural SCCs  (3ms)
Computing no return analysis  (175ms)
Detecting additional functions  (763ms)
Printing assembler  (25s)
$ gcc -o retargeted_wbc_clang_noopt retargeted_wbc_clang_noopt.s
$ ./retargeted_wbc_clang_noopt 00112233445566778899aabbccddeeff
255fb7f6c6456e0420de3aff5d1247b9

Ddisasm version is git commit 15f97c8.

$ ddisasm --version
1.0.0 (15f97c8 2020-05-27)

Following up on #11 (comment).

error A2008: syntax error : pushal
error A2008: syntax error : popal
error A2152: coprocessor register cannot be first operand : fdivr ST(0)

Should be pushad/popad and fdivr ST(0),ST(0) (D8 F8).

And there are false positives where it identified RGB data in the resource section as references, I'm not sure if that is even possible:

_RSRC SEGMENT
ALIGN 16
...
          BYTE 077H
          BYTE 077H
          BYTE 077H
          BYTE 000H
          DWORD $L_6b6b6b
          DWORD $L_5f5f5f
          DWORD $L_535353
          BYTE 047H
          BYTE 047H
          BYTE 047H
          BYTE 000H

Also there were issues with name mangling. I had to use ml /link /entry:_EntryPoint instead of /entry:__EntryPoint (it then still resulted in warning LNK4216: Exported entry point __EntryPoint though).

Then it generated import declarations like

EXTERN __imp__CreateFileA:PROC
EXTERN _CreateFileA:PROC

while C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\um\x86\kernel32.Lib contains stdcall decorated

_CreateFileA@28 __imp__CreateFileA@28

test.obj : error LNK2001: unresolved external symbol __imp__CreateFileA
test.obj : error LNK2001: unresolved external symbol _CreateFileA

sudo apt install selinux-utils -y libselinux1-dev
gcc -nostartfiles ls.s  -o ls-out -l selinux -O0
./ls-out

diff ls ls-out -q
Files ls and ls-out differ

for more informations with radiff2, fell free to install radare2 with:
ideally:

git clone https://github.com/radareorg/radare2
cd radare2
sh sys/install.sh


#or if you can not compile, install radare2 with `sudo apt install radare2;`

$ radiff2 -U ls ls-out
File size differs 142144 vs 159320
Binary files .a and .b differ

$ radiff2 -u ls ls-out

+0x00020808:8606410e38830744 "\x86\x06A\x0e8\x83\aD\x0e@\x02\x97\n\x0e8A\x0e0A\x0e(B\x0e B\x0e\x18B\x0e\x10B\x0e\bA\vT\n\x0e8F\x0e0A\x0e(B\x0e B\x0e\x18B\x0e\x10B\x0e\bE\v"
-0x00020811:18420e10420e08450b000034000000a82c00002c65ffff9a00000000460e108c02 "\x18B\x0e\x10B\x0e\bE\v"
+0x00020811:4002970a0e38410e30410e28420e20420e18420e10420e08410b540a0e38460e30 "@\x02\x97\n\x0e8A\x0e0A\x0e(B\x0e B\x0e\x18B\x0e\x10B\x0e\bA\vT\n\x0e8F\x0e0A\x0e(B\x0e B\x0e\x18B\x0e\x10B\x0e\bE\v"
-0x00020834:188603410e208304025f0a "\x18\x86\x03A\x0e \x83\x04\x02_\n\x0e\x18A\x0e\x10B\x0e\bF\vf\x0e\x18A\x0e\x10B\x0e\b"
+0x00020834:28420e20420e18420e1042 "(B\x0e B\x0e\x18B\x0e\x10B\x0e\bE\v"
-0x00020840:18410e10420e08460b660e18410e10420e08 "\x18A\x0e\x10B\x0e\bF\vf\x0e\x18A\x0e\x10B\x0e\b"
+0x00020840:08450b004c000000e0290000f466ffffb500 "\bE\v"
-0x00020854:60000000e02c00009465ffff5501000000420e108f02420e188e03420e208d04420e288c05410e30860641 "" -0x00020880:388307440e4002970a0e38410e30410e28420e20420e18420e10420e08410b540a0e38460e30410e28420e20420e18420e10420e08450b "8\x83\aD\x0e@\x02\x97\n\x0e8A\x0e0A\x0e(B\x0e B\x0e\x18B\x0e\x10B\x0e\bA\vT\n\x0e8F\x0e0A\x0e(B\x0e B\x0e\x18B\x0e\x10B\x0e\bE\v" +0x00020880:18410e10420e08450b490e18410e10420e08000010000000302a00006467ffff110000000000000058000000442a00007067ffffa60000 "\x18A\x0e\x10B\x0e\bE\vI\x0e\x18A\x0e\x10B\x0e\b" -0x000208b8:4c000000442d00009066ffffb500000000420e108c02410e188603410e20830402630a "L" -0x000208dc:1841 "\x18A\x0e\x10B\x0e\bF\vZ\n\x0e\x18A\x0e\x10B\x0e\bC\vP\n\x0e\x18A\x0e\x10B\x0e\bE\vI\x0e\x18A\x0e\x10B\x0e\b" +0x000208dc:1042 "\x10B\x0e\bC\vR\n\x0e(C\x0e B\x0e\x18B\x0e\x10B\x0e\bE\vT\x0e(G\x0e B\x0e\x18B\x0e\x10B\x0e\b" -0x000208df:10420e08460b5a0a "\x10B\x0e\bF\vZ\n\x0e\x18A\x0e\x10B\x0e\bC\vP\n\x0e\x18A\x0e\x10B\x0e\bE\vI\x0e\x18A\x0e\x10B\x0e\b" +0x000208df:08430b520a0e2843 "\bC\vR\n\x0e(C\x0e B\x0e\x18B\x0e\x10B\x0e\bE\vT\x0e(G\x0e B\x0e\x18B\x0e\x10B\x0e\b" -0x000208e8:1841 "\x18A\x0e\x10B\x0e\bC\vP\n\x0e\x18A\x0e\x10B\x0e\bE\vI\x0e\x18A\x0e\x10B\x0e\b" +0x000208e8:2042 " B\x0e\x18B\x0e\x10B\x0e\bE\vT\x0e(G\x0e B\x0e\x18B\x0e\x10B\x0e\b" -0x000208eb:10 "\x10B\x0e\bC\vP\n\x0e\x18A\x0e\x10B\x0e\bE\vI\x0e\x18A\x0e\x10B\x0e\b" +0x000208eb:18 "\x18B\x0e\x10B\x0e\bE\vT\x0e(G\x0e B\x0e\x18B\x0e\x10B\x0e\b" -0x000208ee:08430b500a0e18410e10420e08450b49 "\bC\vP\n\x0e\x18A\x0e\x10B\x0e\bE\vI\x0e\x18A\x0e\x10B\x0e\b" +0x000208ee:10420e08450b540e28470e20420e1842 "\x10B\x0e\bE\vT\x0e(G\x0e B\x0e\x18B\x0e\x10B\x0e\b" -0x000208ff:1841 "\x18A\x0e\x10B\x0e\b" +0x000208ff:1042 "\x10B\x0e\b" -0x00020902:10420e08 "\x10B\x0e\b" +0x00020902:08003000 "\b" -0x00020908:1000 "\x10" +0x00020908:a02a "\xa0*" -0x0002090c:942d00000067ffff110000000000000058000000a82d00000c67ffffa600000000460e108e0245 "\x94-" +0x0002090c:c467ffff4101000000460e108d02420e188c03410e208604470e70028b0a0e20410e18420e1042 "\xc4g\xff\xffA\x01" -0x00020934:188d03420e208c04410e288605470e307e0a0e28440e20420e18420e10420e08430b520a0e28430e2042 "\x18\x8d\x03B\x0e \x8c\x04A\x0e(\x86\x05G\x0e0~\n\x0e(D\x0e B\x0e\x18B\x0e\x10B\x0e\bC\vR\n\x0e(C\x0e B\x0e\x18B\x0e\x10B\x0e\bE\vT\x0e(G\x0e B\x0e\x18B\x0e\x10B\x0e\b" +0x00020934:08480b0010000000d42a0000e068ffff330000000000000028000000e82a00000c69ffff650000000046 "\bH\v" -0x0002095f:18420e10420e08450b540e28470e20420e18420e10420e080034 "\x18B\x0e\x10B\x0e\bE\vT\x0e(G\x0e B\x0e\x18B\x0e\x10B\x0e\b" +0x0002095f:108c02410e188603440e208304740a0e18410e10420e08460b18 "\x10\x8c\x02A\x0e\x18\x86\x03D\x0e \x83\x04t\n\x0e\x18A\x0e\x10B\x0e\bF\v\x18" -0x0002097c:042e "\x04." +0x0002097c:142b "\x14+" -0x00020980:6067 "g\xff\xffA\x01"
+0x00020980:5069 "Pi\xff\xff\x1c"
-0x00020984:4101 "A\x01"
+0x00020984:1c00 "\x1c"
-0x00020989:46 "F\x0e\x10\x8d\x02B\x0e\x18\x8c\x03A\x0e \x86\x04G\x0ep\x02\x8b\n\x0e A\x0e\x18B\x0e\x10B\x0e\bH\v"
+0x00020989:48 "H\x0e\x10N\n\x0e\bA\v"
-0x0002098c:8d02420e188c03410e208604470e70028b0a0e20410e18420e10420e08480b "\x8d\x02B\x0e\x18\x8c\x03A\x0e \x86\x04G\x0ep\x02\x8b\n\x0e A\x0e\x18B\x0e\x10B\x0e\bH\v"
+0x0002098c:4e0a0e08410b000010000000302b00005469ffff37000000000000001c0000 "N\n\x0e\bA\v"
+0x000209ac:442b "D+"
-0x000209b0:14000000 "\x14"
+0x000209b0:8069ffff "\x80i\xff\xff<"
-0x000209b5:2e "."
-0x000209b8:7868ffff330000000000000000 "xh\xff\xff3"
-0x000209c8:2c ","
+0x000209c8:34 "4"
-0x000209cc:542e "T."
+0x000209cc:642b "d+"
-0x000209d1:68 "h\xff\xffe"
+0x000209d1:69 "i\xff\xff\x8a"
-0x000209d4:65 "e"
+0x000209d4:8a "\x8a"
-0x000209e8:74 "t\n\x0e\x18A\x0e\x10B\x0e\bF\v"
+0x000209e8:7a "z\n\x0e\x18A\x0e\x10B\x0e\bH\v\n\x0e\x18A\x0e\x10B\x0e\bM\v\x1c" -0x000209f2:46 "F\v" +0x000209f2:48 "H\v\n\x0e\x18A\x0e\x10B\x0e\bM\v\x1c"
+0x000209f4:600a0e18410e10420e084d0b1c0000009c2b "\n\x0e\x18A\x0e\x10B\x0e\bM\v\x1c" +0x00020a08:f869ffff4800000000450e1086025e0a0e084d0b530e08 "\xf8i\xff\xffH" -0x00020a20:e068ffff3700 "\xe0h\xff\xff7" +0x00020a20:28000000bc2b "(" +0x00020a28:286affff73 "(j\xff\xffs" -0x00020a30:1c000000bc2e00000869ffff3c00000000480e10610a0e08470b4b0e08 "\x1c" -0x00020a50:3400 "4" +0x00020a50:e82b "\xe8+" -0x00020a54:dc2e00002869ffff8a00000000460e108c02410e188603440e2083047a0a "\xdc." +0x00020a54:7c6affff6500000000460e108f02490e188e03450e208d04450e288c0544 "|j\xff\xffe" -0x00020a73:18410e10420e08480b600a0e18410e10420e084d0b1c000000142f00008069ffff48 "\x18A\x0e\x10B\x0e\bH\v\n\x0e\x18A\x0e\x10B\x0e\bM\v\x1c"
+0x00020a73:308606480e388307470e406e0e38410e30410e28420e20420e18420e10420e080010 "0\x86\x06H\x0e8\x83\aG\x0e@n\x0e8A\x0e0A\x0e(B\x0e B\x0e\x18B\x0e\x10B\x0e\b"
+0x00020a98:302c0000a46affff05000000000000 "0,"
-0x00020aa8:2c ","
+0x00020aa8:14 "\x14"
-0x00020aac:342f "4/"
+0x00020aac:442c "D,"
-0x00020ab0:b069 "\xb0i\xff\xffs"
+0x00020ab0:a06a "\xa0j\xff\xff\x12"
-0x00020ab4:73 "s"
+0x00020ab4:12 "\x12"
-0x00020ab9:450e108602470e204e0a0e10440e084a0b02440a0e "E\x0e\x10\x86\x02G\x0e N\n\x0e\x10D\x0e\bJ\v\x02D\n\x0e\x10A\x0e\bA\v"
-0x00020acf:410e08410b0000 "A\x0e\bA\v"
+0x00020acf:011b0c07089001 "\x01\a\b\x90\x01"
-0x00020ad8:44 "D"
+0x00020ad8:24 "$"
-0x00020adc:642f "d/"
+0x00020adc:1c00 "\x1c"
+0x00020ae0:4035fe "@5\xfe\xff\xb0\x06"
-0x00020ae4:6500 "e"
+0x00020ae4:b006 "\xb0\x06"
-0x00020ae9:460e108f02490e188e03450e208d04450e288c05440e308606480e388307470e406e0e38410e30410e28420e20420e18420e10420e08 "F\x0e\x10\x8f\x02I\x0e\x18\x8e\x03E\x0e \x8d\x04E\x0e(\x8c\x05D\x0e0\x86\x06H\x0e8\x83\aG\x0e@n\x0e8A\x0e0A\x0e(B\x0e B\x0e\x18B\x0e\x10B\x0e\b"
+0x00020ae9:0e10460e184a0f0b770880003f1a3a2a332422000000001400000044000000c83bfeff300000000000000000000000100000005c0000 "\x0e\x10F\x0e\x18J\x0f\vw\b\x80"
-0x00020b20:14000000ac2f "\x14"
+0x00020b20:e03bfeffa006 "\xe0;\xfe\xff\xa0\x06"
-0x00020b28:286affff05 "(j\xff\xff\x05"
-0x00020b38:10 "\x10"
-0x00020b3c:c42f "\xc4/"
-0x00020b40:206affff12 " j\xff\xff\x12"
-0x00021010:b068 "\xb0h"
-0x00021018:7068 "ph"
-0x00021020:4073 "@s"
-0x00021028:a078 "\xa0x"
-0x00021030:5073 "Ps"
+0x00021030:b068 "\xb0h"
-0x00021038:6079 "y" +0x00021038:7068 "ph" -0x00021040:f06e "\xf0n" +0x00021040:3b73 ";s" +0x00021048:9b78 "\x9bx" +0x00021050:4b73 "Ks" -0x00021058:d0 "\xd0y" +0x00021058:5b "[y" -0x00021060:50c8 "P\xc8" +0x00021060:eb6e "\xebn" -0x00021068:30c9 "0\xc9" +0x00021068:fb78 "\xfbx" -0x00021070:c0c8 "\xc0\xc8" +0x00021070:fb6e "\xfbn" -0x00021078:f0c9 "\xf0\xc9" +0x00021078:cb79 "\xcby" -0x00021080:b0ca "\xb0\xca" +0x00021080:46c8 "F\xc8" -0x00021088:b0cb "\xb0\xcb" +0x00021088:26c9 "&\xc9" -0x00021090:30cb "0\xcb" +0x00021090:b6c8 "\xb6\xc8" -0x00021098:d07c "\xd0|" +0x00021098:e6c9 "\xe6\xc9" -0x000210a0:b0a5 "\xb0\xa5" +0x000210a0:a6ca "\xa6\xca" -0x000210a8:f0a5 "\xf0\xa5" +0x000210a8:a6cb "\xa6\xcb" -0x000210b0:70a7 "p\xa7" +0x000210b0:26cb "&\xcb" -0x000210b8:f0a6 "\xf0\xa6" +0x000210b8:cb7c "\xcb|" -0x000210c0:6078 "x"
+0x000210c0:aaa5 "\xaa\xa5"
-0x000210c8:70a6 "p\xa6"
+0x000210c8:eaa5 "\xea\xa5"
-0x000210d0:b0 "\xb0\xa7"
+0x000210d0:6a "j\xa7"
-0x000210d8:30a5 "0\xa5"
+0x000210d8:eaa6 "\xea\xa6"
-0x000210e0:8073 "\x80s"
+0x000210e0:5b78 "[x"
-0x000210e8:707c "p|"
+0x000210e8:6aa6 "j\xa6"
-0x000210f0:6073 "s" +0x000210f0:aaa7 "\xaa\xa7" +0x000210f8:2aa5 "*\xa5" +0x00021100:7b73 "{s" +0x00021108:6b7c "k|" +0x00021110:5b73 "[s" +0x00021118:fb7b "\xfb{" -0x00021120:b0c0 "\xb0\xc0" -0x00021128:10c2 "\x10\xc2" -0x00021130:f0c0 "\xf0\xc0" -0x00021138:20c3 " \xc3" -0x00021140:d0c4 "\xd0\xc4" +0x00021140:a6c0 "\xa6\xc0" -0x00021148:80a8 "\x80\xa8" +0x00021148:06c2 "\x06\xc2" -0x00021150:10c5 "\x10\xc5" +0x00021150:e6c0 "\xe6\xc0" -0x00021158:20c7 " \xc7" +0x00021158:16c3 "\x16\xc3" -0x00021160:60c0 "\xc0"
+0x00021160:c6c4 "\xc6\xc4"
-0x00021168:90c2 "\x90\xc2"
+0x00021168:7aa8 "z\xa8"
-0x00021170:c0bf "\xc0\xbf"
+0x00021170:06c5 "\x06\xc5"
-0x00021178:b0c3 "\xb0\xc3"
+0x00021178:16c7 "\x16\xc7"
-0x00021180:60c5 "\xc5" +0x00021180:56c0 "V\xc0" -0x00021188:f0a7 "\xf0\xa7" +0x00021188:86c2 "\x86\xc2" -0x00021190:40c6 "@\xc6" +0x00021190:b6bf "\xb6\xbf" -0x00021198:b0c7 "\xb0\xc7" +0x00021198:a6c3 "\xa6\xc3" -0x000211a0:40c1 "@\xc1" +0x000211a0:56c5 "V\xc5" -0x000211a8:50c4 "P\xc4" +0x000211a8:eaa7 "\xea\xa7" -0x000211b0:10c0 "\x10\xc0" +0x000211b0:36c6 "6\xc6" -0x000211b8:80c1 "\x80\xc1" +0x000211b8:a6c7 "\xa6\xc7" +0x000211c0:36c1 "6\xc1" -0x000211c8:807b "\x80{" +0x000211c8:46c4 "F\xc4" -0x000211d0:b0c5 "\xb0\xc5" +0x000211d0:06c0 "\x06\xc0" -0x000211d8:90c6 "\x90\xc6" +0x000211d8:76c1 "v\xc1" -0x000211e0:88c201 "\x88\xc2\x01" +0x000211e0:f6c500 "\xf6\xc5" -0x000211e8:129b01 "\x12\x9b\x01" +0x000211e8:7b7b00 "{{" -0x000211f0:169b01 "\x16\x9b\x01" +0x000211f0:a6c500 "\xa6\xc5" -0x000211f8:1c9b01 "\x1c\x9b\x01" +0x000211f8:86c600 "\x86\xc6" -0x00021200:229b "\"\x9b\x01" +0x00021200:88c2 "\x88\xc2\x01" -0x00021208:25 "%\x9b\x01" +0x00021208:12 "\x12\x9b\x01" -0x00021210:2a "*\x9b\x01" +0x00021210:16 "\x16\x9b\x01" -0x00021218:32 "2\x9b\x01" +0x00021218:1c "\x1c\x9b\x01" -0x00021220:2f "/\x9b\x01" +0x00021220:22 "\"\x9b\x01" +0x00021228:259b01 "%\x9b\x01" +0x00021230:2a9b01 "*\x9b\x01" +0x00021238:329b01 "2\x9b\x01" -0x00021240:36 "6\x9b\x01" +0x00021240:2f "/\x9b\x01" -0x00021248:bcbe01 "\xbc\xbe\x01" -0x00021250:3c9b01 "<\x9b\x01" -0x00021258:409b01 "@\x9b\x01" -0x00021260:46 "F\x9b\x01" +0x00021260:36 "6\x9b\x01" +0x00021268:bcbe01 "\xbc\xbe\x01" +0x00021270:3c9b01 "<\x9b\x01" +0x00021278:409b01 "@\x9b\x01" -0x00021280:25 "%\x9b\x01" +0x00021280:46 "F\x9b\x01" -0x00021288:b19901 "\xb1\x99\x01" -0x00021290:a39901 "\xa3\x99\x01" -0x00021298:4d9b01 "M\x9b\x01" -0x000212a0:cf97 "\xcf\x97\x01" +0x000212a0:259b "%\x9b\x01" +0x000212a8:b19901 "\xb1\x99\x01" +0x000212b0:a39901 "\xa3\x99\x01" +0x000212b8:4d9b01 "M\x9b\x01" -0x000212c0:579b "W\x9b\x01" +0x000212c0:cf97 "\xcf\x97\x01" -0x000212c8:5f9b01 "_\x9b\x01" -0x000212d0:649b01 "d\x9b\x01" -0x000212d8:6b9b01 "k\x9b\x01" -0x000212e0:76 "v\x9b\x01" +0x000212e0:57 "W\x9b\x01" -0x000212e8:7d "}\x9b\x01" +0x000212e8:5f "_\x9b\x01" -0x000212f0:86 "\x86\x9b\x01" +0x000212f0:64 "d\x9b\x01" +0x000212f8:6b9b01 "k\x9b\x01" -0x00021300:209c " \x9c\x01" +0x00021300:769b "v\x9b\x01" +0x00021308:7d9b01 "}\x9b\x01" +0x00021310:869b01 "\x86\x9b\x01" -0x00021318:61 "a" -0x00021320:74c2 "t\xc2\x01" +0x00021320:209c " \x9c\x01" -0x00021338:62 "b" +0x00021338:61 "a" -0x00021340:949b "\x94\x9b\x01" +0x00021340:74c2 "t\xc2\x01" -0x00021358:64 "d" +0x00021358:62 "b" -0x00021360:9e "\x9e\x9b\x01" +0x00021360:94 "\x94\x9b\x01" -0x00021378:44 "D" +0x00021378:64 "d" -0x00021380:a4 "\xa4\x9b\x01" +0x00021380:9e "\x9e\x9b\x01" -0x00021398:86 "\x86" +0x00021398:44 "D" -0x000213a0:ae "\xae\x9b\x01" +0x000213a0:a4 "\xa4\x9b\x01" -0x000213b8:87 "\x87" +0x000213b8:86 "\x86" -0x000213c0:c6 "\xc6\x9b\x01" +0x000213c0:ae "\xae\x9b\x01" -0x000213d8:68 "h" +0x000213d8:87 "\x87" -0x000213e0:d5 "\xd5\x9b\x01" +0x000213e0:c6 "\xc6\x9b\x01" -0x000213f8:69 "i" +0x000213f8:68 "h" -0x00021400:db "\xdb\x9b\x01" +0x00021400:d5 "\xd5\x9b\x01" -0x00021418:6b "k" +0x00021418:69 "i" -0x00021420:e5 "\xe5\x9b\x01" +0x00021420:db "\xdb\x9b\x01" -0x00021438:6e "n" +0x00021438:6b "k" -0x00021440:f5 "\xf5\x9b\x01" +0x00021440:e5 "\xe5\x9b\x01" -0x00021458:47 "G" +0x00021458:6e "n" -0x00021460:fe "\xfe\x9b\x01" +0x00021460:f5 "\xf5\x9b\x01" -0x00021478:71 "q" +0x00021478:47 "G" -0x00021480:119c "\x11\x9c\x01" +0x00021480:fe9b "\xfe\x9b\x01" -0x00021498:72 "r" +0x00021498:71 "q" -0x000214a0:a399 "\xa3\x99\x01" +0x000214a0:119c "\x11\x9c\x01" -0x000214b8:73 "s" +0x000214b8:72 "r" -0x000214c0:86 "\x86\x99\x01" +0x000214c0:a3 "\xa3\x99\x01" -0x000214c8:01 "\x01" -0x000214d8:77 "w" +0x000214d8:73 "s" -0x000214e0:199c "\x19\x9c\x01" +0x000214e0:8699 "\x86\x99\x01" +0x000214e8:01 "\x01" -0x000214f8:41 "A" +0x000214f8:77 "w" -0x00021500:24 "$\x9c\x01" +0x00021500:19 "\x19\x9c\x01" -0x00021518:42 "B" +0x00021518:41 "A" -0x00021520:33 "3\x9c\x01" +0x00021520:24 "$\x9c\x01" -0x00021538:46 "F" +0x00021538:42 "B" -0x00021540:3c "<\x9c\x01" +0x00021540:33 "3\x9c\x01" -0x00021558:84 "\x84" +0x00021558:46 "F" -0x00021560:46 "F\x9c\x01" +0x00021560:3c "<\x9c\x01" -0x00021578:8d "\x8d" +0x00021578:84 "\x84" -0x00021580:49 "I\x9c\x01" +0x00021580:46 "F\x9c\x01" -0x00021598:48 "H" +0x00021598:8d "\x8d" -0x000215a0:18be "\x18\xbe\x01" +0x000215a0:499c "I\x9c\x01" -0x000215b8:83 "\x83" +0x000215b8:48 "H" -0x000215c0:629c "b\x9c\x01" +0x000215c0:18be "\x18\xbe\x01" -0x000215c8:01 "\x01" -0x000215d8:88 "\x88" +0x000215d8:83 "\x83" -0x000215e0:67 "g\x9c\x01" +0x000215e0:62 "b\x9c\x01" -0x000215f8:49 "I" +0x000215f8:88 "\x88" -0x00021600:d599 "\xd5\x99\x01" +0x00021600:679c "g\x9c\x01" -0x00021618:8a "\x8a" +0x00021618:49 "I" -0x00021620:6e9c "n\x9c\x01" +0x00021620:d599 "\xd5\x99\x01" +0x00021628:01 "\x01" -0x00021638:4c "L" +0x00021638:8a "\x8a" -0x00021640:7a "z\x9c\x01" +0x00021640:6e "n\x9c\x01" -0x00021658:4e "N" +0x00021658:4c "L" -0x00021660:82 "\x82\x9c\x01" +0x00021660:7a "z\x9c\x01" -0x00021678:51 "Q" +0x00021678:4e "N" -0x00021680:e799 "\xe7\x99\x01" +0x00021680:829c "\x82\x9c\x01" -0x00021688:01 "\x01" -0x00021698:8b "\x8b" +0x00021698:51 "Q" -0x000216a0:8d9c "\x8d\x9c\x01" +0x000216a0:e799 "\xe7\x99\x01" +0x000216a8:01 "\x01" -0x000216b8:52 "R" +0x000216b8:8b "\x8b" -0x000216c0:b899 "\xb8\x99\x01" +0x000216c0:8d9c "\x8d\x9c\x01" -0x000216c8:01 "\x01" -0x000216d8:85 "\x85" +0x000216d8:52 "R" -0x000216e0:979c "\x97\x9c\x01" +0x000216e0:b899 "\xb8\x99\x01" +0x000216e8:01 "\x01" -0x000216f8:8c "\x8c" +0x000216f8:85 "\x85" -0x00021700:aa99 "\xaa\x99\x01" +0x00021700:979c "\x97\x9c\x01" -0x00021708:01 "\x01" -0x00021718:8e "\x8e" +0x00021718:8c "\x8c" -0x00021721:9c "\x9c\x01" +0x00021721:99 "\x99\x01" -0x00021738:54 "T" +0x00021738:8e "\x8e" -0x00021740:b199 "\xb1\x99\x01" +0x00021740:aa9c "\xaa\x9c\x01" -0x00021758:8f "\x8f" +0x00021758:54 "T" -0x00021760:b29c "\xb2\x9c\x01" +0x00021760:b199 "\xb1\x99\x01" -0x00021778:90 "\x90" +0x00021778:8f "\x8f" -0x00021780:c199 "\xc1\x99\x01" +0x00021780:b29c "\xb2\x9c\x01" -0x00021788:02 "\x02" +0x00021788:01 "\x01" -0x00021798:82 "\x82" +0x00021798:90 "\x90" -0x000217a0:c9 "\xc9\x99\x01" +0x000217a0:c1 "\xc1\x99\x01" -0x000217b8:89 "\x89" +0x000217b8:82 "\x82" -0x000217c0:bd9c "\xbd\x9c\x01" +0x000217c0:c999 "\xc9\x99\x01" -0x000217c8:01 "\x01" +0x000217c8:02 "\x02" -0x000217d8:81 "\x81" +0x000217d8:89 "\x89" -0x000217e0:c8 "\xc8\x9c\x01" +0x000217e0:bd "\xbd\x9c\x01" +0x000217e8:01 "\x01" -0x000217f8:5a "Z" +0x000217f8:81 "\x81" -0x00021800:d0 "\xd0\x9c\x01" +0x00021800:c8 "\xc8\x9c\x01" -0x00021818:80 "\x80" +0x00021818:5a "Z" -0x00021820:d7 "\xd7\x9c\x01" +0x00021820:d0 "\xd0\x9c\x01" -0x00021838:7effffff "~\xff\xff\xff" +0x00021838:80000000 "\x80" -0x00021840:cf97 "\xcf\x97\x01" +0x00021840:d79c "\xd7\x9c\x01" -0x00021858:7d "}\xff\xff\xff" +0x00021858:7e "~\xff\xff\xff" +0x00021860:cf9701 "\xcf\x97\x01" +0x00021878:7dffffff "}\xff\xff\xff" -0x00021880:469901 "F\x99\x01" -0x00021888:3b9d01 ";\x9d\x01" -0x00021890:3e9d01 ">\x9d\x01" -0x00021898:0e9c01 "\x0e\x9c\x01" -0x000218a0:229b "\"\x9b\x01" +0x000218a0:4699 "F\x99\x01" -0x000218a8:41 "A\x9d\x01" +0x000218a8:3b ";\x9d\x01" -0x000218b0:44 "D\x9d\x01" +0x000218b0:3e ">\x9d\x01" -0x000218b8:479d "G\x9d\x01" +0x000218b8:0e9c "\x0e\x9c\x01" -0x000218c0:4a9d "J\x9d\x01" +0x000218c0:229b "\"\x9b\x01" -0x000218c8:7d "}\x9d\x01" +0x000218c8:41 "A\x9d\x01" -0x000218d0:4d "M\x9d\x01" +0x000218d0:44 "D\x9d\x01" -0x000218d8:50 "P\x9d\x01" +0x000218d8:47 "G\x9d\x01" -0x000218e0:53 "S\x9d\x01" +0x000218e0:4a "J\x9d\x01" -0x000218e8:d49c "\xd4\x9c\x01" +0x000218e8:7d9d "}\x9d\x01" -0x000218f0:56 "V\x9d\x01" +0x000218f0:4d "M\x9d\x01" -0x000218f8:59 "Y\x9d\x01" +0x000218f8:50 "P\x9d\x01" -0x00021900:5c "\\\x9d\x01" +0x00021900:53 "S\x9d\x01" -0x00021908:5f9d "_\x9d\x01" +0x00021908:d49c "\xd4\x9c\x01" -0x00021910:c39b "\xc3\x9b\x01" +0x00021910:569d "V\x9d\x01" -0x00021918:62 "b\x9d\x01" +0x00021918:59 "Y\x9d\x01" -0x00021920:65 "e\x9d\x01" +0x00021920:5c "\\\x9d\x01" -0x00021928:68 "h\x9d\x01" +0x00021928:5f "_\x9d\x01" -0x00021930:6b9d "k\x9d\x01" +0x00021930:c39b "\xc3\x9b\x01" -0x00021938:6e "n\x9d\x01" +0x00021938:62 "b\x9d\x01" +0x00021940:659d01 "e\x9d\x01" +0x00021948:689d01 "h\x9d\x01" +0x00021950:6b9d01 "k\x9d\x01" +0x00021958:6e9d01 "n\x9d\x01" -0x00021960:259b01 "%\x9b\x01" -0x00021968:719d01 "q\x9d\x01" -0x00021970:3c9c01 "<\x9c\x01" -0x00021978:339c01 "3\x9c\x01" +0x00021980:259b01 "%\x9b\x01" +0x00021988:719d01 "q\x9d\x01" +0x00021990:3c9c01 "<\x9c\x01" +0x00021998:339c01 "3\x9c\x01" -0x000219a0:3d9901 "=\x99\x01" -0x000219a8:779d01 "w\x9d\x01" -0x000219b0:7c9d01 "|\x9d\x01" -0x000219b8:549901 "T\x99\x01" +0x000219c0:3d9901 "=\x99\x01" +0x000219c8:779d01 "w\x9d\x01" -0x000219d0:c69b "\xc6\x9b\x01" +0x000219d0:7c9d "|\x9d\x01" -0x000219d8:469c "F\x9c\x01" +0x000219d8:5499 "T\x99\x01" +0x000219f0:c69b01 "\xc6\x9b\x01" +0x000219f8:469c01 "F\x9c\x01" -0x00021a00:7a9c01 "z\x9c\x01" -0x00021a08:5bc201 "[\xc2\x01" -0x00021a10:61c201 "a\xc2\x01" -0x00021a18:6ec201 "n\xc2\x01" -0x00021a20:7bc2 "{\xc2\x01" +0x00021a20:7a9c "z\x9c\x01" -0x00021a28:eccc "\xec\xcc\x01" +0x00021a28:5bc2 "[\xc2\x01" -0x00021a30:8f "\x8f\xc2\x01" +0x00021a30:61 "a\xc2\x01" -0x00021a38:74 "t\xc2\x01" +0x00021a38:6e "n\xc2\x01" -0x00021a40:5499 "T\x99\x01" +0x00021a40:7bc2 "{\xc2\x01" -0x00021a48:97c2 "\x97\xc2\x01" +0x00021a48:eccc "\xec\xcc\x01" +0x00021a50:8fc201 "\x8f\xc2\x01" -0x00021a58:010000 "\x01" +0x00021a58:74c201 "t\xc2\x01" -0x00021a60:010000 "\x01" +0x00021a60:549901 "T\x99\x01" -0x00021a68:010000 "\x01" +0x00021a68:97c201 "\x97\xc2\x01" -0x00021a70:76 "v" -0x00021a78:0c "\f" +0x00021a78:01 "\x01" +0x00021a80:0100 "\x01" -0x00021a88:0d "\r" +0x00021a88:01 "\x01" -0x00021a90:747501 "tu\x01" +0x00021a90:ce0100 "\xce\x01" -0x00021aa0:10 "\x10 \x02" +0x00021aa0:30 "0 \x02" -0x00021ac0:18 "\x18 \x02" +0x00021ac0:38 "8 \x02" -0x00021ae0:a0 "\xa0\x03" +0x00021ae0:b8 "\xb8\x03" -0x00021af0:9011 "\x90\x11" +0x00021af0:8010 "\x80\x10" -0x00021b00:88 "\x88\x04" +0x00021b00:68 "h\x04" -0x00021b10:4c06 "L\x06" +0x00021b10:b405 "\xb4\x05" -0x00021b70:b82c "\xb8," +0x00021b70:f82a "\xf8*" -0x00021b80:6819 "h\x19" +0x00021b80:a817 "\xa8\x17" -0x00021bd0:f818 "\xf8\x18" +0x00021bd0:3817 "8\x17" -0x00021bf0:dc17 "\xdc\x17" +0x00021bf0:3416 "4\x16" -0x00021c58:58 "X*\x02" +0x00021c58:78 "x*\x02" -0x000221f0:d0 "\xd0\xd4" +0x000221f0:c6 "\xc6\xd4" -0x00022258:20 " D\x02" +0x00022258:80 "\x80D\x02" -0x00022260:60 "i\x01"
+0x00022260:41 "Ai\x01"
-0x00022268:31356164383336626533333339646563306532653661336336333765303865343861616362642e6465627567 "15ad836be3339dec0e2e6a3c637e08e48aacbd.debug"
-0x00022298:fb071937002e7368737472746162 "\xfb\a\x197"
-0x000222a7:2e696e74657270 ".interp"
-0x000222af:2e6e6f74652e676e752e70726f7065727479 ".note.gnu.property"
-0x000222c2:2e6e6f74652e676e752e6275696c642d6964 ".note.gnu.build-id"
-0x000222d5:2e6e6f74652e4142492d746167 ".note.ABI-tag"
-0x000222e3:2e676e752e68617368 ".gnu.hash"
-0x000222ed:2e64796e73796d ".dynsym"
-0x000222f5:2e64796e737472002e676e752e76657273696f6e ".dynstr"
-0x0002230a:2e676e752e76657273696f6e5f72002e72656c612e64796e ".gnu.version_r"
-0x00022323:2e72656c612e706c74002e696e6974 ".rela.plt"
-0x00022333:2e706c742e676f74 ".plt.got"
-0x0002233c:2e706c742e736563002e74657874 ".plt.sec"
-0x0002234b:2e66696e69 ".fini"
-0x00022351:2e726f64617461 ".rodata"
-0x00022359:2e65685f6672616d655f686472 ".eh_frame_hdr"
-0x00022367:2e65685f6672616d65 ".eh_frame"
-0x00022371:2e696e69745f6172726179 ".init_array"
-0x0002237d:2e66696e695f6172726179 ".fini_array"
-0x00022389:2e646174612e72656c2e726f ".data.rel.ro"
-0x00022396:2e64796e616d6963 ".dynamic"
-0x0002239f:2e64617461002e627373002e676e755f64656275676c696e6b ".data"
+0x000223bc:03 "\x03"
+0x000223be:0e "\x0e"
+0x000223c0:d046 "\xd0F"
+0x000223d4:03 "\x03"
+0x000223d6:0f "\x0f"
+0x000223d9:47 "G"
+0x000223ec:03 "\x03"
+0x000223ee:10 "\x10"
+0x000223f0:a04d "\xa0M"
-0x00022400:0b "\v"
-0x00022404:01 "\x01"
+0x00022404:03 "\x03"
+0x00022406:11 "\x11"
-0x00022408:020000 "\x02"
+0x00022408:647501 "du\x01"
-0x00022410:1803 "\x18\x03"
-0x00022418:1803 "\x18\x03"
+0x0002241c:03 "\x03"
+0x0002241e:12 "\x12"
-0x00022420:1c0000 "\x1c"
-0x00022430:01 "\x01"
+0x00022434:03 "\x03"
+0x00022436:13 "\x13"
+0x00022438:4cd201 "L\xd2\x01"
-0x00022440:13 "\x13"
-0x00022444:07 "\a"
-0x00022448:02 "\x02"
+0x0002244c:03 "\x03"
+0x0002244e:14 "\x14"
-0x00022450:380300 "8\x03"
+0x00022450:78db01 "x\xdb\x01"
-0x00022458:3803 "8\x03"
-0x00022460:20 " "
+0x00022464:03 "\x03"
+0x00022466:15 "\x15"
+0x00022468:302002 "0 \x02"
-0x00022470:08 "\b"
+0x0002247c:03 "\x03"
+0x0002247e:16 "\x16"
-0x00022480:260000 "&"
+0x00022480:382002 "8 \x02"
-0x00022484:07 "\a"
-0x00022488:02 "\x02"
-0x00022490:5803 "X\x03"
+0x00022494:03 "\x03"
+0x00022496:17 "\x17"
-0x00022498:580300 "X\x03"
+0x00022498:402002 "@ \x02"
-0x000224a0:24 "$"
+0x000224ac:03 "\x03"
+0x000224ae:18 "\x18"
-0x000224b0:040000 "\x04"
+0x000224b0:782a02 "x*\x02"
-0x000224c0:39 "9"
-0x000224c4:07 "\a"
+0x000224c4:03 "\x03"
+0x000224c6:19 "\x19"
-0x000224c8:020000 "\x02"
+0x000224c8:582c02 "X,\x02"
-0x000224d0:7c03 "|\x03"
-0x000224d8:7c03 "|\x03"
+0x000224dc:03 "\x03"
+0x000224de:1a "\x1a"
-0x000224e0:200000 " "
-0x000224f0:04 "\x04"
+0x000224f4:03 "\x03"
+0x000224f6:1b ""
+0x000224f8:803202 "\x802\x02"
-0x00022500:47 "G"
-0x00022504:f6ffff6f02 "\xf6\xff\xffo\x02"
+0x0002250c:04 "\x04"
+0x0002250e:f1ff0000 "\xf1\xff"
-0x00022518:a003 "\xa0\x03"
-0x00022520:e4 "\xe4"
+0x00022520:11 "\x11"
+0x00022524:02 "\x02"
+0x00022526:0c "\f"
-0x00022528:0600 "\x06"
-0x00022530:08 "\b"
+0x00022538:1a "\x1a"
+0x0002253c:02 "\x02"
+0x0002253e:10 "\x10"
-0x00022540:5100 "Q"
+0x00022540:a04d "\xa0M"
-0x00022544:0b "\v"
-0x00022548:02 "\x02"
-0x00022550:8804 "\x88\x04"
+0x00022550:2300 "#"
+0x00022554:02 "\x02"
+0x00022556:10 "\x10"
-0x00022558:8804 "\x88\x04"
+0x00022558:a54d "\xa5M"
-0x00022560:080d "\b\r"
-0x00022568:07 "\a"
+0x00022568:2c ","
-0x0002256c:01 "\x01"
+0x0002256c:02 "\x02"
+0x0002256e:10 "\x10"
-0x00022570:0800 "\b"
+0x00022570:aa4d "\xaaM"
-0x00022578:18 "\x18"
-0x00022580:59 "Y"
+0x00022580:35 "5"
-0x00022584:03 "\x03"
+0x00022584:02 "\x02"
+0x00022586:10 "\x10"
-0x00022588:0200 "\x02"
+0x00022588:af4d "\xafM"
-0x00022590:9011 "\x90\x11"
-0x00022598:9011 "\x90\x11"
+0x00022598:3e00 ">"
+0x0002259c:02 "\x02"
+0x0002259e:10 "\x10"
-0x000225a0:4c06 "L\x06"
+0x000225a0:b44d "\xb4M"
-0x000225b0:01 "\x01"
+0x000225b0:47 "G"
+0x000225b4:02 "\x02"
+0x000225b6:10 "\x10"
+0x000225b8:b94d "\xb9M"
-0x000225c0:61 "a"
-0x000225c4:ffffff6f02 "\xff\xff\xffo\x02"
+0x000225cc:02 "\x02"
+0x000225ce:10 "\x10"
-0x000225d0:dc17 "\xdc\x17"
+0x000225d0:be4d "\xbeM"
-0x000225d8:dc17 "\xdc\x17"
-0x000225e0:1601 "\x16\x01"
+0x000225e0:5900 "Y"
+0x000225e4:02 "\x02"
+0x000225e6:10 "\x10"
-0x000225e8:0600 "\x06"
+0x000225e8:c34d "\xc3M"
-0x000225f0:02 "\x02"
-0x000225f8:02 "\x02"
+0x000225f8:62 "b"
+0x000225fc:02 "\x02"
+0x000225fe:10 "\x10"
-0x00022600:6e00 "n"
+0x00022600:c84d "\xc8M"
-0x00022604:feffff6f02 "\xfe\xff\xffo\x02"
-0x00022610:f818 "\xf8\x18"
+0x00022610:6b00 "k"
+0x00022614:02 "\x02"
+0x00022616:10 "\x10"
-0x00022618:f818 "\xf8\x18"
+0x00022618:cd4d "\xcdM"
-0x00022620:70 "p"
-0x00022628:07 "\a"
+0x00022628:74 "t"
-0x0002262c:01 "\x01"
+0x0002262c:02 "\x02"
+0x0002262e:10 "\x10"
-0x00022630:0800 "\b"
+0x00022630:d24d "\xd2M"
-0x00022644:04 "\x04"
+0x00022644:02 "\x02"
+0x00022646:10 "\x10"
-0x00022648:0200 "\x02"
+0x00022648:d74d "\xd7M"
-0x00022650:6819 "h\x19"
-0x00022658:6819 "h\x19"
+0x00022658:8600 "\x86"
+0x0002265c:02 "\x02"
+0x0002265e:10 "\x10"
-0x00022660:5013 "P\x13"
+0x00022660:dc4d "\xdcM"
-0x00022668:06 "\x06"
-0x00022670:08 "\b"
+0x00022670:8f "\x8f"
+0x00022674:02 "\x02"
+0x00022676:10 "\x10"
-0x00022678:1800 "\x18"
+0x00022678:e14d "\xe1M"
-0x00022680:87 "\x87"
-0x00022684:04 "\x04"
-0x00022688:42 "B"
+0x00022688:98 "\x98"
+0x0002268c:02 "\x02"
+0x0002268e:10 "\x10"
-0x00022690:b82c "\xb8,"
+0x00022690:e64d "\xe6M"
-0x00022698:b82c "\xb8,"
-0x000226a0:f009 "\xf0\t"
+0x000226a0:a100 "\xa1"
+0x000226a4:02 "\x02"
+0x000226a6:10 "\x10"
-0x000226a8:0600 "\x06"
+0x000226a8:eb4d "\xebM"
-0x000226ac:19 "\x19"
-0x000226b0:08 "\b"
-0x000226b8:18 "\x18"
+0x000226b8:aa "\xaa"
+0x000226bc:02 "\x02"
+0x000226be:10 "\x10"
-0x000226c0:910000 "\x91"
+0x000226c0:bd3201 "\xbd2\x01"
-0x000226c4:01 "\x01"
-0x000226c8:06 "\x06"
+0x000226d0:b400 "\xb4"
+0x000226d4:02 "\x02"
+0x000226d6:10 "\x10"
+0x000226d8:d6df "\xd6\xdf"
-0x000226e0:1b ""
+0x000226e8:bd "\xbd"
+0x000226ec:02 "\x02"
+0x000226ee:10 "\x10"
-0x000226f0:040000 "\x04"
+0x000226f0:507501 "Pu\x01"
-0x00022700:8c "\x8c"
+0x00022700:c7 "\xc7"
-0x00022704:01 "\x01"
+0x00022704:02 "\x02"
+0x00022706:10 "\x10"
-0x00022708:060000 "\x06"
+0x00022708:a84801 "\xa8H\x01"
-0x00022710:2040 " @"
-0x00022718:2040 " @"
+0x00022718:d100 "\xd1"
+0x0002271c:02 "\x02"
+0x0002271e:10 "\x10"
-0x00022720:b006 "\xb0\x06"
+0x00022720:d6d4 "\xd6\xd4"
-0x00022730:10 "\x10"
+0x00022730:da "\xda"
+0x00022734:02 "\x02"
+0x00022736:10 "\x10"
-0x00022738:100000 "\x10"
+0x00022738:975d01 "\x97]\x01"
-0x00022740:97 "\x97"
-0x00022744:01 "\x01"
-0x00022748:06 "\x06"
+0x00022748:e4 "\xe4"
+0x0002274c:02 "\x02"
+0x0002274e:10 "\x10"
-0x00022750:d04600 "\xd0F"
+0x00022750:884801 "\x88H\x01"
-0x00022758:d046 "\xd0F"
-0x00022760:30 "0"
+0x00022760:ee "\xee"
+0x00022764:02 "\x02"
+0x00022766:10 "\x10"
+0x00022768:a6d7 "\xa6\xd7"
-0x00022770:10 "\x10"
-0x00022778:10 "\x10"
+0x00022778:f7 "\xf7"
+0x0002277c:02 "\x02"
+0x0002277e:10 "\x10"
-0x00022780:a00000 "\xa0"
+0x00022780:a75801 "\xa7X\x01"
-0x00022784:01 "\x01"
-0x00022788:06 "\x06"
+0x00022790:0101 "\x01\x01"
+0x00022794:02 "\x02"
+0x00022796:10 "\x10"
+0x00022798:d60901 "\xd6\t\x01"
-0x000227a0:a006 "\xa0\x06"
+0x000227a8:0b01 "\v\x01"
+0x000227ac:02 "\x02"
+0x000227ae:10 "\x10"
-0x000227b0:1000 "\x10"
+0x000227b0:ab6b "\xabk"
-0x000227b8:10 "\x10"
-0x000227c0:a900 "\xa9"
+0x000227c0:1401 "\x14\x01"
-0x000227c4:01 "\x01"
+0x000227c4:02 "\x02"
+0x000227c6:10 "\x10"
-0x000227c8:060000 "\x06"
+0x000227c8:285001 "(P\x01"
-0x000227d0:a04d "\xa0M"
-0x000227d8:a04d "\xa0M"
+0x000227d8:1e01 "\x1e\x01"
+0x000227dc:02 "\x02"
+0x000227de:10 "\x10"
-0x000227e0:d227 "\xd2'\x01"
+0x000227e0:575b "W[\x01"
-0x000227f0:1000 "\x10"
+0x000227f0:2801 "(\x01"
+0x000227f4:02 "\x02"
+0x000227f6:10 "\x10"
+0x000227f8:375701 "7W\x01"
-0x00022800:af "\xaf"
-0x00022804:01 "\x01"
-0x00022808:0600 "\x06"
+0x00022808:3201 "2\x01"
+0x0002280c:02 "\x02"
+0x0002280e:10 "\x10"
-0x00022810:7475 "tu\x01"
+0x00022810:4848 "HH\x01"
-0x00022818:747501 "tu\x01"
-0x00022820:0d00 "\r"
+0x00022820:3c01 "<\x01"
+0x00022824:02 "\x02"
+0x00022826:10 "\x10"
+0x00022828:c84801 "\xc8H\x01"
-0x00022830:04 "\x04"
+0x00022838:4601 "F\x01"
+0x0002283c:02 "\x02"
+0x0002283e:10 "\x10"
-0x00022840:b500 "\xb5"
+0x00022840:46eb "F\xeb"
-0x00022844:01 "\x01"
-0x00022848:02 "\x02"
+0x00022850:4f0100 "O\x01"
+0x00022854:02 "\x02"
+0x00022856:10 "\x10"
+0x00022858:2b6b00 "+k"
-0x00022860:4952 "IR"
+0x00022868:5801 "X\x01"
+0x0002286c:02 "\x02"
+0x0002286e:10 "\x10"
-0x00022870:2000 " "
+0x00022870:d068 "\xd0h"
-0x00022880:bd00 "\xbd"
+0x00022880:6101 "a\x01"
-0x00022884:01 "\x01"
+0x00022884:02 "\x02"
+0x00022886:10 "\x10"
-0x00022888:0200 "\x02"
+0x00022888:c068 "\xc0h"
-0x00022890:4cd201 "L\xd2\x01"
-0x00022898:4cd201 "L\xd2\x01"
+0x00022898:6a0100 "j\x01"
+0x0002289c:02 "\x02"
+0x0002289e:10 "\x10"
-0x000228a0:2c09 ",\t"
+0x000228a0:b6f4 "\xb6\xf4"
-0x000228b0:0400 "\x04"
+0x000228b0:7301 "s\x01"
+0x000228b4:02 "\x02"
+0x000228b6:10 "\x10"
+0x000228b8:406d01 "@m\x01"
-0x000228c0:cb "\xcb"
-0x000228c4:01 "\x01"
-0x000228c8:0200 "\x02"
+0x000228c8:7d01 "}\x01"
+0x000228cc:02 "\x02"
+0x000228ce:10 "\x10"
-0x000228d0:78db01 "x\xdb\x01"
+0x000228d0:6b6f00 "ko"
-0x000228d8:78db01 "x\xdb\x01"
-0x000228e0:d82f "\xd8/"
+0x000228e0:8601 "\x86\x01"
+0x000228e4:02 "\x02"
+0x000228e6:10 "\x10"
+0x000228e8:caa9 "\xca\xa9"
-0x000228f0:08 "\b"
+0x000228f8:8f01 "\x8f\x01"
+0x000228fc:02 "\x02"
+0x000228fe:10 "\x10"
-0x00022900:d500 "\xd5"
+0x00022900:bab8 "\xba\xb8"
-0x00022904:0e "\x0e"
-0x00022908:03 "\x03"
-0x00022910:102002 "\x10 \x02"
+0x00022910:980100 "\x98\x01"
+0x00022914:02 "\x02"
+0x00022916:10 "\x10"
-0x00022918:101002 "\x10\x10\x02"
+0x00022918:f6fb00 "\xf6\xfb"
-0x00022920:08 "\b"
+0x00022928:a101 "\xa1\x01"
+0x0002292c:02 "\x02"
+0x0002292e:10 "\x10"
-0x00022930:0800 "\b"
+0x00022930:16f0 "\x16\xf0"
-0x00022938:08 "\b"
-0x00022940:e100 "\xe1"
+0x00022940:aa01 "\xaa\x01"
-0x00022944:0f "\x0f"
+0x00022944:02 "\x02"
+0x00022946:10 "\x10"
-0x00022948:0300 "\x03"
+0x00022948:76f6 "v\xf6"
-0x00022950:182002 "\x18 \x02"
-0x00022958:181002 "\x18\x10\x02"
+0x00022958:b30100 "\xb3\x01"
+0x0002295c:02 "\x02"
+0x0002295e:10 "\x10"
-0x00022960:0800 "\b"
+0x00022960:7b6e "{n"
-0x00022970:0800 "\b"
+0x00022970:bc01 "\xbc\x01"
+0x00022974:02 "\x02"
+0x00022976:10 "\x10"
-0x00022978:0800 "\b"
+0x00022978:5b80 "[\x80"
-0x00022980:ed "\xed"
-0x00022984:01 "\x01"
-0x00022988:0300 "\x03"
+0x00022988:c501 "\xc5\x01"
+0x0002298c:02 "\x02"
+0x0002298e:10 "\x10"
-0x00022990:202002 " \x02"
+0x00022990:bb7d00 "\xbb}"
-0x00022998:201002 " \x10\x02"
-0x000229a0:380a "8\n"
+0x000229a0:ce01 "\xce\x01"
+0x000229a4:02 "\x02"
+0x000229a6:10 "\x10"
+0x000229a8:f75a01 "\xf7Z\x01"
-0x000229b0:20 " "
+0x000229b8:d801 "\xd8\x01"
+0x000229bc:02 "\x02"
+0x000229be:10 "\x10"
-0x000229c0:fa00 "\xfa"
+0x000229c0:1069 "\x10i"
-0x000229c4:06 "\x06"
-0x000229c8:03 "\x03"
-0x000229d0:582a02 "X*\x02"
+0x000229d0:e10100 "\xe1\x01"
+0x000229d4:02 "\x02"
+0x000229d6:10 "\x10"
-0x000229d8:581a02 "X\x1a\x02"
+0x000229d8:7b7100 "{q"
-0x000229e1:02 "\x02"
-0x000229e8:0700 "\a"
+0x000229e8:ea01 "\xea\x01"
+0x000229ec:02 "\x02"
+0x000229ee:10 "\x10"
-0x000229f0:0800 "\b"
+0x000229f0:9ba1 "\x9b\xa1"
-0x000229f8:10 "\x10"
-0x00022a00:9b00 "\x9b"
+0x00022a00:f301 "\xf3\x01"
-0x00022a04:01 "\x01"
+0x00022a04:02 "\x02"
+0x00022a06:10 "\x10"
-0x00022a08:030000 "\x03"
+0x00022a08:b75c01 "\xb7\\x01"
-0x00022a10:582c02 "X,\x02"
-0x00022a18:581c02 "X\x1c\x02"
+0x00022a18:fd0100 "\xfd\x01"
+0x00022a1c:02 "\x02"
+0x00022a1e:10 "\x10"
-0x00022a20:a003 "\xa0\x03"
+0x00022a20:eb75 "\xebu"
-0x00022a30:0800 "\b"
+0x00022a30:0602 "\x06\x02"
+0x00022a34:02 "\x02"
+0x00022a36:10 "\x10"
-0x00022a38:0800 "\b"
+0x00022a38:2b6c "+l"
-0x00022a40:0301 "\x03\x01"
-0x00022a44:01 "\x01"
-0x00022a48:0300 "\x03"
+0x00022a48:0f02 "\x0f\x02"
+0x00022a4c:02 "\x02"
+0x00022a4e:10 "\x10"
+0x00022a50:3b6b00 ";k"
-0x00022a59:2002 " \x02"
-0x00022a60:68 "h\x02"
+0x00022a60:18 "\x18\x02"
+0x00022a64:02 "\x02"
+0x00022a66:10 "\x10"
+0x00022a68:8b73 "\x8bs"
-0x00022a70:20 " "
+0x00022a78:2102 "!\x02"
+0x00022a7c:02 "\x02"
+0x00022a7e:10 "\x10"
-0x00022a80:0901 "\t\x01"
+0x00022a80:96cc "\x96\xcc"
-0x00022a84:08 "\b"
-0x00022a88:03 "\x03"
-0x00022a90:803202 "\x802\x02"
+0x00022a90:2a0200 "*\x02"
+0x00022a94:02 "\x02"
+0x00022a96:10 "\x10"
-0x00022a98:682202 "h"\x02"
+0x00022a98:e6d500 "\xe6\xd5"
-0x00022aa0:d812 "\xd8\x12"
+0x00022aa8:3302 "3\x02"
+0x00022aac:02 "\x02"
+0x00022aae:10 "\x10"
-0x00022ab0:200000 " "
+0x00022ab0:175b01 "\x17[\x01"
-0x00022ac0:0e01 "\x0e\x01"
+0x00022ac0:3d02 "=\x02"
-0x00022ac4:01 "\x01"
+0x00022ac4:02 "\x02"
+0x00022ac6:10 "\x10"
+0x00022ac8:546201 "Tb\x01"
-0x00022ad8:682202 "h"\x02"
+0x00022ad8:470200 "G\x02"
+0x00022adc:02 "\x02"
+0x00022ade:10 "\x10"
-0x00022ae0:340000 "4"
+0x00022ae0:407501 "@U\x01"
-0x00022af0:0400 "\x04"
+0x00022af0:5102 "Q\x02"
+0x00022af4:02 "\x02"
+0x00022af6:10 "\x10"
+0x00022af8:d07401 "\xd0t\x01"
-0x00022b00:01 "\x01"
-0x00022b04:03 "\x03"
+0x00022b08:5b02 "[\x02"
+0x00022b0c:02 "\x02"
+0x00022b0e:10 "\x10"
+0x00022b11:68 "h"
-0x00022b18:9c2202 "\x9c"\x02"
-0x00022b20:1d01 "\x1d\x01"
+0x00022b20:6402 "d\x02"
+0x00022b24:02 "\x02"
+0x00022b26:10 "\x10"
+0x00022b28:7068 "ph"
-0x00022b30:01 "\x01"
+0x00022b38:7a02 "z\x02"
+0x00022b3c:02 "\x02"
+0x00022b3e:10 "\x10"

and much more differences on the top.

Ideally I would like to have no difference with the original binary with diff ls ls-out.

cons.asm:25375:13: error: unknown use of instruction mnemonic without a size suffix
jmp $L_14001135e
^
cons.asm:25378:13: error: unknown use of instruction mnemonic without a size suffix
mov R8,R15
^
cons.asm:25379:27: error: unexpected token in argument list
lea RCX,QWORD PTR [RSP+72]
^
cons.asm:25380:13: error: unknown use of instruction mnemonic without a size suffix
mov RDX,RDI
^
cons.asm:25383:13: error: unknown use of instruction mnemonic without a size suffix
cmp EAX,-1
^
cons.asm:25384:16: error: invalid operand for instruction
je $L_14001139b
^~~~~~~~~~~~

There seem to be packages for focal but the readme is outdated.
A docker container with preinstalled ddisasm could also be useful.

$ docker run --rm -it ubuntu
apt update && apt install -y ca-certificates 
echo "deb [trusted=yes] https://grammatech.github.io/gtirb/pkgs/focal ./" > /etc/apt/sources.list.d/gtirb.list
apt update && apt install -y ddisasm

Hello,
I have disassembled a simple hello binary using gtrib with the below commands.

ddisasm hello --asm hello.s

Also, I have generated hello.gtrib using the below command.

ddisasm hello --ir hello.gtrib

Now, I am not able to open or view hello.gtrib. sometimes I noticed here in the issue section there is a way to convert back to LLVM-IR or opening in some form.

Could you please help me how to see or convert hello.gtrib IR

Thanks in advance.

#include <stdio.h>
#include <stdlib.h>
struct foo {
    int x;
    char y;
} ga[10];

void bar() {
    for (int i = 0; i < 10; i++) {
        ga[i].x = 1;
        ga[i].y = 2;
    }
    for (size_t i = 0; i < 10; i++)
    {
        printf("%d %d\n", ga[i].x, ga[i].y);
    }
}

int main() {
    bar();
}

For the above C code, ddisasm will split the global struct array into two datablocks, one is of size 4 and the other is of size 76. I can understand why it results in such behavior, but can this be improved?

#-----------------------------------
.globl FUN_4011e0
.type FUN_4011e0, @function
#-----------------------------------
FUN_4011e0:

.cfi_startproc 
.cfi_lsda 255
.cfi_personality 255
.cfi_def_cfa 7, 8
.cfi_offset 16, -8
            push RBP
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
            mov RBP,RSP
.cfi_def_cfa_register 6
            sub RSP,16
            mov DWORD PTR [RBP-4],0
.L_4011ef:

            cmp DWORD PTR [RBP-4],10
            jge .L_401222

            movsxd RAX,DWORD PTR [RBP-4]
            mov DWORD PTR [RAX*8+.L_404050],1
            movsxd RAX,DWORD PTR [RBP-4]
            mov BYTE PTR [RAX*8+.L_404054],2
            mov EAX,DWORD PTR [RBP-4]
            add EAX,1
            mov DWORD PTR [RBP-4],EAX
            jmp .L_4011ef
.L_401222:

            mov QWORD PTR [RBP-16],0
.L_40122a:

            cmp QWORD PTR [RBP-16],10
            jae .L_40126e

            mov RAX,QWORD PTR [RBP-16]
            mov ESI,DWORD PTR [RAX*8+.L_404050]
            mov RAX,QWORD PTR [RBP-16]
            movsx EDX,BYTE PTR [RAX*8+.L_404054]
            movabs RDI,OFFSET .L_402004
            mov AL,0
            call printf@PLT

            mov RAX,QWORD PTR [RBP-16]
            add RAX,1
            mov QWORD PTR [RBP-16],RAX
            jmp .L_40122a
.L_40126e:

            add RSP,16
            pop RBP
.cfi_def_cfa 7, 8
            ret 
.cfi_endproc 


.align 16
.L_404040:
          .zero 16
.L_404050:
          .zero 4
.L_404054:
          .zero 76

The paper is called Ramblr: Making reassembly great again not Ramblr: Making disassembly great again

https://grammatech.github.io/gtirb/pkgs/xenial/libcapstone-dev_4.0.1-gt3_amd64.deb is missing.

RUN wget https://grammatech.github.io/gtirb/pkgs/xenial/libcapstone-dev_4.0.1-gt3_amd64.deb   && dpkg -i libcapstone-dev_*_amd64.deb   && rm libcapstone-dev_*_amd64.deb:
#38 0.267 --2021-06-02 17:16:11--  https://grammatech.github.io/gtirb/pkgs/xenial/libcapstone-dev_4.0.1-gt3_amd64.deb
#38 0.268 Resolving grammatech.github.io (grammatech.github.io)... 185.199.108.153, 185.199.109.153, 185.199.110.153, ...
#38 0.318 Connecting to grammatech.github.io (grammatech.github.io)|185.199.108.153|:443... connected.
#38 0.356 HTTP request sent, awaiting response... 404 Not Found
#38 0.405 2021-06-02 17:16:11 ERROR 404: Not Found.
#38 0.405

Hi, I'm curious about how to get the ground truth for binaries compiled by icc, specifically, how to correctly distinguish the jump table from the code section?

Hi :
I am trying to print the gtirb file generated by ddisasm to asm file, it used to work well but now always printed as blank after I both upgrade ddisasm and pprinter. I also tried --asm flag, asm file is printed normally
my ddisasm version is 1.5.3 (UNKNOWN 2022-04-28)
my gtirb-pprinter version is 1.8.3 (UNKNOWN 2022-04-27)

the generated gtirb file is here
https://drive.google.com/file/d/1TVv0X-LGag1nIrpozvk81f8h8jNy10FV/view?usp=sharing

Hi, I want to use ddisasm to analyze one simple .o file, but it shows that the file could not be disassembled.
I am wondering how to solve this issue?
Thanks!

Hello~

I have a simple question about the compilation process. When I compile the ddisasm that I cloned from Github, it will spend more than an hour. And once I modified something in symbolization.dl (add an output), it will also spend more than an hour to compile... I am wondering if this is a common case?

Thanks for answering.

Hi,

Thanks for your great efforts of bringing datalog disassembly to the community.

I am trying to make ddisasm a disassembly backend of my own project, where the instruction boundaries of the original ELF are needed (i.e., the disassembly result). I am wondering whether ddisasm can directly output the disassembly results (like what ghidra/IDA Pro does), or some coding upon the codebase is required.

Thanks!

(Ran on Ubuntu 18.04, and also ran the test on Windows 11)

After running any PE binary (32 or 64 bit) through ddisasm, and getting the resulting .gtirb, I go to use gtirb-pprinter to reassemble the .exe but always get the same error: "lib.exe: command not found". Additionally I also get "ml64.exe: command not found". Is this a related issue?

How do I fix this?

I am unable to reassemble "ls" using ddisasm and gtirb-pprinter on Ubuntu 22.
I am using the grammatech/ddisasm docker image. ddisasm is version 1.6.0 and gtirb-pprinter is version 1.9.0.

When I try to (re)assemble the assembly generated by ddisasm for the "ls" utility, the rewritten binary segfaults.

Commands to reproduce:
Generate GTIRB file
$ docker run --rm -v $(pwd):/workspace grammatech/ddisasm sh -c "ddisasm /workspace/ls --ir /workspace/out.gtirb"

Generate assembly
$ docker run --rm -v $(pwd):/workspace grammatech/ddisasm sh -c "gtirb-pprinter /workspace/out.gtirb --asm /workspace/out.s"

Assemble
$ gcc -nostartfiles out.s -o out -lselinux

Resulting binary will segfault

$ ./ls
commands.txt  core.406367  core.412298  core.412544  ls  out  out.gtirb  out.s
$ ./out
[1]    7294 segmentation fault (core dumped)  ./out

Looking at the stack trace from the core dump in GDB shows:

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007f724ca29ebb in call_init (env=<optimised out>, argv=0x7ffd75a6c418, argc=1) at ../csu/libc-start.c:145
#2  __libc_start_main_impl (main=0x5579fe24fd20 <main>, argc=1, argv=0x7ffd75a6c418, init=<optimised out>, fini=<optimised out>,
    rtld_fini=<optimised out>, stack_end=0x7ffd75a6c408) at ../csu/libc-start.c:379
#3  0x00005579fe251ad5 in _start ()

So the rewritten binary is crashing before main is reached.

I tried to disassemble a big binary file. Just outputting the assembly took me more than half an hour on a single core; when I wanted to disassemble it with a debug-dir, even with 96 cores, it runs more than two hours and seems not going to stop very soon. What is the right way to get the function boundaries? Is it slow because of the debug-dir option or the multi-thread setting?

I am trying to reassemble x86 binary with latest ddisasm (grammatech/ddisasm:1.5.2).
However, I could not recompile the reassembled code since ddisasm does not create main symbol.

I reassembled a toy program (hello.c) as follows.

$ cat hello.c
#include <stdio.h>
int main()
{
    printf("hello world\n");
    return 0;
}
$ gcc hello.c -m32 -o hello_32
$ strip hello_32

$ sudo docker run --rm -v /home/test/test/:/test grammatech/ddisasm:1.5.2 sh -c "ddisasm /test/hello_32 --asm /test/hello_32.s"
Building the initial gtirb representation  (3ms)
Decoding the binary  (5ms)
Disassembling (20ms)
Populating gtirb representation  (5ms)
Computing intra-procedural SCCs  (0ms)
Computing no return analysis  (0ms)
Detecting additional functions  (1ms)
Printing assembler  (9ms)

I got the following errors.

$ gcc hello_32.s -m32
/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib32/Scrt1.o: In function `_start':
(.text+0x28): undefined reference to `main'
collect2: error: ld returned 1 exit status

I hope ddisasm fixes this bug soon.

Hello Everyone
Can ddisasm be applied to Risc-V binaries to generate relocatable-assembly code and perform CFG analysis etc...?

Thanking you
Sai

With the --self-diagnose arg, I'm seeing this message in my (rather big binary):

Perfoming self diagnose (this will only give the right results if the target program contains all the relocation information)
False positives: 302
False negatives: 12

1. Should I be worried about that many errors? What should we do about it?
2. How should I ensure that I have the required relocation information with gcc ?

The link to http://www.stonecat.com/repos/reading/papers/12313-sec13-paper_zhang.pdf results in a 404 error page.