Direct link:

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.

@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).

Greetings

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.

@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:

https://sourceforge.net/projects/x64dbg/files/snapshots/

@everyone:

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.

Greetings,

Mr. eXoDia

I will send you a PM, I don't want to reveal what software tbh.

V2.3ALPHA is out!

Changelog:
http://x64dbg.com/changelog

Website:
http://x64dbg.com

Greetings,

Mr. eXoDia

some feature suggest and request.
 

1. didn't you see, when we click on next asm code of jump xxxxxx, the red arrow jump line will automaticlly showed on OllyDBG, but none in x32dbg.



eg:



00401000 jnz 004010004

00401001 xxxxxxxxxx

00401002 xxxxxxxxxx

00401003 jmp 00401005

00401004 xxxxxxxxxxxxxxxxxx <----------- If you click here, the red jump line will automatic showed in OllyDBG jump from 00401000, but none in x32dbg, will this implement?

00401005 xxxxxxxxxxxxxx



2. didn't you see, when we search something, will result many, at current, we need set each breakpoint by press F2 many times one by one, so if I find thousand times of mov al, 1, should I need press F2 shousand times to set breakpoint on it? do you even think make a option or sub-menu called set all breakpoint or set bulk breakpoint on all of them? so in OllyDBG is have this feature on set all breakpoint on them or cancel breakpoint on them.



eg find result:



00401000 mov [EAX + 12], 1

00402000 sub 2, [EAX + 12]

00403000 mov EBX, [EAX + 12]

00404000 imul EAX, [EAX + 12]



3. at currently, we set API any breakpoint through command line box, that is inconvenience for user and me, did you even think make a API breakpoint Plugin or API Breakpoint menu option? in OllyDBG there is many such plugins, that is good, but none available yet in x32dbg.



eg:



bp MessageBoxA/W

bp ExitProcess



4. at currentlly, we set each windows eg: infobox window, stack window, hex window width & lenth, but exit debugger process, next time relauched, it can't saved into config.ini file, so need reset again, didn't you even think let it can be saved, so next time relauched I don't need set it again and again, I really hate it.



5. still against, when unicode string searching will be supportted? maybe there is some source code open Plugins on OllyDBG, If I can find for you. thanks.

I just published a definitive tutorial for x64_dbg. It documents its settings and features and shows you how to use the tool to effectively debug a 64-bit application.

http://reverseengineeringtips.blogsp...to-x64dbg.html

V2.4ALPHA Released!

Changelog:
- resolved a crash when scrolling up in the dump
- resolved reference view not following in disasm correctly
- resolved losing settings
- fixed a crash with a critical section initialized multiple times
- added secret option to disable database compression
- various ui improvements
- allow 'jmp short'
- fixed hardware breakpoints
- disasm/dump/stack plugin menu api
- display the number of bytes selected and the module in dump
- added topmost option
- fixed TLS callbacks on DLLs
- show reference count in reference window
- fixed possible buffer overflows
- added a close all button in the reference view to close all tabs
- fixed a bug with a non-refreshed memory map on start
- report bug button
- update hex when editing ascii/unicode in HexEditDialog
- settings dialog now scales
- fixed importing patches
- thread-safe dbghelp access (could fix some crashes)
- Yara pattern finding support
- resolved an issue where toggling patches did not toggle the actual bytes
- data copy dialog in various formats (C byte/word/dword/string/unicode)
- dynamic 'Find references to' menu in disassembler (auto-detects constants)
- added find references option to the dump (also works with a range selection)
- show what was searched for in reference tab title
- RegEx support in SearchListView

Download:
http://snapshots.x64dbg.com

Donate:
http://donate.x64dbg.com

Greetings,

Mr. eXoDia

Nice news
:D

can you implement some type of compatibility with olly plugins. The sheer amount of olly plugins is main reason why i still cannot use it as my default debugger.(i understand the fact that most plugins on the wild is to fix and hide olly, but some of them has other purposes as you can already guess, ex- ollyscript, oreans unvmer etc.)

@Conquest
That is too much work and wasted time.

Maybe you should become active?
- Create feature requests: https://bitbucket.org/mrexodia/x64_dbg
- Ask plugin authors for a x64dbg version.

x64dbg has already more than enough hide plugins.

You misunderstood me, i am not looking for hiding features, some of the pluigns for olly like oreans unvmer and zeus are very important and unfortunately ,deathway isnt active recently(and i doubt with his busy schedule he will be interested in learning x64dbg) and i dont know ximo personally or how to contact him. I can write 1 or 2 small plugins may be but i am far less capable of creating something as good as theirs(or just too lazy).

But i got your point, it will be really cumbersome to provide olly compatibility .
Thanks for considering my advice though. Appreciate it.

Compatibility with OllyDbg plugins is not possible, just because the architecture is completely different. Maybe I could do some exports ollydbg has, but those would already require plugin patching or some weird dll called 'OllyDbg.exe' that was somehow loaded in x64dbg and the plugin at the same time (first load OllyDbg.exe in x64_dbg and then load the plugin in x64_dbg?).

Feel free to give it a shot.

For plugins that only use a few APIs it might be possible to do with some hacks, but apart from that I doubt it is possible.

Olly has 188 exported functions. That is insane.

Oreans UnVirtualizer 1.8 uses 27 functions. Emulation is possible. But some APIs are really difficult to emulate (in my opinion).

Poll options update
 

