Well, there is another reason. Historical one, actually.
At end of 2001, when the first versions of Ollydbg were presented, there was SoftICE, which was at its end, and IDA was not that popular yet. So OllyDBG became sort of the de-facto replacement for the main black-hat tool for cracking\patching\keygen-writing. And OllyDBG 1.x is a good, handy tool.
The SCAS instruction is used to scan a string (SCAS = SCan A String). It compares the content of the accumulator (AL, AX, or EAX) against the current value pointed at by ES:[EDI].
When used together with the REPNE prefix (REPeat while Not Equal), SCAS scans the string searching for the first string element which is equal to the value in the accumulator.
It very much depends on what framework they use in order to do their windowing. It could be MFC, WPF, WinForms, WTL, QT, wxWidgets, pure Windows API. There's a lot of frameworks and they all handle the final routing of messages differently.
I'll answer the question for the cases that are either directly built on top of Windows API or where they're using the ...
The main reason I believe is the scripts and plugins that exist for OllyDbg 1. Tuts4you.com has around 250 plugins for version 1 and only 30 for version 2.
Ollydbg Version 1 plugins.
Ollydbg Version 2 plugins.
Also the feature list is not great anymore to make someone change from version 1 to the new version. If someone is changing from OllyDbg v1 to ...
(OP didn't specify if he knows how structures are laid out. Looks like he assumes they aren't complex. I'll answer a more general question to avoid locality issues by assuming the structures are somewhat complex)
Few ways to find the other structures come to mind:
Scanning memory for signatures
Once you have a few examples of the structures, maybe the ...
The break on attach is due to the ntdll DbgUiRemoteBreakin and DbgBreakPoint functions being called. If you check the kernel32 DebugActiveProcess function called by the debugger, OllyDbg or ImmunityDebugger, you will see a call to the CreateRemoteThread, CreateRemoteThreadEx, or ZwCreateThreadEx function depending on your OS.
So, i guess one ...
You have a mix up here. There is no such thing as dynamic disassembly and static disassembly but rather dynamic
Dynamic program analysis is the analysis of computer software that is performed by executing programs on a real or virtual processor.
and static analysis of a binary.
Static program analysis is the analysis of computer software that is ...
IDA Pro offers two tracing options:
Instruction tracing Debugger->Tracing->Instruction Tracing It is very slow tracing process, since IDA monitors registers and has to record the address, the instruction, and changes values of registers, that were changed by the instruction.
Function tracing Debugger->Tracing->Function Tracing. It is a subcategory of ...
I'm not sure if it's still around, but Themida used to have a kernel-mode driver component that facilitated some of the protection features. It could well be installed on your system and catching the debugger out.
My first suggestion would be to try Immunity Debugger. It's an Olly fork that is designed for offensive debugging and exploit development, but it ...
If only the base is changed, but offsets are constant (as I'd guess is the case), you can just rebase the program in IDA. You can do so by edit->segments->Rebase program ... menu.
Specifying the same starting base in IDA as is in Olly should help. Base may be different for numerous reasons, one of which might be ASLR.
Here is a way how you would go back to the caller. The following is a small C++ crackme for demonstration
printf("Enter your password : \n");
open calc.exe in ollydbg c:\ollydbg.exe calc.exe
press Ctrl + G and type GetMessageW
press F2 to set a breakpoint and press F9 until it breaks
when it is broken press ctrl+f9 to run until return
press shift+f4 to set a conditional log breakpoint
in the expression edit box type [esp+4]
in the decode value of expression select pointer to MSG structure (UNICODE)...
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 ...
@DCoder has certainly answered this, so here is only some notes, or, at least it started out as a short note, and ended up as a monster.
OllyDbg uses MASM by default (with some extension). In other words:
operation target, source
Other syntaxes are available under (depending on version):
E.g. IDEAL, HLA ...
Given your requirements, you'd be much better off sticking with WinDbg.
OllyDbg doesn't do .NET, nor is it capable of directly analyzing minidumps. It does have the ability to log its run traces, but this is likely not the type of logging that you need.
OdbgScript is nice, but it sounds like that's not enough of a reason for you to make the change.
Is there some easy way to "rediscover" the offset in the dll?
Yes, here's the algorithm:
Target_Address_in_OllyDbg = Source_Address_in_IDA - Base_Address_in_IDA + Base_Address_in_OllyDbg
Here are the definitions:
Target_Address_in_OllyDbg: The target address in OllyDbg.
Source_Address_in_IDA: The source address in IDA.
Base_Address_in_IDA: The base ...
One way to do this is to have an OllyDbg plug-in that performs a
WriteProcessMemory(hDebuggee, GetProcAddress(GetModuleHandle("ntdll"), "DbgBreakPoint"), &mynop, 1, NULL)
where hDebuggee is the handle for the process being debugged (I believe that OllyDbg has an API for retrieving this value), and mynop is a variable that holds a 0x90 byte (nop ...
There is clearly not enough of information to get you the exact answer. However, I will try my best to demonstrate logic behind what happens. That in a way might give you an idea how to go about locating the encryption function. I will assume you are using Windows, since it has not being stated otherwise.
The main logic of ordinary (and when I say ordinary,...
While in the CPU/Disassembly window, press Ctrl+G (for "Goto"). Type "send" and press the OK button. This should bring you to the address of the send() function in WS2_32.dll and you can set a breakpoint on this address.
Select the MOV EDI, EAX instruction and press Shift+F4 to open the Conditional log breakpoint window.
In that window, specify eax as the expression, set Pause program to Never, and set Log value of expressions to Always:
Press the OK button, run your program, and now the referenced string will get logged to OllyDbg's log window whenever that instruction is ...
Immunity Debugger is forked from OllyDbg v1.10.
So you should use the latest version of OllyDbg (currently v2.01) instead of Immunity Debugger if you want any OllyDbg v2-specific features/fixes. If you don't need those OllyDbg v2-specific features/fixes though, then there's no benefit to using OllyDbg v1.10 over Immunity Debugger.
Set breakpoints on GetWindowText() and GetDlgItemText() and have the target program read your input text. If the breakpoint is hit, you can trace up the call-stack to
see what code is reading your input text and where in memory it's being stored. If neither breakpoint is hit, you can try setting a conditional breakpoint on SendMessage(), filtering it to ...
Go to the memory window in Ollydbg. Find the code section (usually .text) of the module you want to break on return to. Right click the memory section and set break-on-access or hit F2. You'll break once execution reaches that memory. You can also change the memory access to read only and you'll get an exception when execution hits that memory segment.
The usual approaches to this:
Start typing what you want to say, but don't submit it yet. Use Cheat Engine to perform a memory scan for the string you have typed. Once you've found it, set a read-only HWBP, then submit the chat. The chat function should perform a read on the memory holding your chat string, setting off the BP.
Hook strcpy() and related ...
Last Instruction Opcode is set mainly for the use of exception handlers, but it's set for every non-control FPU instruction (that is, set by loads, stores, compares, etc).
The value is non-zero on my system, but it is different value, and it's not constant.
Olly 1 doesn't request as many context fields as Olly 2 does, and that's part of the reason why the ...
The C compiler doesn't create any assembly code to declare and initialize global fundamental data types, so you won't see anything like MOV ..., 3 in OllyDbg for your program above.
In the disassembly of your program below, you can see that the global variable is stored at dword_402000, which is hardcoded to begin with a value of 3:
You can use gdb on Linux, WinDBG, and could give a try to radare2: it's not as rock-stable as the two previous ones, but it's tailored for reverse engineering, and supports gdb:// and windbg:// protocols ;) All of them have a textual interface that should be suitable for braille-interfaces.
But I guess that the killer-feature of radare2 for blind people is ...
I don't think this is possible without doing something extremely invasive. Either patching OllyDbg to use an alternative ZwXX/NtXX function which accepts some flags or patching the kernel. The initial break is done by the operating system so that the debugger can gather information about the process it is being attached to.
I haven't verified but my guess ...
If you are using OllyDbg 1.x, you could use the MSDN Help Plugin which simply looks up the requested API call on MSDN. It works for me on my Windows XP sp3 system with OllyDbg 1.x.
Of course, this requires internet connectivity.
Another incomplete option that may work is to obtain the Windows 7 SDK and be sure to install the "Documentation / Win32 and COM" ...