Exetools (https://forum.exetools.com/index.php)
-   Developer Section (https://forum.exetools.com/forumdisplay.php?f=48)
-   -   x64dbg (https://forum.exetools.com/showthread.php?t=15328)

anon_c 09-16-2014 12:21

I've just used this tool (V2.1ALPHA) recently and wow! I am speechless on what to say about the improvement since the last time I used this debugger! Thanks a lot mr.exodia for the ongoing development of x64dbg, it is a really nice work and greatly appreciated!

Here are a few comments:

I can't seem to find a plugin development tool or instructions? Does it exist?

Do the hardware breakpoints work? When I try to set one, I always seem to get "address not aligned" in the log.

When I try to set a hardware breakpoint on access for a byte, I see the message "error setting hardware breakpoint". The log shows "invalid size, using 1"… Yet, right clicking on the byte and Breakpoint, the "Remove Hardware" appears in the contextual options. And we can delete the HWBP…

In the small action window in between the disassembly and the dump windows: when not in full screen, the horizontal scroll bar interferes with the visibility

A little cosmetic change on the icon when pinned in the taskbar. On Windows 7 with Aero, the icon is barely visible (at least on my systems…). Maybe add a little red contour? Not a big deal, only a suggestion…

RedBlkJck 09-19-2014 21:24

I'm having a problem with the _NT_SYMBOL_PATH on both 32 & 64 bit. I use a central folder for storing all the symbols that are updated from the MSDN online repository. C:\debug\symbols When using a batch file for setting the srv path or setting it globally in the environment variables, x32_dbg doesn't find the symbols. It's ignoring the path set with _NT_SYMBOL_PATH and only searches for a folder named Symbols in the path of the debugger. C:\debug\x64_dbg\x32\Symbols The folder didn't exist but I've created the folder and tried setting the path there. This made no difference, it won't pulls any symbols from MSDN.

I updated to the current debug tools available from MS, replaced the required files and that made no difference. The only way I can get the symbols to load outside of the debugger path is by creating a hard symbolic folder link named "Symbols" and point it to the central symbols folder.
mklink /J C:\Debug\x64_dbg\x32\Symbols C:\Debug\Symbols
This seems to be working to load from local but it doesn't pull from MSDN. I use the same cmd for setting the env bat file that works for OllyDbg ver 1. Am I missing something?

Here is log entry from a symbol that is not current. This is starting with a batch file and a hard symlink set for the symbol folder. (If no hard symlink, all symbols fail.)
SYMSRV: C:\Debug\x64_dbg\x32\symbols\wininet.pdb\44EB68294B5042CB87A79B41E46A85692\wininet.pdb not found
DBGHELP: C:\Windows\SysWOW64\wininet.pdb - file not found
DBGHELP: wininet.pdb - file not found
DBGHELP: wininet - export symbols

Loaded the same app in Ollydbg 1 via srv batch file which updated the symbol from MSDN, now x64_dbg finds the symbol.
DBGHELP: wininet - public symbols

Request - Possible to add setting the local symbol path with an option for using MSDN similar to how Ollydbg 2 does? So no batch file or global var is needed.
Thx - jack

mr.exodia 09-20-2014 02:34

@anon_c: There is a plugin API, but it's not very documented. We are working on that.

As for your hardware breakpoint problem, this is a hardware limitation (alignment with HWBP size), please see if you can reproduce the issue on another pc.

The icon is not ours, it's licensed from icons8 (with backlinks).

@RedBlkJck: For a central storage, consider setting up your own symbol store. Please add an issue saying the symbol path must be customized though INI/Settings.

Notice that you need to manually download the symbols in the symbols tab, x64dbg will not (like visual studio) automatically download symbols from the internet, as it terribly slows down the debugging.


RedBlkJck 09-20-2014 11:00

Ah ok. I saw from another post in ref to the _NT_SYMBOL_PATH where it looked like the MSDN symbol store would be used.

I looked at using the symstore method but it seemed to be a little more maintenance than I cared to do. I am using symsrv with a local cache stored in a centralized folder. SRV*LocalStore*RemoteStore If the local store has an older cache or the symbol is not present then MSDN is pulled. The initial build up of the cached files slows it down quite a bit but after that it doesn't seem to take very long to load up. Easy enough to use the LocalStore only if needed.

Anyway, yes to be able to control the SymSetSearchPath by the ini file would be much more convenient. ;) Quite a bit of progress since the project started, congrats. Cheers

rasta 09-29-2014 01:10

Do you plan to include some memory search feature like in ollydbg? This is the only missing feature for me so far. Great work.

mr.exodia 10-25-2014 18:47

V2.2ALPHA is out!

Because I started a Bachelor Computer Science I didn't implement all requested features for this version, they are still on the ToDo list though and when I have more time I will try to implement them.

- better JIT Debugger information in the GUI
- JIT commands in the help
- Fixed various TitanEngine bugs
- resolved a crash when calling plugin callbacks
- remove plugins from the internal list on unloading (resolved another crash)
- fixed a bug in SearchListView with searching (strings would disappear)
- do not draw CIP when running
- fixed a bug with copying single byte commands
- fixed the launcher (crashes with compatibility mode)
- move detach command to file menu (+ new icon)
- HW BP on [RSP] is now back (thanks to DragonLoft!)
- show if a jump is going to execute or not in the InfoBox
- fix: Changing a label from an empty value to an empty value shows an error
- breakpoint/bookmark in the symbol view
- advanced change page rights dialog
- clear threads on detach (bugfix)
- fixed a crash in AbstractTableView
- new about dialog
- search for -> command in gui
- fixed deadlock on detaching while a script was running
- fixed a bug in the DbgDisasmFastAt function
- changed some register positions
- go to thread entry option in Thread view
- save user sorting preference for the session
- fixed various possible buffer overflows and other possible bugs
- change commandline of debuggee on the fly
- select next breakpoint on enable/disable
- unicode support (UTF-8)
- register view now has scroll area
- set focus to disassembly on target load
- better scrollbars in InfoBox
- uppercase option now will not uppercase API names
- fixed a bug with duplicate recent files
- changed confusing 'memory leaks found' message
- auto move cursor on toggling BP in reference view
- performance improvement with reading settings



Mr. eXoDia

0x22 10-30-2014 01:58

What can i say other than very nice work, finally someone to pick up the thread on x64.
What I do wonder is though if you can implement a feature so that we can be able to search full memory, all of it at once, like you can in olly for unicode and ascii.

I don't think the feature is there unless im totally braindead and missed it.
If you could add this it would make my life much easier :)

What do you think?

Thanks in advance! :)

