Log in

View Full Version : Identifying SDK APIs without a library?


5aLIVE
December 21st, 2008, 05:27
I have a plugin that I woul like to investigate a little deeper with IDA.
I have the plugin SDK which doesn't include a library file therefore I cannot use FLIRT to create a signature.

The SDK includes header, .c, .cpp and .dsw sample files. I've looked through the header and c++ files but can't seem to find the plugin APIs I am looking for.

I would have thought there must be a .lib file somewhere but the plugin samples make no reference to one.

It would appear the sample plugins serve as a template which you use to develop to your specification.

What options do I have to help me identify the functions used in a compiled plugin in? Any help would be greatly appreciated.

Thankyou.

UPDATE: Having read through some more of the SDK documentation it is now clear that Core API is accessed through the main application which is running the plug-in. What type of linking/addressing is this commonly called? Is this a form of dynamic linking?

Its looking like the only way I can make sense of this is to study the plugin structure and then try to identify the functions of interest by inspecting of the plugins dead listing and debugging it as it runs.

FrankRizzo
December 26th, 2008, 18:30
Is it a DLL, an OCX, a .so, what kinda of package is it in? That will help us to better help you.

5aLIVE
December 27th, 2008, 08:12
Hi Frank, the plug-ins are compiled as DLLs although the application requires them to be renamed with .api extensions. I'm not sure what you mean by the kind of package that it is? Do you mean the name of the application that uses the plug-in? Lets just say that its an application that got a certain Mr. Skylarov in trouble at Defcon back in 2001.

I've managed to identify what looks like an MD5 hash algorithm or variant which is undoubtedy used to generate the decryption key. I'm trying to get to grips with what values are being passed to the hash ago and trying to see what is done with the output. The more I read about it, the more I can get a sort of feel for what the plugin in should be doing when I single step through parts of its code.

I think I need to revise on some areas of assembly language too, such as the different types of addressing, passing of arguments and variables. Then slowly but surely identify the key functions and try to learn who they work. I am making progress with this although it is slow as I don't get much time to work on it.

I take plenty of notes when I work on this so that I can pick where I left off with having to retrace my steps.

Darren
December 27th, 2008, 16:55
Hi,

Maybe I've got this wrong, but you could load the application into ollydbg and when it has started select View/Executable Modules (Alt+E) and you will see a list of loaded dlls or other modules select on a file your interested in and right click on that module and select view names (Ctrl+N) then you will see a list of names and you can set breakpoints on them

Hope that helps

Darren

5aLIVE
December 28th, 2008, 04:46
@Frank, I've just reread you question with a fresh pair of eyes. The SDK inludes header files for the various core APIs and .cpp template files with stub functions which you are required to develop.

The Core APIs are accessed through the main executable of the document reader. Being able to suceesfully identify these function calls in the plug-in would be a tremendous help in understanding the plug-in.

On initial inspection, the sample code doesn't offer much clues to help understand how it works. Maybe that got something to do with being a little rusty on understanding some aspects of C++ coding notation.

Is there anyway I can do this? Short of having to try and manually try to identify a particular call by consulting the Core Api function looking at the number of parameters it accepts and what it does and then stepping through the code in an attemp to find the matching function. There must be an easier way to do this I hope?

@Darren, Doing this will only show calls to the win32 API rather than the core APIs of the SDK.
For example, in the plugin I see calls such as :

02112857 FF90 38010000 CALL DWORD PTR DS:[EAX+138] ; Reader.0049BEB8
0211285F FF16 CALL DWORD PTR DS:[ESI] ; Reader.004A0543

These Core API functions are found in the code of the Reader executable.

UPDATE: I've just has the idea that I could compile the sample code plug in and produce the debugging symbols. Then I could single step through the code and then be able to identify those calls. I can then place comments in my IDA .idb file for the plug-in under invetigate and then apply these comments in Olly. Why I didn't think of this before I don't know, anyway, does this sound like a practical/workable solution to the described problem?

Any other thoughts or suggestions on how best to tackle this are most welcome What would you guys do when faced with such a task?

