dll to c language source code conversion

I take it you've not used the tool I left a link to earlier?
I understand and am conversant with all of the points you mention. In fact, I learnt a huge amount 20 years ago only equipped with TASM(turbo assembler), TD(turbo debugger), Sourcer(disassembler) and anything my friend would bring me that he'd downloaded from his BBS.

1. You know the address of a variable that's been passed onto the stack. You can then examine the way that said address is used and from that, infer the type of data. It's not bomb-proof, but it works in the stunning majority of cases I've encountered. The remainder of cases simply need the decomp engine to be provided with a few hints - hints you can give it from reading the disasm.

2. See answer #1

3. If you unroll a loop, you repeat the same instructions N times, where N is the level of loop unrolling. A compiler has no trouble unrolling it. I'm curious as to why you think that a person/program couldn't re-roll a loop.


Anyway, here's a trivial example, using MinGW g++ 4.7.1 - Decompiled using Hex-Rays IDA Pro v 5.5.0.925t (32-bit) 2009 edition.

IDA was provided with precisely 2 pieces of information by me.
1) The DLL file
2) The fact that it was to analyse a DLL (rather than a PE executable, .ocx PE ActiveX control, PE/LE/NE Device Driver, COFF/OMF object file, COFF/OMF Static Library)

Furthermore, the DLL was compiled in release-mode, with the compiler option "Strip all symbols from binary (minimizes size) [-s]" checked.

--------------------------------------------------------------------------------------------
Input
--------------------------------------------------------------------------------------------
#include "main.h"
#include <stdio.h>

// a sample exported function
void DLL_EXPORT SomeFunction(const LPCSTR sometext)
{
MessageBoxA(0, sometext, "DLL Message", MB_OK | MB_ICONINFORMATION);
}

extern "C" DLL_EXPORT BOOL APIENTRY DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
// attach to process
// return FALSE to fail DLL load
break;

case DLL_PROCESS_DETACH:
// detach from process
break;

case DLL_THREAD_ATTACH:
// attach to thread
break;

case DLL_THREAD_DETACH:
// detach from thread
break;
}
return TRUE; // succesful
}

extern "C" DLL_EXPORT void ShowMouseLoc(HDC hdc, LPARAM lParam)
{
char str[80];

wsprintf(str, "Button is down at %d, %d",
LOWORD(lParam), HIWORD(lParam));
TextOut(hdc, LOWORD(lParam), HIWORD(lParam),
str, strlen(str));
}

extern "C" DLL_EXPORT void ShowMouseRoll(HDC hdc, WPARAM wParam)
{
char str[80];
signed short Roll;

Roll = HIWORD(wParam);

sprintf(str, "Mouse Rolled: %4i", Roll);
TextOut(hdc, 0, 0, str, strlen(str));
}

--------------------------------------------------------------------------------------------
Output
--------------------------------------------------------------------------------------------
signed int __stdcall DllMain(int a1, int a2, int a3)
{
return 1;
}

BOOL __cdecl ShowMouseRoll(HDC a1, int a2)
{
char v3; // [sp+20h] [bp-5Ch]@1

sprintf(&v3, "Mouse Rolled: %4i", SHIWORD(a2));
return TextOutA(a1, 0, 0, &v3, strlen(&v3) - 1);
}

BOOL __cdecl ShowMouseLoc(HDC a1, unsigned int a2)
{
char v3; // [sp+20h] [bp-6Ch]@1

wsprintfA(&v3, "Button is down at %d, %d", (unsigned __int16)a2, a2 >> 16);
return TextOutA(a1, (unsigned __int16)a2, a2 >> 16, &v3, strlen(&v3) - 1);
}

int __cdecl SomeFunction(const CHAR *a1)
{
return MessageBoxA(0, a1, "DLL Message", 0x40u);
}


Perhaps you and I have different definitions of decompile? certainly, the code doesn't retain all of the features of the initial source-code. A perfect case-in-point is DllMain.

Indeed, the output is not a perfect facsimile of the original input - I never claimed it was. I'm not a perfect driver on the roads either, but that doesn't mean that I can't drive.

I suggest you look more closely at the DLLMain functions. Notice how in this example, the original doesn't actually do anything? So in essence, they are the same. The disassembly of each is identical too. Trivial examples almost always fail to properly indicate performance on real-world examples.

Any reasonable bounds-checker will catch the fact that we're trying to sprintf to a single char, rather than an array of them - so this mistake will be caught by all but the least competent of programmers.

A quick check of the disassembly of both the original version and the decompiled version shows them to be almost identical. After changing char v3; to char v3[80]; the disassembly is identical. As you're no doubt aware, the return value is found in EAX. So, whether or not the program uses this value, it is still actually returned. Syntactically perfect? Nope. Binary identical? Yup.

As for the return-type of the functions, don't forget that sizeof(BOOL) == sizeof(int), the fact that we're putting 1 into an int, rather than true into a BOOL, doesn't change the binary output. It does muddy the water somewhat, but is a perfectly functional equivalent - in cases, it's actually better.

Take for example, DIALOGPROC - the window procedure for a dialog box. The common wisdom (& MS stipulation) is to make this function return a BOOL. It doesn't need to. If it returns an LRESULT, you actually get more functionality, not a reduction or an error in execution. A perfect example is handling a WM_CTLCOLORSTATIC message. Looking at the docs, one sees that handling the message should result in the function returning a HBRUSH. Yet, DIALOGPROC 'should' return a BOOL.
This appears to indicates that handling this message should not be possible. (And indeed the compiler moans bitterly if you try to return a HBRUSH from a function marked as returning a BOOL) However, if one instead tells the compiler that DIALOGPROC returns an LRESULT, then guess what? It works as is expected - windows uses the returned HBRUSH to do the painting.

Anyway, thanks for the discussion. Ten years ago, my answer may have been more closely aligned with yours. However, some years of reverse-engineering experience has taught me that (!perfect) != (!possible).
As I said earlier, I think the largest difference in our positions comes from the working definition that we each have of "decompile". I can't throw a perfect 180 in darts, but I can still play successfully..