Hack hiding

[lanman92]

I'm trying to unlink my module from the PEB linked list, but it doesn't seem to be doing it. Here's my code. It's only running through the loop one time, then stopping. Olly is still seeing it in the list. I can see that it's the first module loaded inside the process in olly, but it's obviously still being linked unless olly doesn't constantly refresh the list. Any, here's the code.

 
void UnlinkUs(void)
{
PPEB_LDR_DATA ldr = NULL;
PLIST_ENTRY pListEntry, pListStart;
PLDR_MODULE pLM;
__asm {
mov eax, fs:[0x30]; //PEB offset 
mov eax, [eax + 0x0C]; //PEB_LDR_DATA offset
mov ldr, eax;
}

pListEntry = ldr->InMemoryOrderModuleList; //store first link(circular...)
pListStart = pListEntry->Flink; //Set first link
while(pListEntry != pListStart)
{
pLM = CONTAINING_RECORD(pListEntry, LDR_MODULE, InMemoryOrderModuleList);
MessageBox(NULL, L"Module.", L"Module", MB_OK);
if(((DWORD)pLM->BaseAddress < (DWORD)placeholder) && ((DWORD)placeholder < ((DWORD)pLM->BaseAddress + (DWORD)pLM->SizeOfImage))) //only if it's my DLL
{
pListEntry->Flink->Blink = pListEntry->Blink; //replace for next link
pListEntry->Blink->Flink = pListEntry->Flink; //replace for previous link
}
pListEntry = pListEntry->Flink; //do next link
}
}

[ramey]

I could be very wrong, but as far as I know it only unlinks it for inside the module, and olly will always see it. Find a way to check from inside your DLL.

Haven't looked at code, don't have time! Gotta go.

[kynox]

Just so you know, all this hides from warden is your module name. No other scan uses the PEB.

[Cypher]

I could be very wrong, but as far as I know it only unlinks it for inside the module, and olly will always see it. Find a way to check from inside your DLL.

Haven't looked at code, don't have time! Gotta go.

You are wrong. The linked list is process local not module local, so as long as you do it properly (which he isn't, by far) nothing running in userland should be able to see it. You could probably retrieve it from the kernel mode list (I'm pretty sure there is one, but not 100%), but not from usermode.

Just so you know, all this hides from warden is your module name. No other scan uses the PEB.

It doesn't even do that. He's missing two of the other documented linked lists, one undocumented one, and he's leaving behind the LDR_ENTRY structure which can be recovered if you know what you're doing, and from there you can get the name and module base address (even if the PE header is gone).

[lanman92]

I added ZeroMemory() to get rid of the struct after I replace the previous/next pointers. Is there any reading I can do to learn about the other linked lists? I'm almost done reading Secrets of Reversing and they've only mentioned this list, at the point where I am. I'll search amazon for other windows internals books, I guess.

EDIT: Your ModuleCloaker is a nice resource.

[Cypher]

Still missing two 'documented' lists (In InLoadOrderModuleList and InInitializationOrderModuleList), and one 'undocumented' one (which is left as an exercise to the reader to find -- not even 100% if it still exists, your post is actually the one that reminded me of its existence).

Also, your module can still be very easily identified due to the fact the PE header is still valid and intact.

Furthermore, your code is one-way (you should really be able to reverse it -- trust me, it will be necessary if you want to be able to do dynamic loading and unloading), and its not compatible with x64.

Lastly, you're relying on a hardcoded offset into the FS register. Don't do that, you should be calling NtQueryInformationProcess to get a pointer to the PEB. Yes that is still not guaranteed to never change, but it will work across platforms, its more reliable, and currently works on all available Windows versions (unlikely to change in the near future).

[lanman92]

Okay, I'm a retard. I totally forgot about the other lists... Don't know why I did that, but w/e. I'll read on the functions you said and see if I can clean up my code as well. I'm sure there's a better way for me to check if it's my module, also.

EDIT: I'm running x64. What has to be done for it to be compatible?

[ramey]

Ah, thanks for correcting me, was indeed thinking of linked list!