mr.exodia 10-30-2014 02:56

@0x22: You can search in a single memory section by pressing Ctrl+B in the dump window.

For searching the complete memory: If you can, please code an efficient algorithm to search the complete memory. I tried various things, but they were too slow to be useful.


Carbon 10-30-2014 03:32


Originally Posted by mr.exodia (Post 95436)
For searching the complete memory: If you can, please code an efficient algorithm to search the complete memory. I tried various things, but they were too slow to be useful.

Maybe you need a video tutorial https://www.youtube.com/watch?v=lwFIC7It3Fc

Sorry couldn't resist :p

quygia128 10-31-2014 15:13

hi eXoDia,

why i can't download the latest version from here

check it plz.

MarcElBichon 10-31-2014 15:34


Originally Posted by quygia128 (Post 95453)
hi eXoDia,

why i can't download the latest version from here

check it plz.

Direct link:



elite_r 11-04-2014 00:55

Hi mr.exodia. I have a question about the script in x64_dbg on x64 system. I did not find the commands to patch memory of any size, and then I use "mov" - change memory only 8 bytes at once that patch is not suitable. I think to patch a memory of any size is one of the most used functions when writing a script unpacker. Maybe I'm not there watching or if this is not yet supported in the scripts - are there plans to do this in? because scripting without patching - very limited.

mr.exodia 11-04-2014 20:09

@elite_r: Yes, this is something I wanted to add for some time now. Please create an issue at http://issues.x64dbg.com that describes the problem (and a possible solution if you have one).


metal 11-23-2014 07:29

Actually, I used it to crack some software, it was a real PITA since it kept crashing all the time. If you need more info, I will provide it for you.

mr.exodia 11-23-2014 07:33

@metal: Please provide as much information as you can on crashes. Please also try the snapshots found here to see if certain issues are maybe already fixed:



We would appreciate screen recordings that show you working with x64dbg to see about the usability of the software (or features people don't know about). These recordings will be kept confidential if desired. I think they would really help to figure out what is needed most for x64dbg in the future.


Mr. eXoDia

All times are GMT +8. The time now is 21:51.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2023, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX