See screenshot below. Can be reproduced with electron.exe, file size: about 120 MB.

Hello. You need to update the reference to protobuf, because currently selected version trying to download gmock files from https://googlemock.googlecode.com/files/gmock-1.7.0.zip, but it's an invalid link now.

Tried to build the plugin but got the following error:

> Task :generateProto FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':generateProto'.
> protoc: stdout: . stderr: [libprotobuf WARNING T:\src\github\protobuf\src\google\protobuf\compiler\parser.cc:646] No syntax specified for the proto file: binexport2.proto. Please use 'syntax = "proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
  binexport2.proto:1:1: Expected top-level statement (e.g. "message").

More info on this error : here

Is there a version of BinDiff that can read a .BinExport file from the current version of BinExport? I believe BinDiff 4.2 and 4.3 cannot. Thank you.

I run binnavi in ubuntu16.04_x64,but IDA pro is 6.4_x86,
who can help me? Thanks a lot

Building binexport on Windows 7, using MSVC 2015 with Ida-6.95 installed. I've copied the IDA-SDK. The build fails due to a missing file "ins/pc.hpp" which is included from "intel.hpp" (which is part of the IDASDK).

The error message is:

  C:\VStudio15\VC\bin\CL.exe /c /IC:\Users\Administrator\GNUHome\binexport /IC:\Users\Administrator\GNUHome\binexport\build_msvc /IC:\Users\Administrator\GNUHome\binexport\third_party\boost_parts /IC:\Users\Administrator\GNUHome\binexport\third_party\idasdk\include /IC:\Users\Administrator\GNUHome\b
inexport\build_msvc\OpenSSL\include /IC:\PostgreSQL\9.4\include /IC:\Users\Administrator\GNUHome\binexport\none /IC:\Users\Administrator\GNUHome\binexport\third_party\protobuf\src /nologo /W3 /WX- /O2 /Ob2 /Oy- /D WIN32 /D _WINDOWS /D NDEBUG /D __NT__ /D __IDP__ /D USE_DANGEROUS_FUNCTIONS /D USE_STA
NDARD_FILE_FUNCTIONS /D NDEBUG /D "CMAKE_INTDIR=\"Release\"" /D zynamics_binexport_9_plw_EXPORTS /D _WINDLL /D _MBCS /Gm- /EHsc /MT /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /GR /Fo"zynamics_binexport_9.plw.dir\Release\\" /Fd"zynamics_binexport_9.plw.dir\Release\vc140.pdb" /Gd /TP /analyze
- /errorReport:queue C:\Users\Administrator\GNUHome\binexport\ida\metapc.cc
  metapc.cc
C:\Users\Administrator\GNUHome\binexport\third_party\idasdk\include\typeinf.hpp(2658): warning C4267: 'return': conversion from 'size_t' to 'type_t', possible loss of data [C:\Users\Administrator\GNUHome\binexport\build_msvc\zynamics_binexport_9.plw.vcxproj]
C:\Users\Administrator\GNUHome\binexport\third_party\idasdk\include\typeinf.hpp(2691): warning C4267: 'return': conversion from 'size_t' to 'uchar', possible loss of data [C:\Users\Administrator\GNUHome\binexport\build_msvc\zynamics_binexport_9.plw.vcxproj]
C:\Users\Administrator\GNUHome\binexport\third_party\idasdk\include\typeinf.hpp(2881): warning C4267: 'return': conversion from 'size_t' to 'cm_t', possible loss of data [C:\Users\Administrator\GNUHome\binexport\build_msvc\zynamics_binexport_9.plw.vcxproj]
C:\Users\Administrator\GNUHome\binexport\third_party\idasdk\include\typeinf.hpp(2951): warning C4267: 'return': conversion from 'size_t' to 'type_t', possible loss of data [C:\Users\Administrator\GNUHome\binexport\build_msvc\zynamics_binexport_9.plw.vcxproj]
C:\Users\Administrator\GNUHome\binexport\third_party\idasdk\include\intel.hpp(11): fatal error C1083: Cannot open include file: 'ins/pc.hpp': No such file or directory [C:\Users\Administrator\GNUHome\binexport\build_msvc\zynamics_binexport_9.plw.vcxproj]
Done Building Project "C:\Users\Administrator\GNUHome\binexport\build_msvc\zynamics_binexport_9.plw.vcxproj" (default targets) -- FAILED.
Done Building Project "C:\Users\Administrator\GNUHome\binexport\build_msvc\zynamics_binexport_9.plw.vcxproj.metaproj" (default targets) -- FAILED.
Done Building Project "C:\Users\Administrator\GNUHome\binexport\build_msvc\binexport.sln" (default targets) -- FAILED.

I can see in the Appveyor yml file that idasdk.zip.enc gets both decrypted and decompressed, but I'm not sure if that should be happening on my local system (seeing as how I already have IDA's SDK) or not. If not, I'm not sure what I missed, or where I can get the missing file.

Also, from the IDA-SDK readme it mentions:

intel.hpp header file from the ibm pc module.
for information only, it will not compile
because it contains references to internal files!

So I'm wondering why it is being included at all?
build_log.txt

Thanks.

i haved try to compile for IDA 6.8 on windows,but i failed,a bunch of errors. OSX compiled OK. anyone can provide windows version for download?

Not exactly a BinExport question, but what's the FortKnox format that's referenced to in /usr/local/google/home/cblichmann/devel/zyclient/google3/third_party/zynamics/bindiff/main_portable.cc? Is that the .BinDiff SQLite format?

