New one to me... I have an app that installed from an msi file. It successfully installed so I removed the original msi file from my system.

When you try and register the app (regname/serial combo) it fires up msiexec. I know that its not using the original msi file as I deleted it. I manage to figure out that a tmp file, which is infact a DLL, is created in my tmp diretory and this dll has an exported function called 'CheckRegCode'. Promising I've had a look at the dll in w32dsm and I think I can keygen it, but I have two quesitons:

1) Where does this dll file come from?

It is created and removed from the tmp directory during every reg attempt. Its not the same size as any of the DLLs in the program diretcory.

2) Is there anyway I can use Olly to trace the DLL?

If I attach to the msiexec process in Olly the tmp file is not listed as an executable module to dump.

NOTE: Theres a .msi file in \windows\installer that has a random number name but the summary tells me in contains the logic info and data required to install the app. This msi file is only a fraction, less than 10%, of the size of the original msi file.

Any help, tutes or places to look would be greatly appreciated!

proggy create this temp file so change :

create ---------> open existing

http://members.lycos.co.uk/sssevennn/gotu.jpg

To find where the DLL comes from try to use filemon - it will give you answer immediately.

Sounds like a crappy installer to me, to begin with.

When an author creates an MSI file, he has the option to make shortcuts "Advertised". What this means is the files needed to actually run the program are NOT installed. What you instead get is a shortcut to some special system magic that will run msiexec on demand, when you click the shortcut, and install the files you need at that time. This saves disk space, because if a user never uses a program it doesn't get installed. Hence, it's only "advertised".

Also, an MSI file knows about what files it contains. If one of these files is missing in a feature, it will try to repair it when you run that feature. The author of this MSI probably messed up and had that DLL in the MSI project when it shouldn't have been. MSI sees it's not installed (because the app deletes it when you quit registering), so it runs. Meanwhile, the app creates the DLL behind its back. (Just a theory).

Regarding the MSI temp file, any MSI package you install puts a local cached package of the MSI on the system. This is used for the Add/Remove functionality, to know how to repair/remove itself.

-nt20

Thanks for your input guys. I'm getting somewhere now. I've established that its not infact msiexec that makes the call to the dll but instead the target. If I run the target with Olly, I can live patch it to make the program call my dll as opposed to the one its generating. Olly still doesn't seem to list the dll as an 'executable module' so I can't trace into it. Does anyone have any ideas on this?

Also, anyone have any tips as to analysing a dll to see number and/or type of arguments for the functions?

Ok, it gets worse.

I was having a feeling that the dll in question wasn't actually getting called. I made the patch so it pointed to my own dll and made my own dll an empty file. I still got the same message telling me my serial was wrong. So it can't possibly have been doing the check with the dll right? No other files are created during the process so the check must be internal to the msiexec thread! Argh.

I can't get anywhere. I've tried catching when it reads the serial, with GetWindowTextA, GetDlg... etc... even tried MSI own ones of MsiGetProperty... but they just seemed to bring up SQL instructions like "SELECT ? FROM ? WHERE ?".

Anybody any suggestions?

Exactly what do you mean with "made my own dll an empty file"? Make your dll display a messagebox in each exported function, including the DLLMain function, and then you can see if it's loaded and which functions are called. If it is loaded, use PSAPI functions or similar inside the dll to get all the info you want about the loader/caller process. Also, you can make your dll code call some obscure Windows API, and then put a global breakpoint on this API in Softice, then you can catch it during execution and easily trace back to the original caller to see exactly how everything works. And in addition to this, there are at least a thousand other ways too.

Be careful with your own DLL since you don't know how many parameters each function takes, you can't ballance stack so you could crash that app.
That olly doesn't list it in modules could mean that the DLL is loaded dynamicaly - is it listed when are typing the serial (maybee try BP loadlibrary).
Number of arguments should be clear when you look at the end of procedure - here should be something like ret x where x means number of bytes to pop off the stack after return. Then just look at the params. Or try to use IDA to disassemble the dll, it will show you the arguments.

By "made my own dll an empty file" I mean literally that... I completely filled the dll its was loading with NOPs, in the hope that the app would through some kind of error, crash or just anything to suggest it was actually bothered about the content of the dll. It didn't it smiled nicely and told me my serial was incorrect. So, I think reasonably, the serial check isn't done in the dll!

Using Olly I set a breakpoint on MsiGetProperty again (or whatever its called, something like that) and it broke. On theses BPs I could see the msi process reading in my username and regcode from the dialog box, but they were all refered to as UNICODE.

Gonna have to do a bit more reading I think, but to summarise:

1) The dll is not called during the regcode check.
2) If I have the address of where in memory my username is stored, is it possible to set a breakpoint in Olly on memory r/w like in SoftICE?

(Can't actually use SoftICE as it causes apps on my machine not to work and I haven't found a work around yet.)

Thanks again.

I'm not sure if filling the dll with nops was a good idea, since it probably failed to load - dll_main must return something to flag that all is alright. Maybee it just tried to load the dll and since dll didn't work it looked like bad serial. Try to put on the beginning of each exported function manually (haxeditor) CC opcode, but don't forget to write somewhere previous value - this way it will cause exception which olly breaks in.
Concerning the memory breakpoint - I think olly has similar feature. And concerning softice, if your machine isn't too old, try to use VMWARE, and use softice in this - for me it works like charm

Hm.

Seems strange, you say MSIGetProperty is reading your serial, etc. Seems like the MSI package might be the one doing your serial check, and the temp DLL is just a dll the MSI uses to do the check? You can, for example, tell an MSI package to run an external DLL function. When you do this in an MSI project, it puts the DLL into its binary table. When the function is to be called, it extracts it from the binary table into a temp and then calls into the DLL.

Using a tool named "Orca" you can open a compiled MSI file and search for those unregistered text strings, maybe it will lead you closer. (try opening that temp MSI file you talked about with it)



-nt20