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 ...
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 ...
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 ...
Disclaimer: I am the main developer of x64dbg, take that into account :)
I would say that the main difference between OllyDbg and x64dbg is that there is no 64 bit (os) support at all in OllyDbg. If you are working on a modern system I think x64dbg is a better choice because it was designed to work there.
That said, x64dbg isn’t better in all aspects. One ...
You are searching for Conditional Breakpoints
It's possible to set a conditional breakpoint in both OllyDbg 1.01 and 2.00
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 ...
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 ...
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 ...
In C, this function would look like this:
// some code you haven't pasted here; probably scanf("%d", &a);...
a ^= 3; // xor a with 3
a ^= 2; // xor a with 2
printf("a = %d.\n", a);
I cannot say anything more about it having only the snipped you shared with ...
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.
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
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".
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.
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 ...
I don't know how to do it in x64dbg, but here is another way to achieve it.
Open your ocx (dll) file in Resource Hacker and you should see the resorces within your dll file. Then click Create Resources from Blank Script button and type there:
And click Compile Script button (or press F5 ...
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 ...
mov al, 1, the instruction you want to use becomes b0 01 (you can check here), assuming x86-32. That is, 2 Bytes.
The instruction you are patching (mov byte ptr ds:[ecx+0x72], al) is 88 41 72 and so takes up 3 Bytes. See the problem already?
That means you are only patching the first two bytes of the instruction and need to pad it with a single-byte NOP (...
The large integer that is added to ESP is negative and is used to move the stack pointer to a an address that allows 0x44 bytes on the stack for the current function.
At this point, ESP=EBP-0x44. So, EBP-0x44 is essentially, [ESP].
It is equivalent to PUSH EAX, as a parameter for the CALL that comes next.
The ss: is a selector which indicates that the "...
The RET instruction transfers control to the return address located on the stack. Normally this is used to go back from a function to where the function was called, as the address of the next instruction was pushed into the stack by the CALL instruction.
However, RET can be misused: a PUSH before a RET instruction is a typical obfuscation technique. In this ...
On Windows Travel Debugging (TTD) is a perfect use case for this scenario.
To use TTD, you need to run the debugger elevated. Install WinDbg Preview from Windows 10 store using an account that has administrator privileges and use that account when recording in the debugger. In order to run the debugger elevated, select and hold (or right-click) the WinDbg ...
Download the files
Copy xAnalyzer.dp32 to x32/plugins directory
Copy xAnalyzer.dp64 to x64/plugins directory
Create a folder named "apis_def" in both x32/plugins & x64/plugins directory
Now copy the contents of "apis_def.zip" into both "apis_def" folder
Two ways to label local variables in x64dbg:
In x64dbg, follow in dump at address of local var (like this [ebp-4]). Right click at this address and select Add label, then name the label.
Now in the CPU window, local var is displayed like the following picture:
Try the labeless plugin : https://github.com/a1ext/labeless/ to sync from IDA to x64dbg.
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 ...
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.
[arg1] - Module name (with or without extension) to attept to download symbols for. When not specified, an attempt will be
done to ...
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 ...
What you could do:
With each found anti-debug, patch the exe with the bypass and continue with the patched one.
If your debugger is scriptable (like e.g. Ida) run it under the script, insert breakpoints in your script and bypass the anti-debug in your script. This is a particularly useful in "dynamic" anti-debug cases where static patching is not possible ...
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 ...