Implement full expression trees for instructions, so that downstream consumers can display richer disassembly information.
The current minimal implementation simply adds the mnemonic and a single expression consisting of the rest of Ghidra's textual disassembly for the instruction.

Hello,

I am using IDA 7.3 on Linux and the latest version of Bindiff (Bindiff ver. 5 and BinExport 10). And I am writing to inquire the procedure to export a binExport database from the commandline.

So after installing the BinDiff and IDA-Pro, I am using the following command:

sudo ./idat64 -A -S"/export/d1/idaedu-7.3/bin_export.idc" -OExportModule:"/export/d1/idaedu-7.3/mcf.binExport" "/export/d1/idaedu-7.3/mcf_base.i386-m32-gcc42-nn.i64"

And the bin_export.idc script is like this:

#include <idc.idc>
static main()
{
        Batch(0);
        Wait();
        Exit(1 - RunPlugin("zynamics_binexport_8", 2));
}

However, after executing the command, somehow it is hanging there, and cannot proceed any further.. Am I doing anything wrong? Thank you.

I know you cannot install bindiff6 on Windows 7 only Window 8.1+.

I bypassed that check and still installed it on my Windows 7 machine.. It loads the extension in IDA PRO 7.5 without any issues.

All looked well until I ran BinDiff (still looks good)

Now when I do BinDiff (Diff Database (.idb)) the exporting of binexport works fine.. it takes about a minute and it does it job.. but something happens on the next step where it has to do the actual bindiffing.

see this error happens, why is this ? is this by design to not support windows 7? or is there some fix I can do to fix this issue?

The tool itself bindiff I ran in command prompt works good in Windows 7

I managed to load up the whole thing into the new graphs you see in screenshot #1 similar as it would run without the command prompt so it's fixable right? how do I do it. I really like this tool it's very handy and always exporting it to BinExports then running command line and loading up the BinDiff results into IDA is a bit too much work for me haha anyway around this?

Here is my shitty debugging attempt

Here are the broken codes I believe lol idk what it means

if I patch those checks for both to not jump to error.. I get new error.. can't find file size something I gave up lol

Here is my BinDiff.xml file