[Cypher]

Okay, I'm a retard. I totally forgot about the other lists... Don't know why I did that, but w/e. I'll read on the functions you said and see if I can clean up my code as well. I'm sure there's a better way for me to check if it's my module, also.

EDIT: I'm running x64. What has to be done for it to be compatible?

I'm talking about making it compatiable for native x64. Atm your code won't even compile under x64 because of the inline ASM which is obviously for IA-32. You need to rewrite it properly for it to even begin to work.

Also, your code is pretty awful. Assuming you're using C++ not C.
1. Initialized variables as close as possible to the point where they are defined.
2. Use C++ style casts
3. Use the correct architecture-independent data types (DWORD_PTR, not DWORD).
4. Get rid of the macros. They are unnecessary.
5. Remove the 'void' from the param list, it's poor style in c++ code.
6. Make your strings character set independent. (Use the TEXT macro provided by the Win32 API.)

[schlumpf]

3. Use the correct architecture-independent data types (dword_ptr, not dword).
4. Get rid of the macros. They are unnecessary.
6. Make your strings character set independent. (use the text macro provided by the win32 api.)

< 3

[Cypher]

< 3

Sigh. There's a difference between a necessary and an unnecessary macro.

Necessary:
Compile-time logic and flag checks

Unnecesary:
Run-time unlinking of a module.

You should avoid the preprocessor when its unnecessary, but sometimes its unavoidable, those cases are acceptable.

Lrn2program kthx.

[schlumpf]

Lrn2irony finally ._____.

[Cypher]

Lrn2irony finally ._____.

Except it's not ironic, it would be ironic if I told him to use the preprocessor unnecessarily, but that's not what I did. The TEXT macro HAS to be compile time, his CONTAINS_ENTRY or w/e macro does not. It's a different situation and hence no irony exists, simply poor programming and a lack of understanding.

[amadmonk]

So here's a fun task: how to use templates to do strongly-typed detour-style hooks without preprocessor magic.

(Totally off topic, so if y'all wanna flame or delete, feel free.)

Was working on this last night; I know others have invented this wheel but I'm super rusty in C++ (was always more comfortable in C, to my detriment) and was working on it at like 3am last night. Decided that for a rusty C++ programmer trying to "correctly" (elegantly, usefully) write template classes with a factory object and a "manager" (something to roll all the hooks together and patch/unpatch them all at once, as well as exposing the "real" function -- which varies depending upon whether a hook is installed or not, and has to be strongly typed) ... at 3am, was not wise.

something like...

void __stdcall MyFunc(int someparm);

template <class T>
class APIHook
{
public:
	T GetRealFunction();
	bool Hook();
	void UnHook(); // probably should be bool, but failing to unhook is usu. fatal

	APIHook(std::string libName, std::string apiName, T& hookFunc);
};

APIHook<void (__stdcall *)(int)> myHook("SomeLibrary", "ZwSomeFunction", MyFunc);

(Excuse any obvious syntax errors; I'm at work and my Eclipse C++ plugin is currently borked.)

The prob with this is that I'd like to avoid the template syntax in the object construction. I know this isn't legal code, but it would be cool if I could do something like:

APIHook myHook("SomeLibrary", "ZwSomeFunction", MyFunc);

I know this isn't valid (compiler doesn't have a non-specialized APIHook type), but it would make the syntax WAY less cumbersome. Aside from the syntax error, all the info the compiler needs is there (the function pointer type can be inferred from the passed-in detour method, etc.)

Thing is, I'd really like to avoid doing this with a macro (I probably could make it work with the preprocessor, but that doesn't mean that I SHOULD).

I guess I could define a non-templated base class, but my rusty C++ always fails me in this case (non-templated bases of template classes... when I do I need to use the template syntax in construction? there are non-obvious gotchas in this design).

Like I said, I'm sure someone else has invented this wheel; I'm re-rolling it mostly to force my aging, rusty-in-C++ brain to start thinking about things like this again.

[Cypher]

Windows via C++ has a decent starting API hooking library (IAT/EAT). The one I'm writing is based off it.