Add target "doc" to generate Doxygen documentation of all source in "src/".

Compile with -Wall and fix all warnings.

It would be useful to be able to start a debugger from the UI, running an instance of the binary being analyzed.

For basic support, a path to a debugger must be given and how to run it with the binary (like arguments etc. and the path to the binary with "%1", for instance).

Later on, it might detect installed debuggers, like lldb, gdb, msvs and so on, and have those in a drop-down to choose from. Choosing one should then complete the path to debugger field and possible arguments of running it.

Right now, when inputting a filter it filters for each character input and it gets really slow when there are many entries in the respective list. Perhaps it is better to have a search/go/ok button to the right of the filter input?

Also, the filter must not be shared. Each symbol pane must have its own filter.

In any case, it's really slow to filter more than a few thousand entries.

It would be very cool to have a pseudo-code generator/decompiler from assembly to some pseudo-code format to give an idea of what something is doing.

Check if any libraries exist that does this already.

It should be in the menu if a binary is already loaded. Reloading a binary must keep the current project intact. It should use shortcut ALT+CMD+r. Before actually reloading it should ask if the user is sure, or perhaps only if binary changes are pending?

In addition, when the binary is edited perhaps instead of automatically reloading the UI it should make visible a "Reload UI" button in the main view? The idea is that if the user doesn't want to spend time on reloading, the changes can always be visualized in the editor explicitly if needed.

In certain cases a specific SDK is required for testing so it'd be easiest with the following:

% cmake -DFORCE_SDK=10.10 ../../

There might be performance gains to get.

In the lower, right corner a graphical representation of the whole binary layout could be placed. Each part should have a different color and hovering should display the section names. Clicking in the image should roughly determine where the click was made and select the address in the main widget.

Think about how the sections are displayed; whether they are top-down or left-to-right.

Is it useful to be able to zoom in it?

Mention what it is about, what it does, what is will maybe be able to sometime, how to compile and run it, and how to contribute (do make test before making any PRs!)

Right-clicking in the main view should have a "Hex edit SECTION (TYPE)" action on the section based on the cursor. It should show four columns of the data: address, data low (8 bytes), data high (8 bytes), and an ASCII representation.

Only low and high data columns should be editable.

Modifications should trigger further like disassembly editing.

Implement a dialog for jumping to address, line, function, strings, tags, or text value.

Search in the following way:

• Addresses is in binary view
• Lines in binary view
• Section names (also jump to section on match)
• Section types (also jump to section on match)
• Functions in functions list (it'll automatically also select in binary view on match)
• Strings in strings list (also selects on match)
• Tags in tags list (also selects on match)
• As a fall-back try to find a string match in the binary view

If nothing is found then display message box about it.

Add menu action: Tools -> Omni-search
Application-wide shortcut: ctrl+shift+f

https://en.wikipedia.org/wiki/Portable_Executable

Right now you have to scroll a lot to go between the different sections of the binary, like text, symbol etc. It would be better with a drop-down or right-click "jump to section -> sub menu" or have a menu called "Sections" with the ones of the current binary/project.

Accept .app when selecting. It should take "Contents/MacOS/X" where X is the binary stated in "Contents/Info.plist". Show error if nothing can be found or structure is incorrect.

this looks like a nice tool, but will you have a longer README with more details?

keep it up, cheers!

This is just a simple program which computes a square root and prints the value. Which crashes dispar.

#include <iostream>

int square(double x) {
  return x * x;
}

void print_square(double x) {
  std::cout << "The square of " << x << " is " << square(x) << std::endl;
}

int main(int argc, char **argv) {
  print_square(10);

  return 0;
}

Compiled like so:

clang++ main.cc -o main

% clang++ --version
Apple LLVM version 8.0.0 (clang-800.0.38)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Only a few cases make sense to use the shared pointers. Try to use unique pointers and instead move them around as necessary.

For various scenarios, right-clicking should display options:

• Disassemble - For when text is selected
• Jump to address - When an address/number/hex number is selected

Currently if dispar is launched for the first time (without any previous settings) it will be launched at the user's maximum screen resolution. Might be better to calculate a desirable viewing resolution given the user's current viewing resolution and resize dispar to that instead of fullscreen.

In the main view it would be nice if jumps (relative and absolute) were shown visually, like with an arrow or something. It would be even better if it points to the address it will jump to: Imagine having a jump that happens on the same current viewable portion of the binary and with an arrow from the jump to the address.

In all cases, right-clicking on a jump should expose the "Jump to address X" context action, where X is the resolved, absolute address. It should also have "Copy absolute address" (for both relative and absolute) and "Copy relative offset" (only for relative).

In the main widget, the machine code should be editable. After having been edited the changes must be revertable and there must be commit/save to binary functionality.

Edited machine code should be shown in a different color to make it very clear what's been edited.

Maybe a special editing dialog is needed so it isn't required to support inline editing. The selection is from start to end block in cursor selection, which marks an address range. Add context menu item "Edit machine code".

After editing the range must be updated in the main view: the machine code and disassembly if needed.

When committing to file also make a backup file right next to the file, like ".bakX" where X is a number that grows. Perhaps the program will detect these backup files and make available a "Revert" menu displaying the previous versions - clicking one should then overwrite the original with that backup file and load the overwritten binary.

Add config setting for choosing where to place the backup files. It should default to "Same folder as original file" and be possible with manual input.

The idea is to have a menu item to open the log dialog. But the log context should be decoupled from the UI, so it's a viewer of the log data and only if it is visible should it update anything, of course. From the dialog, there should be a "save to file" button of sorts, and possibly a path to the log file associated maybe.

There can only be one instance of the dialog at any one time. Clicking the menu item again while the dialog is open already should just highlight it.

I would like it to work by hooking into the Qt debug/info/warning/critical/fatal logging functions and channel that into the log context. And by extension, a log file it should append to. Remember to add a mutex inside the handler installed by qInstallMessageHandler(). This is important because entries will come in from multiple places and you want to lock whenever you create an entry and write to disk etc.

The entries in the context should have date/time, severity, message, but in debug mode also file line/function.

Keep like 200 in memory as a window and channel to file continuously.

Rewrite all occurrences of #include "../SomeFile.h" with #include "folder/SomeFile.h" so it is evident from where it is being included.

Currently dispar configuration settings are spread between two separate files (~/.dispar and ~/Library/Preferences/com.dispar.Dispar.plist). Would be good to merge these files into one file located at ~/.dispar.

Only save position, size and delta data for each modified region block.

When loading a project, the modified regions must be applied after loading the binary but before creating the UI.

Speed up processing binary info to produce UI elements etc.

It should default to not use it.

https://en.wikipedia.org/wiki/Executable_and_Linkable_Format