While I was an employee at G2, I maintained a modified version of “Insider”. Which is an older remote access server/trojan that was on the Internet. Around 2003 it was great, it connected outbound to an HTTP server for command and control. Fixes and improvements kept it going. Unfortunately, as time went along it became obvious that there were implementation issues that would only allow it to scale so much. That fact combined with the fact that some of the code was on the clock, I decided to start re-writing insider.
Now named Wintermute, I’m writing the code from scratch. It’s again a windows based implant/rootkit. I’ve moved it to a DLL and focusing on modularity and designing it to not be a standalone app. As such I learned a few interesting things about DLLs that I didn’t know before:
- Visual Studio 2008 pushes you toward a MFC Dll. This probably isn’t what most people (C programmers) want to do. Create a generic Win32 project and select the DLL option.
- During DLL initialization (functions called from Dllmain, the Constructor, or the Initialize function if MFC, cannot create new threads. To be more precise, new threads are created but do not begin execution. This is actually documented on MSDN here near the bottom of the article.
- MSDN Recommends exporting DLL functions with keyword __declspec(dllexport) in the function’s definition. Unfortunately this mangles the function name. MS calls the name “decorated”, but it makes it difficult to be sure the mangling will be predictable across builds to create a uniform entry point.
- The other option is to create a .def file. It has this format:
LIBRARY “wintermute”
EXPORTS
execute @1
In this case “execute” is the function name that is exported and the name that you can use when calling GetProcAddress()