<?xml version="1.0"?>
<bindiff config-version="6">
  <!-- Settings not shown here are java-vm-options and max-heap-size-mb. When
       java-binary is empty or unset, BinDiff will try to auto-detect a
       suitable JVM.
    -->
  <ui server="127.0.0.1" port="2000" retries="20" directory="C:\Program Files\BinDiff\bin" java-binary="C:\Program Files\BinDiff\jre\bin\javaw.exe"/>
  <!-- The actual IDA Pro executable can be set with executable (for 32-bit
       addresses) and executable64 (for 64-bit).
    -->
  <ida directory="F:\Tools\IDA Decompilers\IDA Pro v7.5 (SP3)\"/>
  <!-- How many BinDiff threads to use when batch-diffing. Use "max-hw" for
       the number of hardware threads present in the system.
    -->
  <threads use="2"/>
  <!-- Minimum log level and settings. Levels are (in this order): "debug",
       "info", "warning", "error" and "off". Fatal errors are always logged.
    -->
  <log level="info" to-stderr="false" to-file="false" directory=""/>
  <function-matching>
    <!-- For documentation on the various algorithms, see the BinDiff manual
         at https://zynamics.com/bindiff/manual/index.html#N2038E.
      -->
    <step confidence="1.0" algorithm="function: name hash matching"/>
    <step confidence="1.0" algorithm="function: hash matching"/>
    <step confidence="1.0" algorithm="function: edges flowgraph MD index"/>
    <step confidence="0.9" algorithm="function: edges callgraph MD index"/>
    <step confidence="0.9" algorithm="function: MD index matching (flowgraph MD index, top down)"/>
    <step confidence="0.9" algorithm="function: MD index matching (flowgraph MD index, bottom up)"/>
    <step confidence="0.9" algorithm="function: prime signature matching"/>
    <step confidence="0.8" algorithm="function: MD index matching (callGraph MD index, top down)"/>
    <step confidence="0.8" algorithm="function: MD index matching (callGraph MD index, bottom up)"/>
    <!-- <step confidence="0.7" algorithm="function: edges proximity MD index" /> -->
    <step confidence="0.7" algorithm="function: relaxed MD index matching"/>
    <step confidence="0.4" algorithm="function: instruction count"/>
    <step confidence="0.4" algorithm="function: address sequence"/>
    <step confidence="0.7" algorithm="function: string references"/>
    <step confidence="0.6" algorithm="function: loop count matching"/>
    <step confidence="0.1" algorithm="function: call sequence matching(exact)"/>
    <step confidence="0.0" algorithm="function: call sequence matching(topology)"/>
    <step confidence="0.0" algorithm="function: call sequence matching(sequence)"/>
  </function-matching>
  <basic-block-matching>
    <!-- See https://zynamics.com/bindiff/manual/index.html#N20496 -->
    <step confidence="1.0" algorithm="basicBlock: edges prime product"/>
    <step confidence="1.0" algorithm="basicBlock: hash matching (4 instructions minimum)"/>
    <step confidence="0.9" algorithm="basicBlock: prime matching (4 instructions minimum)"/>
    <step confidence="0.8" algorithm="basicBlock: call reference matching"/>
    <step confidence="0.8" algorithm="basicBlock: string references matching"/>
    <step confidence="0.7" algorithm="basicBlock: edges MD index (top down)"/>
    <step confidence="0.7" algorithm="basicBlock: MD index matching (top down)"/>
    <step confidence="0.7" algorithm="basicBlock: edges MD index (bottom up)"/>
    <step confidence="0.7" algorithm="basicBlock: MD index matching (bottom up)"/>
    <step confidence="0.6" algorithm="basicBlock: relaxed MD index matching"/>
    <step confidence="0.5" algorithm="basicBlock: prime matching (0 instructions minimum)"/>
    <step confidence="0.4" algorithm="basicBlock: edges Lengauer Tarjan dominated"/>
    <step confidence="0.4" algorithm="basicBlock: loop entry matching"/>
    <step confidence="0.3" algorithm="basicBlock: self loop matching"/>
    <step confidence="0.2" algorithm="basicBlock: entry point matching"/>
    <step confidence="0.1" algorithm="basicBlock: exit point matching"/>
    <step confidence="0.0" algorithm="basicBlock: instruction count matching"/>
    <step confidence="0.0" algorithm="basicBlock: jump sequence matching"/>
  </basic-block-matching>
  <theme name="Google Material" based-on="">
    <!-- Google Material colors: Deep Orange (500) -> Google Yellow (A700) ->
         Light Green (A400)
         Generated with
         http://gka.github.io/palettes/#colors=#FF5722,#FF9E00,#84FA02|steps=256|bez=1|coL=1
      -->
    <!-- Color ramp for visualizing similarity in IDA and in the UI, exactly
         256 colors -->
    <ramp for="similarity">
      <c v="#ff5722"/><c v="#ff5722"/><c v="#ff5922"/><c v="#ff5922"/>
      <c v="#ff5a22"/><c v="#ff5b21"/><c v="#ff5b21"/><c v="#ff5c21"/>
      <c v="#ff5d21"/><c v="#ff5e21"/><c v="#ff5f21"/><c v="#ff5f21"/>
      <c v="#ff5f21"/><c v="#ff6120"/><c v="#ff6120"/><c v="#ff6220"/>
      <c v="#ff6220"/><c v="#ff6320"/><c v="#ff6420"/><c v="#ff6520"/>
      <c v="#ff661f"/><c v="#ff671f"/><c v="#ff661f"/><c v="#ff671f"/>
      <c v="#ff681f"/><c v="#ff691f"/><c v="#ff691f"/><c v="#ff6a1e"/>
      <c v="#ff6b1e"/><c v="#ff6c1e"/><c v="#fe6c1e"/><c v="#fe6d1e"/>
      <c v="#fe6f1e"/><c v="#fe6f1e"/><c v="#fe701d"/><c v="#fe711d"/>
      <c v="#fe701d"/><c v="#fe721d"/><c v="#fe721d"/><c v="#fe731d"/>
      <c v="#fe731d"/><c v="#fe741d"/><c v="#fd751c"/><c v="#fe751c"/>
      <c v="#fd761c"/><c v="#fd771c"/><c v="#fd771c"/><c v="#fd791b"/>
      <c v="#fd791b"/><c v="#fd7a1b"/><c v="#fd7a1b"/><c v="#fd7a1b"/>
      <c v="#fc7c1b"/><c v="#fc7d1b"/><c v="#fc7d1a"/><c v="#fc7e1a"/>
      <c v="#fc7f1a"/><c v="#fc7f1a"/><c v="#fc7f1a"/><c v="#fb811a"/>
      <c v="#fb8119"/><c v="#fb8119"/><c v="#fb8319"/><c v="#fb8219"/>
      <c v="#fb8419"/><c v="#fb8419"/><c v="#fa8518"/><c v="#fa8618"/>
      <c v="#fa8718"/><c v="#fa8718"/><c v="#fa8818"/><c v="#fa8718"/>
      <c v="#f98a17"/><c v="#f98917"/><c v="#f98b17"/><c v="#f98a17"/>
      <c v="#f98c17"/><c v="#f88d17"/><c v="#f88c17"/><c v="#f88d16"/>
      <c v="#f88e16"/><c v="#f78f16"/><c v="#f79016"/><c v="#f79015"/>
      <c v="#f79115"/><c v="#f79215"/><c v="#f69215"/><c v="#f69215"/>
      <c v="#f69315"/><c v="#f69415"/><c v="#f59514"/><c v="#f59514"/>
      <c v="#f59614"/><c v="#f49714"/><c v="#f49714"/><c v="#f49813"/>
      <c v="#f49813"/><c v="#f49913"/><c v="#f39a13"/><c v="#f39a13"/>
      <c v="#f39b13"/><c v="#f29c12"/><c v="#f29d12"/><c v="#f29d12"/>
      <c v="#f19e12"/><c v="#f19e11"/><c v="#f19f11"/><c v="#f0a011"/>
      <c v="#f1a011"/><c v="#f0a011"/><c v="#f0a111"/><c v="#efa210"/>
      <c v="#efa210"/><c v="#efa410"/><c v="#eea410"/><c v="#eea510"/>
      <c v="#eea50f"/><c v="#eda60f"/><c v="#eda70f"/><c v="#eda80f"/>
      <c v="#eca90e"/><c v="#eca80e"/><c v="#eca90e"/><c v="#eba90e"/>
      <c v="#ebaa0e"/><c v="#ebab0e"/><c v="#eaac0d"/><c v="#eaac0d"/>
      <c v="#e9ad0d"/><c v="#e9ad0d"/><c v="#e8ae0c"/><c v="#e8af0c"/>
      <c v="#e8af0c"/><c v="#e7b00b"/><c v="#e7b10b"/><c v="#e6b20b"/>
      <c v="#e6b20b"/><c v="#e6b20b"/><c v="#e5b30a"/><c v="#e5b30a"/>
      <c v="#e4b50a"/><c v="#e4b50a"/><c v="#e3b609"/><c v="#e3b709"/>
      <c v="#e3b709"/><c v="#e2b709"/><c v="#e1b809"/><c v="#e1b908"/>
      <c v="#e1ba08"/><c v="#e1b908"/><c v="#dfbb08"/><c v="#dfbb08"/>
      <c v="#debc07"/><c v="#debc07"/><c v="#debe07"/><c v="#debd07"/>
      <c v="#ddbe07"/><c v="#ddbe07"/><c v="#dbc006"/><c v="#dbc006"/>
      <c v="#dac206"/><c v="#dac106"/><c v="#dac206"/><c v="#d9c205"/>
      <c v="#d8c405"/><c v="#d8c405"/><c v="#d7c405"/><c v="#d7c504"/>
      <c v="#d7c504"/><c v="#d6c604"/><c v="#d5c804"/><c v="#d5c704"/>
      <c v="#d4c904"/><c v="#d3c903"/><c v="#d3ca03"/><c v="#d2cb03"/>
      <c v="#d2ca03"/><c v="#d1cc03"/><c v="#d0cd03"/><c v="#d0cc03"/>
      <c v="#d0cc03"/><c v="#cfcd02"/><c v="#cece02"/><c v="#cdcf02"/>
      <c v="#cbd002"/><c v="#cbd102"/><c v="#cbd002"/><c v="#cad202"/>
      <c v="#cad102"/><c v="#c9d301"/><c v="#c8d401"/><c v="#c7d401"/>
      <c v="#c7d501"/><c v="#c5d601"/><c v="#c5d601"/><c v="#c4d701"/>
      <c v="#c3d800"/><c v="#c3d700"/><c v="#c2d800"/><c v="#c2d800"/>
      <c v="#c0da00"/><c v="#bfda00"/><c v="#bfda00"/><c v="#bedc00"/>
      <c v="#bedb00"/><c v="#bcdd00"/><c v="#bbde00"/><c v="#bbdd00"/>
      <c v="#bade00"/><c v="#bade00"/><c v="#b8e000"/><c v="#b7e100"/>
      <c v="#b7e100"/><c v="#b5e100"/><c v="#b5e100"/><c v="#b4e300"/>
      <c v="#b4e200"/><c v="#b2e400"/><c v="#b1e400"/><c v="#b1e400"/>
      <c v="#afe600"/><c v="#aee600"/><c v="#ade600"/><c v="#ace800"/>
      <c v="#ace700"/><c v="#aae900"/><c v="#aae800"/><c v="#a8e900"/>
      <c v="#a6eb00"/><c v="#a6ea00"/><c v="#a4eb00"/><c v="#a4ec00"/>
      <c v="#a3ed00"/><c v="#a1ee00"/><c v="#a1ee00"/><c v="#a1ed00"/>
      <c v="#9fee00"/><c v="#9def00"/><c v="#9def00"/><c v="#9bf000"/>
      <c v="#98f200"/><c v="#98f200"/><c v="#96f300"/><c v="#96f300"/>
      <c v="#94f301"/><c v="#94f401"/><c v="#92f401"/><c v="#8ff601"/>
      <c v="#8ff601"/><c v="#8df601"/><c v="#8cf701"/><c v="#8bf701"/>
      <c v="#88f802"/><c v="#88f902"/><c v="#85fa02"/><c v="#84fa02"/>
    </ramp>
    <!-- Manually assigned matches. Light Blue (900) -->
    <c for="manual-match" v="#01579b"/>

    <!-- Default text color in graph nodes -->
    <c for="text" v="#000000"/>
    <c for="address" v="#000000"/>
    <c for="mnemonic" v="#000080"/>
    <c for="symbol" v="#940707"/>
    <c for="immediate" v="#8c0000"/>
    <c for="operator" v="#010101"/>
    <c for="register" v="#0067e9"/>
    <c for="size-prefix" v="#9f9e9e"/>
    <c for="dereference" v="#010101"/>
    <c for="operator-separator" v="#000000"/>
    <c for="stack-var" v="#8c0000"/>
    <c for="global-var" v="#8c0000"/>
    <c for="jump-label" v="#a000a0"/>
    <c for="function" v="#8c0000"/>
    <c for="comment" v="#646464"/>

    <!-- Background color in graph windows -->
    <c for="background" v="#ffffff"/>
    <c for="background-primary-start" v="#ffffff"/>
    <c for="background-primary-stop" v="#ffffff"/>
    <c for="background-secondary-start" v="#ffffff"/>
    <c for="background-secondary-stop" v="#ffffff"/>

    <!-- Font settings -->
    <f for="ui" v="Roboto" s="13"/>
    <f for="code" v="Roboto Mono" s="13"/>
  </theme>
  <preferences>
    <workspace default="" directory=""/>
    <history>
      <entry for="new-diff-primary-dir" v=""/>
      <entry for="new-diff-secondary-dir" v=""/>
      <entry for="directory-diff-primary-dir" v=""/>
      <entry for="directory-diff-secondary-dir" v=""/>
      <entry for="add-existing-diff-dir" v=""/>
      <list for="workspace-dir">
        <!-- List of recent workspace directories: <entry v=""/> -->
      </list>
    </history>
    <layout>
      <!-- screenWidth/screenHeight will be used to check for changed
           resolution
        -->
      <window height="900" maximized="false" width="1200" x="100" y="100"/>
      <divider-position v="300"/>
    </layout>
    <use-theme name="Google Material"/>
    <call-graph>
      <!-- animation-speed = 0 disabled, otherwise range from 1-10 -->
      <layout default="hierarchical" auto="true" draw-bends="false" animation-speed="5"/>
      <proximity-browsing enabled="true" auto-enable-threshold="300" child-depth="1" parent-depth="1" visibility-warn-threshold="400"/>
      <!-- style either "default" or "orthogonal-edge-routing" -->
      <hierarchical-layout style="default" orientation="vertical" min-layer-distance="50" min-node-distance="25"/>
      <!-- style either "default" or "tree", orientation "vertical" or
           "horizontal"
        -->
      <orthogonal-layout style="default" orientation="vertical" min-node-distance="25"/>
      <!-- style either "compact", "isolated" or "single-cycle" -->
      <circular-layout style="compact" min-node-distance="50"/>
      <!-- sensitivity steps 0-9, wheel-action either "zoom" or "scroll" -->
      <control scroll-sensitivity="4" zoom-sensitivity="4" wheel-action="scroll" show-scrollbars="false" view-synchronization="true"/>
    </call-graph>
    <flow-graph>
      <!-- Same settings as for call-graph -->
      <layout default="hierarchical" auto="true" draw-bends="false" animation-speed="5"/>
      <proximity-browsing enabled="true" auto-enable-threshold="200" child-depth="2" parent-depth="2" visibility-warn-threshold="300"/>
      <hierarchical-layout orthogonal-edge-routing="false" orientation="horizontal" min-layer-distance="50" min-node-distance="25"/>
      <orthogonal-layout style="normal" orientation="horizontal" min-node-distance="50"/>
      <circular-layout style="compact" min-node-distance="50"/>
      <control scroll-sensitivity="4" zoom-sensitivity="4" wheel-action="scroll" show-scrollbars="false" view-synchronization="true"/>
    </flow-graph>
  </preferences>