Please, update poll options. Currently there are only 3 options excluding the most important one: "Yes, as x64 debugger"

Would you use this debugger?

• Yes, as x64 debugger
• Yes (mainly x32)
• Not at all
• Yes, if it gets better (please post feature suggestions)

U can also add another one. -Yes, As x32 and x64 debugger.

When i made the poll I meant to make the "Yes (mainly x32)" "Yes (mainly x64)" the typo was never fixed :) now added the option.

Please remove the poll, because it is useless. With further improvements more and more users will use this debugger.

Have you thought about supporting more OS? Like linux x86/x64? I don't know how good the win code separation is but supporting another OS will be a killer. If your code is good :D you only need to replace titanengine, because qt is platform independent anyway.

Creating the basic linux debugger functions is as easy as in windows.
e.g. https://github.com/tuco86/edb-debugger/blob/master/plugins/DebuggerCore/unix/linux/DebuggerCore.cpp

PS: Please create a new snapshot with the new plugin icon stuff :)

I like the poll myself :p And yea, there have been thoughts, but the code is not portable (the dbg part that is). It would probably be possible to make the GUI generic so people can plugin their own debug engines in, but that's really far away right now.

My jenkins server is down so I cannot do any snapshots right now. You could compile it yourself (should be really easy with the supplied batch files).

Greetings

Just a quick question. I have just compiled the updated x64_dbg and now the plugins dont seem to work anymore.. is this because the files have the '_' taken out.. i.e. x64_dbg.exe to x64dbg.exe, x64_dbg.dll..x64dbg.dll?

Just checked seems the name change does affect the plugins.. can be fixed by editing the filenames in the plugins :)

I created a forwarder for backwards compatibility: https://github.com/x64dbg/x64dbg_forwarder

If you want the latest x64dbg version I encourage you to use the builds at http://snapshots.x64dbg.com they are mostly up to date with the latest master (except when the change is so minimal it doesn't affect anything)

Hi mr.exodia,

Do you have tested the x64dbg debugger in win 8.1 ?! Do you plan to do the optimization of code execution? Implementation of the code execution by F8 for example, I think it is too slow. Generally tracing in the code is fairly slow.

On my system, this message comes out -

---------------------------
ERROR
---------------------------
NT APIs missing

section

060200000109_x86_000169B0

file

Z:\x64_Debug\x32\plugins\NtApiCollection.ini
---------------------------
§°§¬
---------------------------

But I think it is a problem of plug-ins. After completion of debugging on Win 8.1, the debugging file looks like remain busy until you restart the debugger.

Do you plan to add the search for a set of assembly instructions?

Thank you for your great project!

@mak: x64dbg is developed on Windows 8.1 x64. There are indeed many plans to improve the performance of these kind of things, but it is really hard to benchmark and even harder to improve. Feel free to improve things and send a pull request.

That error message is from ScyllaHide. In their readme file they explain why it happens and how to fix it.

And until now there were no plans. Feel free to report if you have ideas or made anything here.

Hi Mr.exodia , I am using x64dbg for x86 binary.
I was reading this and thought i could give it try using x64dbg.But I'm not able to search for strings within program(shows ntdll strings ? not demo app strings or am i missing something ?)

btw I love tabs better than toolbar of olly :) Great work keep it up.

Hey,

If you want to search for strings somewhere, you have to go there in the cpu first. Just go in the memory map and double click the code region of the module you want to see the strings of. Then find strings again.

Sorry for trouble, i got that after i posted this message :)

Just a small feature request. In dump windows it would be useful if selecting dword/qword you would add "Follow in dump" option in context menu thus pointers in dump can be easier tracked :) or I missed this feature somehow :)

@deroko: I plan on working on x64dbg today, I will implement your feature request as I missed it myself a couple of times too!

Great, this will be very useful :)

I implemented your feature request, download the latest snapshot from here

Wow that was fast :) work like a charm :D

Some more suggestions, would be also good to have same option to follow dword/qword in dump, and to be able to use '-' like in disassembler to go back to previous address in dump. Would be very useful for quick inspection of struct/object members which are pointing to some address without need to type address in dump :)

I have tested the new build with decompiler.It really adds so much more to the whole debugger.
Seems more complete now.

Good work Devs

Changelog

http://sourceforge.net/projects/x64dbg/files/snapshots/

+1 for deroko's request using +/-

I use them a lot for jumping back and forward while tracing code.

Thanks as always for all the effort on this. Exceptional piece of work!

Deroko: what do you mean with the second request? The thing with the structures...

I will look at implementing the +/- option in the dump window. Unfortunately the current architecture doesn't suit very well for that, but it'll be the first thing I look at when I go streaming again :)

Sent it as pm, it's a bit longer description :)

jesi ziv gde si druze

Oki, one small bug which I've noticed is that attach to process doesn't work if you set x64dbg as JIT and from ProcessExplorer or ProcessHacker you click on process and select debug. It launches x64dbg, but it doesn't attach to the process :(

@Dreamer: §¦§Ó§à §Þ§Ñ§Ý§à §ã§Ñ §Ó§â§Ö§Þ§Ö§ß§Ñ §ß§Ñ §Ó§â§Ö§Þ§Ö §Ò§Ñ§è§Ú§Þ §á§à§Ô§Ý§Ö§Õ §ß§Ñ §Ü§à§Õ§à§Ó§Ö §Ú §ä§Ñ§Ü§à §å §Ü§â§å§Ô :D