Summarizing what we’ve created over the last few sections, we now have:
postgres
).We now demonstrate using BSim to help reverse engineer postgres
.
While doing this, we’ll showcase some of the features available in the decompiler diff view.
Import and analyze the stripped postgres
executable into the tutorial project, then perform the following steps:
postgres
via Ctrl-A
in the Listing.example
.
grouping_planner
as the matching function.
The corresponding function in postgres
should have a default name.double
argument differ between the functions?
For matches with a fair number of differences, the decompiler diff panel can get pretty colorful. Furthermore, as you click around, tokens will gain and lose highlights of various colors. It’s worth giving a brief explanation of when highlighting happens and what the different colors mean. Some terminology: if you click on a token in a decompiler panel, that token becomes the focused token.
The colors:
By default, scrolling in the diff window is synchronized. This means that scrolling within one window will also scroll within the other window. In the decompiler diff window, scrolling works by matching one line in the left function with one line in the right function. The two functions are aligned using those lines. Initially, the functions are aligned using the functions’ signatures.
As you click around in either function, the “aligning lines” will change. If the focused token has a match, the scrolling is re-centered based on the lines containing the matched tokens. If the focused token does not have a match, the functions will be aligned using the closest token to the focused token which does have a match.
Synchronized scrolling can be toggled using the and icons in the toolbar.
If you are satisfied with a given match, you might want to apply information about the matching function to the queried function. For example, you might want to apply the name or signature of the function. There are some subtleties which determine how much information is safe to apply. Hence there are three actions available under the Apply From Other menu when you right-click in the left panel:
Warning: You should be absolutely certain that the datatypes are the exactly the same before applying signatures and data types. If there have been any changes to a datatype’s definition, you could end up bringing incorrect datatypes into a program, even using BSim matches with 1.0 similarity. Applying full data types is also problematic for cross-architecture matches.
There are similarly-named actions available on rows of the Function Matches table in the BSim Search Results window. The Status column contains information about which rows have had their matches applied.
The token matching algorithm matches a function call in one program to a function call in another by considering the data flow into and out of the CALL
instruction, but it does not do anything with the bodies of the callees.
However, given a matched pair of calls, you can bring up a new comparison window for the callees with the Compare Matching Callees action.
Ctrl-F
.FUN_
and search for matched function calls where the callee in the left window has a default name and the callee in the right window has a non-default name.The function shown in a panel is controlled by a drop-down menu at the top of the panel. This can be useful when you’d like to evaluate multiple matches to a single function.
Exercise:
postgres
, each of which has exactly two matches.
Select the corresponding four rows in the matches table and perform the Compare Functions action.In the next section, we discuss the Executable Results table.
Next Section: From Matching Functions to Matching Executables
Having debug information isn’t necessary to use BSim (as we’ve seen in a previous exercise), but it is convenient. Note that applying debug information can change BSim signatures, which can negatively impact matching between functions with debug information and functions without it. ↩