</bindiff>

Please help me!

Thank you.

Hi,

Now that BinDiff has been made available for free, can a plugin built with this version of BinExport be used to export an IDA Pro database to be used by BinDiff?

And if so, how can BinDiff be configured to use this zynamics_binexport_9 instead of zynamics_binexport_8?

Thanks,
Lucas

I sent a sample idb to private

Is it possible to call BinExport2Sql9 function from IDAPython? Or is this function available only from IDC?

I did some patch diffing using BinDiff and I noticed that there is a bug, which I guess is located in BinExport.

The problem is that BinExport splits functions into several small parts, each recognized as an one function.
This make the analysis using BinDiff very difficult if many function have changed.

As an example I used BinExport on the following binary: win32kfull.sys 10.0.18362.592_x64 (4D6691EEBC1FE5DB0FF4691DE10F429779B44D4208219A53A6116ADBA5484A5B)

Using the 'Text Dump Export' Button, I created a list of functions:

1C0002C40          EngPlgBlt
1C0002CE4          sub_1C0002CE4
1C0002CFE          sub_1C0002CFE
1C0002D10          sub_1C0002D10

It should have only found the function 'EngPlgBlt' and not the other three.
Its easier to see if you have symbols for the binaries, because there shouldn't be many function without symbol names.

The bug occurs around code, which looks like this:

