Hello,

Does anyone know of a way to automate olly? Right now im debugging an app
that requires me to set a couple of breakpoints, change some memory values
etc. every time i run it so i can get to the part that intrests me...

Maybe a scripting plugin should be done?

yes, it's a nice idea for a plugin.

yaa

Ok, started writing... It already shows an About box! =)

Anyone who wants some specific functionality can post in this thread.

Release date: before 20 January 2009. Seriously, I make no guarantees it
will ever be released, i have a history of not finishing started projects.

I have a question, maybe a sugestion, dunno...

It's really quite easy to setup a J-Script or VB Script engine, you know, set your active site and voila. Writing a COM object exposing the plug-in SDK routines might be a bit tougher, but do-able.

My thinking is that, with this type of scenerio, you could even add dynamic script functions for certain types of events, say when you break, etc., that could be changed at in the script as it goes. (i.e. in the script, OllyObj.OnNextBreak = Function_ProcessStep15).

Ok, so creating a COM object that would allow you to access the registers of the target, control program flow, mod memory, and receive events based on actions (i.e. implicit parsing of Getstatus in ODBG_Pluginmainloop), well, I don't know. It seems to me it would be quite usefull.

In theory, it could make short work of a lot of problems that are currently manual. Scripting languages aren't exactly speed demons, but they sure are faster than typing.

What do you think?

nice ideea waiting for progress ...

sgdt: Not a bad idea at all... Was writing this plugin in MASM, but parsing script files is a bitch...

Lets see that I understood you correctly: a COM object that exposes Ollydbgs API routines should be developed. It should also fire events when things such as exceptions and breakpoints happen. Right?

Yes.

You feed it a COM object that exposes most of the plug-in SDK. The plug-in will need to implement ODBG_Pluginmainloop, parsing the status change via Getstatus, so that it can fire one shot script events on target status change (i.e. break point, termination, exception, etc.).

The rest of the functions are pretty much 1:1 mapping to a COM object.

You need IActiveScript, IActiveScriptParse, and IActiveScriptSite. And of course, a COM object exposing the plug-in SDK routines.

I'd also recomend a few helper routines, for searching/modding memory, setting flags w/o needing to know the bit offsets, etc.

It would help with a lot more than simple automation. Finding bugs in a repeatable way would be invaluable. Also, it would eliminate the tedium of having to visually look at a register to see if your at the right spot yet.

Being able, in the script, to say what should the next script routine to be fired on a given state would be most cool. i.e. OllyObj.OnNextBreak = Function_ProcessStep15.

Of course, OllyObj.OnNextBreak = "" would mean when olly hits next break, go interactive...

The only trick to remember is when you are invoking script events, the parameters are going to be variants, and you really need to pay attention to the types. For example, the same script routine can choose a different result type based on how it ran. I think MicroSoft (does that mean Small and Limp?) just wanted to keep programmers on their toes...


The scripting engine itself is tiny. The implementaion of the OllyObj is where the fun begins...

OMG, its been some time since i used ATL etc and ive repressed all the emmories of it. It isnt gonna be any beautiful clean code in this plugin =))

Now I'm starting get stuff working with this plugin, but Id really need some help.
sgdt, you seem to know your COM. You suggested using something like "OllyObj.OnNextBreak = Function_ProcessStep15". What I dont understand is how Im supposed to pass a function pointer? I mean, in VB id use the addressof operator, but its not present in vbscript. The property of the COM object is of IDispatch* type, which means it wants a pointer? Any ideas on how to implement this?

Greetings...

VBScript 5.0 or later: use the GetRef() method.
(Before 5.0 there was no way to use function pointers)

Example to create a reference to a function, allowing set the event handler:

<pre>
set OllyObj.onNextBreak = GetRef( "foo"

function foo()
alert( 'onNextBreak() event called')
end function

</pre>

Regards,

A. Focht

The object (OllyObj) is injected into the engine via "AddNamedItem". The scripting engine, when it encounters "OllyObj" calls "GetItemInfo" to get type info and a IDispatch pointer.

"GetIDsOfNames" and "Invoke" are used to fire events into the script. That is why I just had the event function name as a string, to avoid lifetime issues with a pointer. Minor slowdown, but avoids potential problems.

Speed is pretty decent, because once it has the IDispath, it calls the member routines nicely. Still, strong helper functions are prefered, as lots of little calls could bring a computer to its knees. This is why "ODBG_Pluginmainloop" can't be exposed directly, but rather only its effect of determing state.

The plugin basicly drives the script, with the script providing context on what to do next, but the scripting engine can keep global variables to maintain scope from call to call if desired.

From script, you have access to the filesystem, etc., via standard active x objects, but you have to manually create them (new activex for *.js, CreateObject for *.vbs). The interface for the scripting engine is derived by the file extention (CLSID_VBScript for *.vbs, CLSID_JScript for *.js).

sgdt: any progress on the automate OD plugin ?

Humm TBD, I think you misunderstood. I am the one writing this plugin. =)
There is some progress, it's already parsing scripts, stepping through disassembly and displaying EIP in a nice messagebox. =) Now I'm working on it being able to script events...

I don't really have that much time to dedicate to it, but I expect to have a v0.1 ready sometime quite soon...

Mine is just for fun, so I could get around a protector (written because I got tired of always having to press Shift F11 for 13 times before having to mod a memory address and add HW Break Points, and then... Well, you get the idea.). Mine isn't very stable yet, so I'm certain TBDs efforts will be what you want instead.

Active Script itself is fairly trivial to implement. The only tricky part is the object(s) you inject into the engine have to be in sync, which is sometimes harder than it sounds. But still, it's a big time saver when doing repetitive tasks.

psyCK0: oops, sorry
anyway, maybe you can post your progress and we can start helping in some way.

Right now there is not much to share. I will, as soon as it is working somewhat...

sgdt: What are the synchronization issues you mention? I have some problems implementing multiple commands, like two "step over" in a row, because only one of those can be executed each time ODBG_Pluginmainloop is passed... =/

What I did was set the name of the next script function to call. In the case of two step overs, the first says 'OllyObj.OnNextBreak = "Function_ProcessStep15"' and then in Function_ProcessStep15, it says 'OllyObj.OnNextBreak = ""' to go interactive on next break.

I couldn't figure out state any other way than in ODBG_Pluginmainloop. What I do is maintain state, and then when it changes in ODBG_Pluginmainloop, I call into the script with what changed (assuming the event function name string is set).

The race condition has to do with the injection of OllyObj into the scripting engine. Well, not actually the injection, but on program termination, things currently get pretty hairy... Learning quite abit about COM in ActiveScript, which is almost harder than dealing with the protectors I'm trying to circumvent. Still, in the long run, it should make things quite a bit easier.

Well, maybe IactiveScript::GetScriptThreadID() / SuspendThread() can help me here...

Really iritating that you cant set breakpoints in the COM object when debugging. I only succeed in getting breakpoints on the ollydbg plugin functions. Well, well.. If I ever finish this work you'll get on the contributors list. =)

BTW sgdt, do you think I could have a look at your implementation? Maybe then I get some bright ideas...