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 ...
Let's split this up a bit. I'll skip over some stuff that you might already understand, but we may need to expand this if some stuff is not clear.
MOV DWORD PTR SS:[EBP-30],400400
MOV DWORD PTR SS:[EBP-30],DWORD PTR DS:
The syntax is a bit wonky but we can understand that you want to encode a MOV with two memory operands.
Let's take a look ...
All messages in a gui application passes through the Application Defined Callback WinProc whose prototype is
LRESULT CALLBACK WindowProc(
_In_ HWND hwnd,
_In_ UINT uMsg,
_In_ WPARAM wParam,
_In_ LPARAM lParam
so when you have breakpointed on a wndproc
esp -> return Address
esp+4 -> hwnd
esp+8 -> uMsg
** MSDN Doc ...
The cmp instruction does not multiply anything by two. Instead, the piece of code seen in your ollydbg screen shot is the implementation of the following line from the poor quality source code image you attached:
if ((!key) || (key > (0x1337 * 2000)))
First, in address 0x01051C09, key is compared to 0. If key equals 0 a jump to 0x01051C18 is taken. ...
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 ...
First Find the address you are looking for. Then cycle this:
Find the base (the beginning of the record).
Dissect the memory around this to recognize array or linked list.
Search the memory for pointer to that base.
Scan for parameter finding the address 30000032.
Find out the base of this record is 30000000.
Checking memory - nothing fancy ...
In OllyDbg there is the option to set memory breakpoints. That means, you can break at the instruction which accesses this certain memory address or the region you specified.
You can set, that the breakpoint triggers at read, write and/or execute.
To set a memory breakpoint, select the area in the memory dump/map, right-click and choose Breakpoint > ...
First of all, welcome to the fascinating and frustrating world of malware reversing.
What should I learn before I start to learn reverse engineering?
I believe that the best way is start to learn basic reverse engineering and improve as you go.
Is learning programming with C/C++ a MUST?
No, it's not a "MUST." However, if you don't know how to program,...
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 ...
This may either be packed multiple times or contain additional obfuscations or anti-analysis. Use the "PUSHAD, breakpoint on ESP, run" method to find the tail transition, as you have. Then set a breakpoint on the tail transition (in your case, JMP 0002A99E) and run to that. The single-step to take the jmp and you'll be at the OEP, or the next stage of ...
What should I learn before I start to learn reverse engineering?
Assembly is a must. Without deep understanding of assembly you cannot reverse engineer anything seriously. Additionally, you'll have to become familiar with relevant tools, depending on the platform; not knowing every detail of them, just basic use - you will learn more complex things in ...
I assume that you don't have any more information about this Secret dialog window than what you have written (that is you don't know how it looks like and the strings it contains, etc.).
In such a case, you can search for GetKeyboardState function that may be used to obtain the keys pressed at a given time. After finding it, just look at the subsequent ...
If you are using OllyDbg, I suggest installing an anti-anti-analysis plug such as ScyllaHide. For ScyllaHide, grab the latest from the releases and follow the instructions in the ScyllaHide.pdf document. Then you can try the various techniques simply through a set of checkboxes.
Generally, if you suspect that a particular anti-analysis technique is being ...
version used: ollydbg v2 but method is similar for v1 too
ollydbg allows you to log the trace i have done some crude diffs in the past as below
you can try improvise
here is the source code that's used for demo
keep in mind i had the source so i compiled it and linked with with /FIXED linker switch to vs 2017 linker so that ASLR doesn't get into ...
Switch to graph mode, then go to menu Options-General, Disassembly tab and enable
[x] Line Prefixes (graph)
Other disassembly options : https://www.hex-rays.com/products/ida/support/idadoc/605.shtml.
You can also check the status bar, it displays the current address.
In general, stepping back for a debugger is a hard problem. gdb has a limited step back feature but it comes with a cost, see here.
But, when you think about it, the whole difficulty solved by the programmer when debugging is to step-back until it reach the bug. This is the whole difficulty and we do not have a nice and automated solution for it right now.
Win32 debugger is IDA's internal debugger, whereas WinDbg is Microsoft's debugger. They both effectively do the same thing. IDA's debugger is probably better integrated with IDA.
I'm going to make a recommendation here to use x64dbg. Ollydbg is outdated and unsupported. IDA's debugger works but the interface is clunky and isn't as easy to use as x64dbg. Plus ...
There's also the possibility to set a screen to full screen with the function SetRect
I found this spot on the mentioned executable:
0x004619bf mov esi, dword [sym.imp.USER32.dll_GetSystemMetrics]
0x004619c5 push 1
0x004619c7 call esi
0x004619c9 push eax
0x004619ca push 0
0x004619cc call esi
0x004619ce push eax
0x004619cf push 0
0x004619d1 push 0
Memory-to-memory MOV does not exist. You could try the following:
MOV eax, DWORD PTR DS : 
MOV DWORD PTR SS : [EBP - 30], eax
Please check also if the absolute numbers are interpreted as hex values in your assembler.
Regardless of operating system, a mouse click represents an event and there is a bunch of event handling plumbing that makes this happen. Some of this can hinge upon certain design choices like how processes are separated in the GUI.
A common pattern is to register a context relative to which events can be processed through an implemented handler. ...
If I get you question correctly, you want to change where OllyDbg breaks first when the executable is loaded.
You can change that by going to: Options -> Option.... And then selecting the Startup and exit under the Debugging. There you have an option to select where it will stop when executable is loaded.
You probably have System breakpoint selected.
It must have truncated your database value, 99999999, to a 16-bit unsigned integer: 99999999 = 0x5F5E0FF => 0x5F5E0FF & 0xFFFF = 0xE0FF = 57599 (or more succinctly 99999999 % 65536 = 57599).
Unfortunately, it's probably impossible to easily change that 2-byte integer to a 4-byte one. In memory, structures might be laid out so that everything is ...
Others have already described elegant ways of doing this, so I'll post a dirty (but very versatile) trick:
Open the binary in a hex editor and replace the first two bytes of the function you want to debug with EB FE (a jump to itself). Run the binary normally (e.g. start the service) and once the process starts consuming 100% CPU (well, 100% of one core), ...
I prefer to use HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Debugger see more here.
To specify the debugger process, which starts as soon as the service process does. So that I'm able to set up the breakpoints at the very beginning.