.text:00000001C0002CD8 48 FF 15 79 2A 35 00                    call    cs:__imp_SURFOBJ_TO_SURFACE
.text:00000001C0002CDF 0F 1F 44 00 00                          nop     dword ptr [rax+rax+00h]
.text:00000001C0002CE4 48 8B F0                                mov     rsi, rax				;<--- BinExport wrongly detects this a the beginning of a new function sub_1C0002CE4
.text:00000001C0002CE7 48 89 84 24 30 02 00 00                 mov     [rsp+5A8h+var_378], rax
.text:00000001C0002CEF 48 8B CF                                mov     rcx, rdi

The bug occurs also on other binaries, which are compiled for Windows 10 19H1, at least also ws2ifsl.sys

The same binaries on previous windows versions do not trigger the bug, so I guess it is related to some new compiler feature/optimization

I tried to reproduce this case on sample driver with the latest visual studio compiler, but I failed to do so.
I hope the information I provide are enough to reproduce the issue on your side.

I've tested this on the latest version of IDA (7.4.191112) with:
BinExport Google 11 (@297836223, Feb 28 2020) com.google.binexport

I've encountered this bug also on IDA 7.3 with BinExport 10

Is it possible to export "headlessly" with Ghidra?

One function in module

Second (equ) function in module after rebuild:

Why it is possible (duplicate BB)?
Why unconditional jmp split with another BB-body?
Analize result both functions in IDA is equ.

See #44.

On Windows, the checked-in symlink java/BinExport/src/main/proto/binexport2.proto -> binexport2.proto cannot be followed.

Possible solutions:

• Have Gradle copy the file before the build
• Figure out a (supported) way to only specify a single proto file to the protoc compiler from Gradle.

When exporting the busybox binary from busybox_mips_ghidra_binexport.zip, the function _init at address 004028B0 is included twice in the flow_graph field, causing BinDiff to fail:

$ bindiff busybox_g.BinExport busybox_g.BinExport 
BinDiff 7 (@376216480, May 27 2021), (c)2004-2011 zynamics GmbH, (c)2011-2021 Google LLC.
Error: AttachFlowGraph: flow graph already attached 004028B0

The root cause is Ghidra not properly handling _init, but the BinExport extension should always output a valid .BinExport.

Hi, I'm trying to build the plugin in Windows with the above error. This file that's missing is included in main_plugin.cc and is expected to be in third_party\zynamics\binexport, which is actually a link to the root dir, where the version.h.in file is located. The file is created in the CmakeLists.txt:

