After beating my head against the wall that is Olly automation I now officially give up. If anyone is intrested in continuing this work you can download the source at http://members.chello.se/psycko/ollyscript.zip ("http://members.chello.se/psycko/ollyscript.zip") .

The reason I gave up is that it seems that there is no working way to synchronize the active scripting engine with Ollys debug loop. Even though a command queue is possible to implement, the responses from Olly to the script would be meningless.
For example this script would not work properly:<pre>dim x
x = OllyDbg.EIP
while x < 402000h
OllyDbg.StepOver
x = OllyDbg.EIP
wend
</pre>

If you need some more info on my code you can mail me at bik78_NOSPAM_@mail.ru(remove _NOSPAM_).

Hope someone else does a better job of this then I did... =(

What I did was cheat, have seperate event functions for each stage. Instead of a "while" loop, an "if" condition to go to the next function.

The end result may seem to be more script work, but it actually comes out with the scripts being more understandable. It's quite common to have a well described function name being more readable than several lines of comments describing what in-line code is doing.

I haven't had a chance yet to look in depth at your code, but from what I did look at, it seems complete and very well written.

IMHO, I would concentrate less on what your engine can't do, and more on what you can do. In otherwords, don't give up. It may be just a mater of altering expectations.

Ok, consider this:
<pre>OllyDbg.StepOver
if OllyDbg.EIP = 402000h then
'Do something
end if
</pre>
In this script, the StepOver method executes and sends a Go(... STEP_OVER ...)
to Olly. But the value of EIP is not updated until next iteration of the debug
loop so the value of eip before and after the "OllyDbg.StepOver" call is the
same. In fact, the whole script is executed before Olly reacts to the first
command. That must be because the plugin is running in the same thread as Olly, so the whole script engine business is run before the plugin returns control to Olly... Thats the issue I find difficult to resolve...

Greetings,

>In fact, the whole script is executed before Olly reacts to the first command.
>That must be because the plugin is running in the same thread as Olly, so the whole script engine business is run before the plugin returns control to Olly...

That is the consequence of the design of ollydbgs main debugger event loop.
Hope you "enjoyed" my explanations in the "STEP_OVER" message board thread

The only chance to get around this limitation is to not execute the script at once but design the script evaluation around the debuggers event callback mechanism.
Like single stepping the script itself, each step gets driven by a separate debug event plugin callback call (e.g. a finite state machine).

Currently i dont think there's a chance to "fix" this problem at root (ollydbg) because the plugin processing architecture would severe break.
Imagine, what happens to other plugins, if one plugin "captures" exclusive control of the debugger flow itself. No way.
Even if ollydbg itself exposes some automation model - the problem would remain.
There can only be one debug event loop, which gets driven by the debuggers main thread.

Regards,

A. Focht

What he said, I think...

Have a string or function pointer called "OnNextBreak", and a action (Run, step, interactive, etc.). When the script function returns, it issues the Go based on the specified action and returns. When the internal plug-in state changes (ie. a break or exception), the apropriate function in the script is called.

function Step5(n)
{
if (OllyDbg.EIP < 402000h)
{
OllyDbg.Step; // Only sets flag, doesn't actually call Go.
}
else
{
OllyDbg.OnNextBreak = "Step6";
OllyDbg.Run; // Only sets flag, doesn't actually call Go.
}
}

In this case, the "OnNextBreak" (or "OnException", etc.) are used by the plug-in to determine which script function to call, while the action (Run, Step, etc.) are used after the script function returns to determine what to do about it. Interactive stops it from doing anything.

Hi again

There might be a chance to implement this...

As i said above, the script should not be executed at once in the plugin's debug event loop (e.g. doing IActiveScriptParse::ParseScriptText, IActiveScript::AddNamedItem + IActiveScript::SetScriptState(SCRIPTSTATE_CONNECTED)).

You might know there exist the possibily to not only hosting script sites but host debugging site too, called "active scripting debugging".
This is usually done by implementing IActiveScriptSiteDebug, IProcessDebugManager, IDebugApplication, IDebugDocumentHelper interfaces (among lots of other stuff).

By default external script debuggers can debug any script run by Active
Scripting.
The M&#036; Script Debugger is one example of an external debugger, but
you can write your own (like this one http://www.dreamcompany.com/dsd.html ("http://www.dreamcompany.com/dsd.html") though its commercial)

Get the idea?
Single stepping through scripts by implementing your own script debugger engine.
That way you can synchronize "single line" script statement evaluation/execution with olldbg's main debugger event loop.

I might point you to following stuff: "Active Scripting APIs: Add Powerful Custom Debugging to Your Script-Hosting App"
http://msdn.microsoft.com/msdnmag/issues/1200/active/default.aspx
("http://msdn.microsoft.com/msdnmag/issues/1200/active/default.aspx
")
It also contains a sample of a script host and debugger.

An invaluable resource around active scripting:

http://www.mindspring.com/~mark_baker/
("http://www.mindspring.com/~mark_baker/
")

(check out "FAQ online version"

Tons of useful stuff and snippets/examples.

Regards,

A. Focht

focht: intresting info, thank you. i was thinking of single-stepping for synchronization, but didnt think of the debugger interfaces. =) We will see where it all leads...

Progress notes:
I abandoned the whole Active Scripting idea altogether. Even though
in the begining the idea seemed really nice, I never managed to get Olly
and Active Script engine working together.

I am now working on a custom asm-like scripting language for Olly.
At the moment the project is progressing well and the engine is already
capable of running scripts such as: <pre>// Test script
var x // Create a variable named x
mov x, 0
start:
sto // Execute OllyDbg step-over
add x, 1
cmp x, 5
jne start
</pre>


I hope to be able to release the first version (which will be able to read / write register values,
step through code and set breakpoints) some time quite soon.