There are various great alternatives here. However, all of them seem to be unmaintained. The tool I recommend you is Diaphora https://github.com/joxeankoret/diaphora (Disclaimer: I'm the author). Is a pure Python plugin for IDA Pro for doing program diffing, is the only one that can import/export structures, enumerations, etc..., the only one that makes use ...
Yes, this is now possible with Ghidra.
The latest version, BinDiff 6, has experimental support for the Ghidra disassembler. It ships with an extension that allows to export Ghidra disassembly into the .BinExport format needed for diffing.
BinDiff 6 from the zynamics website
A recent Java runtime (OpenJDK 11 or later)
Ghidra 9.1.2 (https:/...
You may want to give a try to ssdeep:
ssdeep is a program for computing context triggered piecewise hashes (CTPH). Also called fuzzy hashes, CTPH can match inputs that have homologies. Such inputs have sequences of identical bytes in the same order, although bytes in between these sequences may be different in both content and length.
You are correct that the binary does not match the tagged source. It does, however, match the changes made in commit 6cfc6b4a403f8487d9fa96aa3d42db7848c8755a, which was made on February 25, one day after the most recent commit tagged 6.11 and before the most recent merge commit in 6.11.
I can only speculate, but it seems likely that their local version of ...
The function prototype for ?EnsureCollectionCache@CFormElement@@QAEJXZ is the same before and after the patch. It demangles to:
public: long int __thiscall CFormElement::EnsureCollectionCache(void)
And the calling convention for the parent function, ?DoReset@CFromElement@@QAEJH@Z, is the same before and after as well:
public: long int __thiscall ...
Something is wrong here, since the original push ebp; mov ebp, esp is 32 bit code, and the modified pop rax is 64 bit code. You might want to sort that out before proceeding.
That said, in IDA:
locate the method in the graph view, or disassembly view. The bottom line in this view will show you the load address of the current instruction as well as the ...
This is probably a bit further outside the normal reverse engineer's toolchest, but still a possibility. Courgette is the codename of the update mechanism behind Chromium and thus Chrome. Quote:
Courgette transforms the program into the primitive assembly language
and does the diffing at the assembly level:
asm_old = disassemble(original)
Given that you're looking to compare ~500 binaries to each other, what you really want is VxClass.
Unfortunately, Zynamics/Google is no longer selling VxClass. If anyone knows of a way to buy it or download it though, feel free to share the information here.
Here is my solution.
I use radiff2 to find out all the difference
radiff2 binary1 binary2
Then xxd to convert binary into hex
xxd -p final
After that, wc to figure out the number of hex in one binary
wc -c outputhex
wc -l newlineneedtodelete
Now I have the difference between two binaries and the total number of hex in each binary. ...
Another option you could try is Relyze (Commercial, Standalone Windows desktop application) which supports binary diffing. It matches functions between two Windows binaries and gives you a list of all equal, modified, removed and added functions, along with a percentage difference value so you can see how heavily modified any two matched functions are.
With the now free BinDiff 4.2 you can do batch analysis with a bit of work.
In the BinDiff installation directory (zynamics/BinDiff 4.2), you will find bin/differ.exe and bin/differ64.exe. Those are binaries for batch diffing of IDBs and .BinExport files.
The basic usage would be:
differ --primary=<directory-with-IDBs> --output-dir=<output-...
In Windows, perhaps the simplest possibility is the built-in File Compare command with its /B (binary) switch, to be used from the command-line. It lists all different bytes together with their file offset.
fc /B filepath1 filepath2
You shouldn't use a debugger to search for differences. You should use a diff tool. Of course, most diff tools works on text, but there are some that deal with the binary files.
There are more and you probably will find one that matches exactly your need.
If you would like to see your modifications in a nice visual manner with ...
VBinDiff at http://www.cjmweb.net/vbindiff/
Below is the same message as above. But with details if you're interested in those.
VBinDiff (Visual Binary Diff) code at https://github.com/madsen/vbindiff
VBinDiff displays files in hexadecimal and ASCII (or EBCDIC). It can also display two files at once, and highlight the differences between them.
VBinDiff is ...
When you use bindiff e.g.,
bindiff original.BinExport patched.BinExport
it will create a BinDiff file, e.g., original_vs_patched.BinDiff. In the current version (6) that file is an sqlite3 database. You can find some of the information you're looking for in the tables in that database-- specifically, the functions table contains the number of basic blocks ...
I think there is a problem with BinExport.
When I used BinNavi, there was similar problem. BinExport was not compatible with my IDA version.
The IDB file structure differs for each version of IDA.
Access the following URL and Check which version of IDA is supported by BinExport.
I'm not going to accept this answer, because likely someone else will tell me a better way to do it. But, browsing the site I saw an old picture of Radare that seemed to kind of do what I want with an S= option. This is showing the breakdown by section. That seemed like a good place to start.
Turns out that's now really close to the undocumented iS= option.
I would like to see the actually files that were patched ...
New-school: Attack Surface Analyzer
... and see what in the code might have been changed and see what the problem was.
As @Neitsa said, see how can I diff two x86 binaries at assembly code level?
It may be because the calling convention changed from __cdecl (using the stack to receive the arguments) to __fastcall or even to a calling convention invented by the compiler (using EAX as the register holding the same information that was pushed on to the stack in the previous version).
One of things I do is to read the machine code and translate it back into IR pseudo opcodes sans any addressing address values, and then perform differences between those two pseudo-IR binaries after using this reduction method on each.