configure_file(version.h.in version.h ESCAPE_QUOTES @ONLY)

When using configure_file with relative paths, the input is relative to CMAKE_CURRENT_SOURCE_DIR and the output to CMAKE_CURRENT_BINARY_DIR .

In the Windows build, which is out-of-source, these dirs are not the same, the source dir is the root dir but the binary dir is build_msvc, so version.h ends up there, and not in the root (build_msvc parent's) dir. As a quick (and dirty) fix I've changed the output file path to:

configure_file(version.h.in ../version.h ESCAPE_QUOTES @ONLY)

But looking at the configure file used in the Linux and OS X builds, these seem to be in-source, so the previous change will likely break them, needing a cleaner fix than mine.

Lucas

Hello,

I am using IDA 7.3 on Linux and the latest version of Bindiff (Bindiff ver. 5 and BinExport 10). And I am writing to inquire the procedure to export a binExport database from the commandline.

So after installing the BinDiff and IDA-Pro, I am using the following command:

sudo ./idat64 -A -S"/export/d1/idaedu-7.3/bin_export.idc" -OExportModule:"/export/d1/idaedu-7.3/mcf.binExport" "/export/d1/idaedu-7.3/mcf_base.i386-m32-gcc42-nn.i64"

And the bin_export.idc script is like this:

#include <idc.idc>
static main()
{
        Batch(0);
        Wait();
        Exit(1 - RunPlugin("zynamics_binexport_8", 2));
}

However, after executing the command, somehow it is hanging there, and cannot proceed any further.. Am I doing anything wrong? Thank you.

Currently, all build artifacts end up directly in the source tree. It would be desirable to put all build files into a build_linux/build_macos subdirectory, similar to what the Windows build does.

Hi

as @wangshuai901 did a year ago, I am having the same issue (which was not resolved earlier, at least not documented). I would like to bulk binexport files for comparison with bindiff 6 for Ida7.1 in Windows 10. Bindiff and Binexport are working fine when used in the GUI.
Therefore I created the ida db via 'idat64 -B test\x.exe'.
When binexporting via GUI,
'bindiff --primary "e:\test\x.exe" --secondary "e:\test\y.exe" --output_format log'
works fine.
The only thing not working is binexport via command line.
I tried

ida64.exe -A -SE:\test\bindiff_export.idc -OExport-Module:"e:\test\x.binexport" "E:\test\X.exe.i64"
ida64.exe -A -OBinExportAutoAction:BinExportBinary -OBinExport-Module:"e:\test\x.binexport" "E:\test\X.exe.i64"

with ida, ida64, idat and idat64, because @cblichmann wrote 'idat' was untested. Unfortunately, no binexport. Ida is not hanging, just not doing anything.

Contents of bindiff_export.idc:

#include <idc.idc>
static main()
{
  batch(0);
  auto_wait();
  qexit(1 - load_and_run_plugin("binexport10", 2));
}

I'm using Ida7.1 bindiff 6 with binexport10 (because 11 is not working with ida71).
Could someone point me to what I'm doing wrong?

In this example, BinExport only references the location accepted and not the string Welcome to the admin console, trusted user!; in what situations should I be using string_reference as well? Never? Only if I have no data reference?

For example: There is instruction in IDA "sub rsp, 0F8h" with opcode "48 81 EC F8 00 00 00", but after export to Binnavi it converts to "sub qword rsp, 0h"
example of idb file, source and binary attached:
sub_bug.zip

This instruction is in function "test" with address 004004FA

Error exporting: Executing query failed: ERROR: insert or update on table "ex_1_expression_substitutions" violates foreign key constraint "ex_1_expression_substitutions_address_position_fkey"
DETAIL: Key (address,position)=(4263946,1) is not present in table "ex_1_operands".

I'm getting the above error when exporting to db. I'm using IDA Pro 6.95.160808 (32-bit) with the BinExport 9 plugin and PostgreSQL 9.5.6 64-bit.
It happens when I import an idb from Binnavi or if I directly invoke the idc script from within IDA. Any ideas? I can export to protocol buffers with no problems. Thanks!

The current protobuf based format was originally based on the PostgreSQL database schema used by the (now archived) BinNavi project. Is is heavily optimized for compactness and being well compressible, as Google's internal use case is to store billions of them.
This, in turn, makes accessing disassembly structure somewhat difficult and error prone (e.g. see binexport.cc:GetInstructionAddress()). One has to write a lot of code to get to the most basic information. This code also has to be implemented at least in C++ (for BinDiff core), Java (for its UI) and possibly Python if one wishes to use the format from a script in one of the supported disassemblers.
Another issue with the current protobuf based format is that Protocol Buffers messages are not self-delimiting and always have to be parse whole. The (never published) BinExport v1 format used a small header with (file offset, size)-pairs followed by individual CallGraph/FlowGraph proto messages. To save space, the v2 format combined everything into one big message. This design decision has lead to various problems: For example, BinDiff has to reparse the full .BinExport file each time symbols and comments are imported. As another example, some binaries (such as Electron) lead to proto message that are hundreds of megabytes in size, resulting in warnings from libprotobuf itself as messages over 32MiB are considered to be inefficient.

A new database based format would allow for a somewhat more natural query interface and SQL queries that can be shared across languages. As BinDiff already uses SQLite for its result and workspace files, it seems like an obvious choice that does not require a database server. SQLite based formats can be partially consumed as well and it should be possible to keep them small, too.

Description
When starting BinExport in non-interactive mode from a PowerShell/cmd console, I had a crash from IDA (a dump was generated).
Passing command (on PowerShell): & 'C:\Program Files\IDA Pro 7.4\ida64.exe' -A -OBinExportModule:mybinary.binexport -OBinExportAutoAction:BinExportBinary .\mybinary.sys
When adding -OBinExportAlsoLogToStdErr:TRUE, the command fails.
The command was run from a non elevated console.
A similar behavior is observed on cmd (same syntax without the leading '&').
A similar behavior is observed in an elevated console.
Several different binaries have beeen tested (.sys, .dll) - same behavior.

Versions
IDA version: 7.4, ida64.exe
Powershell version 5 / cmd
On Windows 10.

Error messages (in the dump)

• Exception code: 0xC0000005
• Message: The thread tried to read from or write to a virtual address for which it does not have the appropriate access.

Is this supported?
I basically have many small .idb (or Ghidra) files, with a few functions each, and I want to generate a single .BinExport file from that. (sidenote: the originals were actually .o files, but I've used IDA's batch mode to make .idbs for all of them)
I haven't found any method/tool to do this.

I see that there is the option --export (batch export .idb files from input directory to BinExport format) which does this apparently? Assuming it means a single BinExport file, which isn't clear.
But it does not work.

bindiff.exe --export --primary=test (where test is a dir that has a bunch of .idbs) -> no output or errors whatsoever.

Any help appreciated, thanks :)

