After doing all sorts of manual unpacking, I would like to take things to the next level. Being a coder by nature, I want to write my own tools rather than rely on other people's stuff.
Stand-alone programs are fine for some tasks but I feel like some sort of plugins might ease my life - doing stuff from the single debugger is just soo much nicer (yes I'm lazy in a way, that if I can make it easier by some fun coding, why not do it?!).
The first obstacle is obviously choosing The tool. SoftICE has macros, and IDA has IDC. SI macros/IDC seem quite restricted for what I had in mind. IDA is great, but imo not so great as a debugger, so I might rule that out (4.7..). I haven't found good documentation on extending SI (DS3.1), beyond the few posts on this forum (exet's forums doesn't allow searching without account..sigh), steen's russian document (which babelfish translates quite horribly) and a few already available tool sources and of course their disassemblies. Apparently there's at least the driver way that some tools use and the plugin directory in DriverStudio's installation with some examples. Googling softice/.dpp/.dfp gave absolutely nothing useful ( how is this even possible). I disassembled few of these, and seems that they are for Visual SI? Where's the Development Kit for these, and documentation?? VSI might be exactly what I'm looking for, since I'm not quite sure I want to do it in ring0, where even simple things like writing to disk are harder. VSI would not have this trade-off of complexity vs. power I believe?
And then there's OllyDbg. Great Plugin Development Kit, plenty of examples and knowledge around the 'net. Unfortunately I only used it briefly, before felling in love with the good old text&keyboard interface of SI. Also it has the burden of ring3. I don't like to learn redundant stuff and Olly 2.x is expected (?) to have some radically different plugin approach. Some targets (Themida anyone??) might be better defeated with SI of course, and who knows what hellish patterns might emerge in the future from some crackpot packer coder..that require the debugger to be SI/ring0. Then I'd be in trouble with Olly.
Any opinion on the tools and examples/whatever on the methods to extend would be welcome. Does DS3.2 have any improvement on the doc etc issues? When is OllyDbg 2 coming out, if ever? What about Syser (haven't even tried it after reading about the problems and general betaness of it), I think it isn't extendable? Should I just jump back to OllyDbg since the plugin kit is so nice and only use SI when absolutely necessary?
Sorry for the long rant and thanks in advance.

Hi

WinDbg might be another option to look at, it has an extensive set of APIs for plugin use through its WinDbgExtensionDllInit interface. Both SI and VisualSI use the same interface and a subset of the WinDbg extension APIs for their KDExtensions, strictly ring0 for SI.

If you're comfortable with Softice, and with driver programming, a set of KDExtension routines you can pull up in Sice at any time is very useful. Once a basic skeleton and a solid file I/O routine is set up, you can add modules as required. In terms of programming, a KDextension is a driver within a driver(ntice.sys), you can do most anything as with a normal driver beforehand, including having a GUI interface, and yet still have access to many Sice functions.

For many of the standard WinDbgExtension API's available in Sice, you can duplicate their function in other ways, but they can be useful. One of the nice things is that you also have access to the Softice disassembler itself, as a command through <ExtensionApis.lpDisasmRoutine>, which can be used anywhere in your driver code and is a pretty powerful feature.
On top of this, you can also call any Sice command programmatically in your driver code, this requires parsing of the internal Softice command address table, but does work.

You are right that a good file I/O routine is critical, it requires creation of a system thread which queues requests to write memory to a file, you will have to handle synchronization. It can be challenging to code but once you've developed it it's there forever.


In terms of writing the !kdextension modules themselves, you have to be a bit careful because they run at the same high, uninterruptable IRQL level (29) as Softice itself. What this means is you can't actually debug them using INT1 or INT3(DRV). That's not really a big deal though, say you wanted a !("bang" command to overwrite a section of target memory or decrypt a routine starting at a particular address. You can likely test and debug most of this in regular driver code, then transfer it to the ! command code. All you need to do then is parse the arguments you would normally be sending with the ! command.


All depends on what you want to do I guess, Olly is probably great for ring3. I think we'll have to wait for Syser, I still see talk about problems.

Regards,
Kayaker

I have to say you are definitely "lazy" as you say. First of all nobody wants to write "redundant code". However, protectors rarely stay static, and you will often have to change your code to keep up, no matter how you write it, as plugin or not.

Ring3 is not death.In fact, ring3 can work better against many protectors since it's harder to detect a ring3 debugger than it is SI. (I mean it's easier to hide a ring 3). Look at ImpREC, it still has tons of functionality that still works against most protectors. The trace import feature still works against VBOX and UltraProtect, etc. And you'll notice is has plugins but these are the ones that break with different protector releases. So plugins are not always "the answer" They do however allow you to add new functionality without redoing the entire program. Ring0 is not the ultimate answer either. A tool that does things in a creative new way, that is what matters most.

Instead of coming up with excuses to keep you from getting started, just write something, even if it is standalone. Don't get caught in analysis by paralysis looking for the perfect situation. Doing something now will still help you to figure out the best way to construct your software moving forward. For example, I wrote several unpackers until I finally realized a good codebase and technique to make writing an unpacker more "intuitive". I still use that same codebase today.

-nt20

Hello Kayaker,

and thanks for pointing me to the right direction! WinDbg extensions seem pretty straightforward now after I've found some documentation, and it just might be what I wanted. Writing kernel mode Windows drivers (or any driver for that matter) is new to me, but it seems very exciting indeed. SI obviously doesn't support the !load like WinDbg but I guess there are examples.

@nt20:
I don't understand what you mean by "redundant code", do you mean I should stick to using the stuff already available? Well I don't care about other ppl's programs, yes I could just use -insert unpacker name here- but I think that's not what this is about..I rather learn new stuff by doing it myself. If you see me as lazy and making excuses for not coding stuff, you don't know me. Thank you on your views anyways, I will certainly think about the points you made out. I was kinda hoping someone would kick me to the user mode code direction and give it some credit (and by this I mean Olly not stand-alone progs, those I've already did some, but would like to use debugger's disassembly and other features from a prog).

I only meant that no matter what tool you construct, in time you will need to rewrite it eventually to keep up with the external world. Hence, the "redundant" issue, in that you have to maintain the code no matter how it is written. I was under the impression that you were hoping coding a tool in ring0, for instance, would remove that burden from you, when that is not the case (which you may already know however - but you referred to not wanted to learn redundant stuff).

-nt20

Of course I am aware of protections changing as soon as a weakness is found. That's the nature of the game? By redundant stuff I ment that if OllyDbg 2 is coming out soon, I rather not study the plugin architecture of 1.x. Maybe redundant was wrong term, sorry for my quirky english.
You are absolutely right that there probably isn't a perfect solution. But right now I'm not looking for perfect solution, just mainly pondering at where to start.

I hope Olly 2.x does come soon, it's such a nice tool

Anyway, good to have another tool author out there, even though of course they will most likely stay private.

-nt20

Heh, good line
"Don't get caught in analysis by paralysis looking for the perfect situation." / -nt20
"Do, or Do not, there is no Try." / Yoda

If you write a WinDbg extension and want to port it to ring0, it's simple enough to convert the code to a Softice extension. You install the driver with a dependancy on "NTICE" in the CreateService call, and register its sys name under
SYSTEM\CurrentControlSet\Services\NTICE\KDExtensions"
Forget about any mention of using KD2SYS.exe to convert a Windbg extension dll to a sys driver as mentioned in the Sice docs or early Mamaich example, it doesn't work and isn't necessary. The DriverEntry routine simply needs to be modified slightly since the driver is acting as a kernel dll.

When you load the driver, by whatever means, any exported ! commands you wrote will be immediately available in Softice. Don't forget that you can still use the /PROTECT and other options of IceExt at the same time. You can simply extend it with your own ring0 routines. Study the code of Mamaich and Sten, don't worry about translating any Russian text, there's no hidden information lost. If the time comes, I can certainly assist.

Kayaker

Well, well..It is working. Sort of.
I have a skeleton that loads to SI, and I can even use the exported extension commands. But when I do the 'net start' on the extension to load it, SI pops up due to page fault. Landing in hal, ntice, or just plain invalid (0:0). DriverEntry works fine, but I think it is the ..DllInit or something after that that is the problem. Driver loads fine when I don't register it in the KDExtensions, since SI doesn't try to load the DllInit, I guess. BTW, does SI even try to call the ExtensionApiVersion export?
A lot details about this was not covered in any of the articles I found on the subject. Also, there was a lot of conflicting information, mainly concerning the build process. I see Sten using the TARGETTYPE MINIPORT in IceExt, and some suggest using type DRIVER. Also on top of this it can be a executable image or DLL. I've tried all these combinations, but the GPF is still there. Build types of the DDK: Official MS documentation states that wdbgext's should be compiled in the w2k3/"wnet" environment, again I did not see any real effect between this, wxp and w2k (which eg IceExt uses).
The DllInit I am using currently does nothing but saves the extension APIs, prints some stuff (doing absolutely nothing here still creates the fault).
So..If anyone has a clue about this, am I missing some initialization or using wrong compile parameters (-D_DLL=1 /c /Zel /Zp8 /Gy /Gi- /Gm- -cbstring /W3 /WX /Gd /QIfdiv- /G6 /GX- /GR- /GF -Z7 /Od /Oi /Oy-)?

Dear blank,
Welcome to the wonderful world of the Windows DDK.

Note: A similar experience can be obtained by using the Microsoft DirectX SDKs and, to a a lesser extend, with the Platform SDK.

Entertaining, but not very helpful

thanks for laughs anyways!!
(I have yet to see a BSOD with user-mode code tho...)

And actually, all this is driving me to the OllyDbg direction. Maybe that is a good thing..Anyone ever did a poll between SI and Olly/Windbg? The "new" (2004) MS Windbg seems to have some interesting new features, comparing to the ancient version:
h__p://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/DW04044_WINHEC2004.ppt

BSOD, what's that? Heh, that's the benefit of developing drivers under VMware. I doubt it's your compiler options, you've left out how you handle DriverEntry. As I alluded to, things are a bit different from a regular DriverEntry. My response slowly grew and I decided to create a new thread, please see it here

http://www.woodmann.com/forum/showthread.php?t=7097

Kayaker