5aLIVE
December 29th, 2008, 11:24
Can anyone offer any help or advice on how they might go about reversing something like this please? Ive since discovered that the SDK v4.0 used to compile this is no longer freely available as it has been superceded by a later release (I've scoured the web for this). So compiling a sample plug-in using the later SDK may complicate matters in identiifying calls to the core API.

Darren
December 29th, 2008, 13:39
Your idea about compiling the source you have, sounds a good idea, it will probarly give you a feel for how the protection is used, you mention the SDK has been updated, it could be alot is still similar, I think the debug symbols route is a good one, you will probarly find how things flow in a similar order even though a different SDK, for example you might find the apis are in a similar order and similar params, unless some thing radical changed

Darren

FrankRizzo
December 29th, 2008, 14:19
If it's just a DLL renamed to .API, then you should be able to disassemble just like a DLL. Which should list its exports. You could also possibly get the function information that way. If the debugging info was left in the DLL, then IDA will pull it out, and use it to define what parameters are passed to each function.

Now, as for them being renamed. I don't think that's a big deal, that just means that they're probably loaded manually via LoadLibrary.

If I have misunderstood anything, please clarify, and I'll try to help.

5aLIVE
December 29th, 2008, 15:27
@Darren, I'll try to use the symbols generated from compiling the sample plugin to see if that will help me identify the name of the core APIs which are of interset to me. Thsi may take a while until I get familiarise with the VC6 environment which must be used in order to compile it succesfully.

@Frank, I'm able to break on the .api(dll) as it loads and single step through the code no problem. The plug-in I am trying to reverse engineer is used in a commercial product and therefore has the symbol table stripped from it. The PEDUMP/Dependency Walker tools only shows a single export called PlugInMain which is common to all plug-ins.

Ah hold on, you must mean the exports would be found in the reader application rather than the plug-in. Damn, none to be found in the main exe either.

Hmm, thinking about this some more, if the plugin is calling exported functions found in the main exe, will the compiled sample plugin include symbols for these functions in the symbol table? In this case , its the Dll that is actually making calls to exported functions in the main exe which controls the behaviour of the document reader. Normally its the other way around isn't it?

FrankRizzo
December 29th, 2008, 16:32
I was talking about exports in the DLL (api module). If there is only 1, then that's kinda weird. I would DEFINITELY compile up the sample, and see how it works. Trace it, or throw in some printfs, or something that would let you know where it was, and what it was doing.

Wait, you have the SOURCE to a sample, and you can't tell what it's doing? You could be studying the wrong thing here. Study the sample's source, and once you understand it, THEN, go to the target one.

5aLIVE
December 29th, 2008, 16:55
Quote:
[Originally Posted by FrankRizzo;78409]I was talking about exports in the DLL (api module). If there is only 1, then that's kinda weird. I would DEFINITELY compile up the sample, and see how it works. Trace it, or throw in some printfs, or something that would let you know where it was, and what it was doing.

Okay, I thought you meant the main exe, on account of the way the plugin calls exports from it.

Quote:
[Originally Posted by FrankRizzo;78409]
Wait, you have the SOURCE to a sample, and you can't tell what it's doing? You could be studying the wrong thing here. Study the sample's source, and once you understand it, THEN, go to the target one.


I think you're right, so far it looks to be the best option, I'll compile the sample plugin and study that and see what I can learn from it and then apply this knowledge to the target. Now where did I put my VC6 discs....

Darren
December 29th, 2008, 19:37
Another tip, if you can compile this sample source, you could load the .obj file into IDA and gain some knowledge and maybe able to use FLAIR with it as well

Darren

5aLIVE
January 2nd, 2009, 08:08
Just an update to this, I successfully compiled the sample plug-in and created different signature files using the pcoff and sigmake tools as well as using a couple of IDA plugins to covert the .idb file to a pattern. I also tried loading the object files directly into IDA with Gerbay's COFF object loader plugin. Sadly, none of these signature helped identify a single function. This could be for a number of reason such as compiler optimsations and differences in the SDK and possibly some other reason I am not aware of...

So it looks like I'll need to study the source of the sample as Frank suggests then debug it making use of the symbol file and then hopefully identfy some export calls of interest in the reader application then apply my finding to the plugin I want to analyse.