Steps to reproduce the problem:

1. Install IDA 7.O (macOS 10.15.7 Catalina)
   2.Install Bindiff 6 (installs correctly)
2. Install binexport1164 (fail installation) and load Mac binary

What is the expected behavior? binexport11 fails installation and Bindiff 6 fails to find binexport11

What went wrong? binexport11 install failure and IDA 7.x crashes.

What version of the product are you using? On what operating system?
Install IDA 7.O (macOS 10.15.7 Catalina), Bindiff 6, binexport1164
Any other comments? I need help fixing this.

ERRORS: dlopen(/Applications/IDA Pro 7.0/ida64.app/Contents/MacOS/plugins/binexport1164.dylib): dlopen(/Applications/IDA Pro 7.0/ida64.app/Contents/MacOS/plugins/binexport1164.dylib, 2): Symbol not found: _get_enum_name2
Referenced from: /Applications/IDA Pro 7.0/ida64.app/Contents/MacOS/plugins/binexport1164.dylib
Expected in: flat namespace
in /Applications/IDA Pro 7.0/ida64.app/Contents/MacOS/plugins/binexport1164.dylib
/Applications/IDA Pro 7.0/ida64.app/Contents/MacOS/plugins/binexport1164.dylib: can't load file

I can not compile s2geometry on windows subsystem for linux.
I install gtest at /usr/include/gtest/
and I create a CMakeLists.txt in it:
find_path(googletest_src_dir
googletest/include/gtest/gtest.h
HINTS ${GOOGLETEST_ROOT_DIR}
PATHS ${PROJECT_BINARY_DIR}/googletest
)
set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
message("${googletest_src_dir}")
add_subdirectory(${googletest_src_dir} ${PROJECT_BINARY_DIR}/googletest
EXCLUDE_FROM_ALL)

but cmake error:
GTEST_ROOT: /usr/include/gtest
googletest_src_dir-NOTFOUND
CMake Error at /usr/include/gtest/CMakeLists.txt:23 (add_subdirectory):
add_subdirectory given source "googletest_src_dir-NOTFOUND" which is not an
existing directory.

Like it says in the title, we should have a continuous integration setup for BinExport.
The IDA SDK as the only commerical prerequitise is already checked in in encrypted form, so implementing this change is not too much effort.

Hello,

I downloaded the binaries in the release folder (zynamics_binexport_9.plx + zynamics_binexport_9.plx64) and put them into the plugins folder of IDA-Pro (version 6.95).

However, I am unable to load binexport as a plugin of IDA-Pro. Actually I just cannot find it in the plugins item:

Could anyone shed some lights here? Am I missed anything? Thank you!

It would be helpful to have Python bindings/wrapper.

I might end up doing this eventually myself; would you prefer I keep the bindings in my own personal project, or contribute them back to BinExport?

I've got the ** .BinExport file and I want use Python to parse it. I know it's a database file, but how can I parse it?I can't find a way!

Hello, I encounter a bug during testing the BinExport addon for Ghidra. For now it only happens for one particular file.

Steps to reproduce:

1. Go into Ghidra CodeBrowser
2. File -> Export program...
3. Set Format to Binary BinExport (v2) for BinDiff
4. Press OK

Snip from logs

ERROR | (ExporterDialog) Exception exporting java.lang.NullPointerException
-- | --
  | at com.google.security.binexport.BinExport2Builder.buildFlowGraphs(BinExport2Builder.java:284)
  | at com.google.security.binexport.BinExport2Builder.build(BinExport2Builder.java:512)
  | at com.google.security.binexport.BinExportExporter.export(BinExportExporter.java:93)
  | at ghidra.app.plugin.core.exporter.ExporterDialog.tryExport(ExporterDialog.java:470)
  | at ghidra.app.plugin.core.exporter.ExporterDialog.lambda$doExport$8(ExporterDialog.java:445)
  | at ghidra.util.task.TaskLauncher$2.run(TaskLauncher.java:119)
  | at ghidra.util.task.Task.monitoredRun(Task.java:126)
  | at ghidra.util.task.TaskRunner.lambda$startTaskThread$1(TaskRunner.java:94)
  | at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
  | at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  | at java.base/java.lang.Thread.run(Thread.java:834)

