Hot answers tagged

10

Debugging software with a combination of managed and unmanaged code: Ollydbg debugs and runs managed code very well (of course in this case it only runs as a native debugger and not like DnSpy which shows the .Net functions and code perfectly). There are times when, if the malware makes a lot of calls to unmanaged code (native code DLLs) it is far more ...


9

from google starmans realm quoting relevant info These are also known as SHORT Relative Jumps. Programs using only Relative Jump instructions can be relocated anywhere in memory without having to change the machine code for the Jumps. The first byte of a SHORT Jump is always EB and the second is a relative offset from 00h to 7Fh for ...


8

The plugin labeless (https://github.com/a1ext/labeless) was created for exactly this purpose. You can now also use x64dbgida (https://github.com/x64dbg/x64dbgida) to import/export x64dbg databases.


5

You are searching for Conditional Breakpoints OllyDBG It's possible to set a conditional breakpoint in both OllyDbg 1.01 and 2.00 Conditional Breakpoint Displays dialog window asking user to set or modify parameters of simple conditional INT3 breakpoints at one or more addresses addr[naddr] in the memory of the debugged process. [Source: Official ...


5

From what I know you can search for String references in all modules. The way is: right click ---> search for ---> all modules ---> String references


4

You are encountering the issue of backwards disassembly. When you give x64dbg an address to disassemble at it will start decoding at exactly this address, go to the next instruction, etc. For example if you have the bytes: EB 00 48 83 C4 38 C3 And you start disassembling at the first byte you will see: 0 | EB 00 | jmp 2 2 | 48 83 C4 38 | add rsp,38 ...


4

When x64dbg attaches to a process it will first stop at the 'Attach breakpoint'. The button to search for string references will search the module currently shown in the disassembly. To search in another module you simply have to go there. One way to do this is to go to the Symbols tab and double click the module you are interested in. This should take you ...


4

From your screenshot I understand that you want to break on. You can do this by breaking on the debug string event. Use the following setting: If you want to pause the execution, simply click the “pause” button. If you want to see the current instruction executes you can use the “Threads” tab and double click the EIP/RIP column of one you’re interested in.


4

I'll post my own answer here so I can find this again in the future. Using CFF Explorer open the service binary. Find the AddressOfEntryPoint in the Optional Header. Find the .text entry in Section Headers. Calculate raw_offset = raw_address - virtual_address + AddressOfEntryPoint. Within the built-in hex editor, navigate to raw_address. Change the two ...


4

no every exe will not start from 0x401000 the image base is hardcoded in header and is configurable with /entry switch when linking (ms linkers) the operating system can and will override the preferred image base all other address in the exe file are relative to the hardcoded preferred imagebase if os overrides it and maps it elsewhere ...


3

It sounds like you want to dump the executable. You can use Scylla (which is built into x64dbg) to dump and restore the executable. You can find Scylla in Plugins -> Scylla


3

Local variables labeling is not yet supported by x64dbg and as far as I know there's no plugin to achieve that. However, you can still label a specific memory address. You can do this by selecting the address and press :, or right click it and select Label >> Label Current Address. If you want this functionality you can ask for it on the x64dbg's Github ...


3

You can find this out by first running the program to the entry point to skip all of the boilerplate code, then go to the Symbols tab in x64Dbg, going to User32.dll and then filtering for the MessageBox functions. Place breakpoints on any functions with MessageBox in them and then run the program. Now, when MessageBox is called, the program will break and ...


3

Exceptions are complicated business. I will attempt to explain briefly how SEH (Structured Exception Handling) in Windows works to invoke the appropriate exception handler. Your game probably does not use SEH, however, since your question is too broad so will be my answer. I based it on SEH since it's the easiest to understand and you can work your way up. ...


3

You get the “x/y patches applied” message when you try to patch at a virtual address that has no file offset associated with it. Generally this happens if you add code at the end of a section. In rare cases it could be that there is a bug in converting the virtual addresses to file offsets. If you think that is the case, provide the relevant binary and ...


3

You can disable ASLR on the executable using a PE editor and disabling IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE in the Dll Characteristics field. If the value is contained within the executable image, you can calculate its relative address and add it to the executable's base address, assuming this relative address is the same every time. If it's outside the ...


3

You can use the Set New Origin Here option in the context menu of the disassembly view to change EIP/RIP to the selected line: In x64dbg commands this option can be expressed as: cip = dis.sel().


3

Outside of maybe custom plug-ins or perhaps buried features and usability differences, there's really no incentive to use OllyDbg over x32dbg/x64dbg. Since OllyDbg was the debugger of choice for so many years, it will take awhile to run its course. That said, it's still extremely capable for a 32-bit debugger with a rich support/plug-in ecosystem (even if a ...


3

You may want to use "Trace record" and "Run trace". Using Trace record, the debugger records and highlights every instructions as you step through the code. You will easily know when the same instruction is executed twice by virtue of the highlighting. When "Run trace" is enabled with "Trace record", the debugger additionally saves the code execution path ...


3

prototype of DispatchMessage() is LRESULT DispatchMessage( const MSG *lpMsg ); it takes only a pointer to struct MSG which has a hwnd as its first typedef struct tagMSG { HWND hwnd; UINT message; WPARAM wParam; LPARAM lParam; DWORD time; POINT pt; DWORD lPrivate; } MSG, *PMSG, *NPMSG, *LPMSG; this hwnd is validated and the ...


3

It counts the number of 1's in argument's binary representation (see link). Basically, each n & (n - 1) cancels out the least significant 1 in n's binary representation, preserving all more significant digits.


2

I am not aware of any fully-fledged plugin, but there are some halfway solutions. Labeless looks promising and provides Labels/Comments synchronization between IDA PRO and dbg backend (OllyDbg1.10, OllyDbg 2.01, x64dbg) Another solution is ret-sync (or here). It syncs your current address between IDA and various debuggers, and allows for basic command ...


2

As the application is written in Delphi I would recommend to run the binary through IDR (Interactive Delphi Recorder). This tools has a better understanding of Delphi and VCL internals and can then produce and .idc file that you can load into Ida Pro. You'll have (mostly) correct function and symbol naming which makes reading the code much easier. Then ...


2

I have one solution after mucking around for a while, I'm sure I can find something better, in the meantime however here you go. Using the 'Memory Map' Tab you can create a memory breakpoint on code sections Right click on a section->Memory Breakpoint->Execute->Restore Then you can edit the breakpoint condition to be something like this (I am using a 64 ...


2

ollydbg v 2.01 ollydbg calc.exe -> ctrl+g ->address or symbol->follow ->shift+f4 ->pause never -> log arguments ->always -> f9 and see the log window if you are on windbg you simply do 0:003> bp USER32!TranslateMessage "dt ole32!tagMSG poi(@esp+4);kb 2;.echo ========;gc" breakpoint 0 redefined 0:003> g +0x000 hwnd : (null) +...


2

The way is: Debug -> Run to user code Then you will see the strings of the program itself. x64dbg/x32dbg as any other debugger, walks you trough all the process initialization code before entering your "main".


2

Simply execute downloadsym ntdll in the command field at the bottom of x32dbg. As you can see in the documentation: Command: symdownload / downloadsym Attempt to download a symbol from a Symbol Store. arguments [arg1] - Module name (with or without extension) to attept to download symbols for. When not specified, an attempt will be done to ...


2

NOTE! I realized afterward that it was about Ollydbg... Anyway, I stick to my answer... GDB is great! GDB is a wonderful debugger! In fact, and only a few people knows about it, it gives access to all the usual libc functions. For example, in your case, you may find interesting to set up a conditional on a breakpoint like that (by using strcmp()): break *...


2

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. Some examples: radiff2 HxD 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 ...


2

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. Usage: fc /B filepath1 filepath2


Only top voted, non community-wiki answers of a minimum length are eligible