This happens for the newest version in the repository. I built it Aug 20 directly from source.

There is instruction in IDA "and esp, 0FFFFFFF0h" with opcode "83 E4 F0", but after export to Binnavi it converts to "and esp, 0F0h".
Instruction "83 E4 F0" is "r/m32 AND imm8 (sign-extended)", so F0 should be converted to 0FFFFFFF0h
Example of IDB file and binary attached:
and_bug.zip

There is a file named "BinExport.jar" in ghidra_BinExport.zip. But not mentioned in ReadMe, how to use it ?

I downloaded the source, all the dependencies, and built according to the windows instructions on the Binexport GitHub page, but I get this error: C:\BinNavi\BinExport\third_party\idasdk\include\intel.hpp (11): fatal error Cannot open include file 'ins/pc.hpp': no such file.

I do have idasdk69 installed. Any ideas?

thanks

e.g. add radare2 when/if that happens.

Capstone project does this and it's handy to see if there's similar projects to use as a reference.

Hi guys.

I am trying to compare the two exported BinExport files in BinDiff5. When trying to compare, I get an error - "An error occured while diffing. Exit code 1."

What could be wrong?

And could you add at least some debug log? The program is for reversers, but displays errors as for housewives - "Error 1"...

Only .plwFiles fund in release and it's not suitable for idaPro7.0+~
Where can i get the last release dll ?Thanks~

Will version 10 release with a new version of BinNavi?

I have confirmed that binexport installed correctly. BinExportText() and BinExportStatistics() works well.

When executing BinExportSql(), this error occurs.

IDC>BinExportSql("xxx", 5432, "xxx", "xxx", "xxx", "xxx")
Error exporting: Executing query failed: ERROR:  value too long for type character varying(40)

          0.        0h           0o 0000000000000000000000000000000000000000000000000000000000000000b '........'

Other Infomation:

• OS: Windows 10 x64
• IDA Pro: 7.0.170914 Windows x64
• BinExport: 10 (download from the release page)

I'm trying to build binexport (retreived from GitHub on Friday 18 Nov 2016) on a Windows 7 computer, with IDA-6.95 and Postgresql-9.5.3 installed. Everything was going great till the last step where we configure and build binexport.

The configuration script produced the following:

C:>cmake -DCMAKE_FIND_ROOT_PATH="cd" -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY 
-- Boost version: 1.61.0
CMake Error at C:/DevTools/CMake/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find PostgreSQL (missing: PostgreSQL_LIBRARY) (found suitable
version "9.5.3", minimum required is "9.3")
Call Stack (most recent call first):
C:/DevTools/CMake/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
C:/DevTools/CMake/share/cmake-3.7/Modules/FindPostgreSQL.cmake:170 (find_package_handle_standard_args)
CMakeLists.txt:37 (find_package)

-- Configuring incomplete, errors occurred!
See also "C:/Users/Administrator/GNUHome/binexport/build_msvc/CMakeFiles/CMakeOutput.log".

It looks like it is finding the postgreSQL headers and libraries, but CMake thinks that version 9.5.3 does not meet the minimium requirements of postgreSQL-9.3.

CMake is not a build tool I use frequently so I am at a loss on how to proceed to rectify this problem, any suggestions would be helpful.

Running latest macOS with ghidra 9.1.2 and built ext with gradle.

It appears to be installed, but there is no binexport option in the Export... menu like the docs say.

Hello
I am trying to use BinDiff 5 to match binaries which have been stripped of symbol information using the GNU strip utility.

Strip command:
strip -s <binary>

I then run the stripped binary through IDA 7.4 and BinExport 10.:
idat64 -c -A -S"<IDA script>" <stripped binary>
idat64 -A -OBinExportModule:<BinExport output path> -OBinExportAutoAction:BinExportBinary <binary database>

However, neither IDA or BinExport are able to recognize any functions present in the stripped binary and so BinDiff does not attempt any matching.
Is this expected behavior of BinDiff for stripped binaries or am I missing something at the IDA/BinExport step?
I don't want BinDiff to match binaries based on symbol information. Is stripping the binaries the right strategy? Can stripped binaries be used with BinDiff? If not, what matching strategy should be used so that BinDiff matches the binaries without using any symbol information present in the binary?

Hi, when building the plugin in Windows, the incorrect PostgreSQL installation may be selected by CMake during the build configuration, if there was already a default PostgreSQL installation (for example, if BinNavi was already installed alongside the PostgreSQL database in the same host).

Even though the correct PostgreSQL binaries path is passed to CMake as an argument, DPostgreSQL_ROOT, during the call to find_package(PostgreSQL 9.3 REQUIRED), the CMake finder FindPostgreSQL.cmake script uses this information only as “directories to search in addition to the default locations“, but will search the default locations first.

In contrast to the Boost configuration which allows to explicitly exclude the system path from the search, I didn't find a similar option for the PostgreSQL finder. I'm not very familiar with all the inner workings of the various CMake search paths, but adding the CMAKE_FIND_ROOT_PATH to the CMakeLists.txt file (which I'm sure it's not the correct way to go) fixes this issue:

set(CMAKE_FIND_ROOT_PATH ${PROJECT_SOURCE_DIR}/third_party)

Also the (default) C:\Program Files\PostgreSQL path could be temporarily renamed during the call to CMake, as another (ugly) solution, but that would additionally entail stopping the PostgreSQL service.

Lucas

BinExport2Builder.java setAddressOffset does not use the provided offset to set addressOffset. As a result, setting the export option "Subtract Imagebase" does nothing