When software is good enough
Microsoft, Google and Apple make software for everybody. Millions of users run this software every day. It must be stable and user friendly, so that Aunt Judy and Average Farmer Joe can use it. If it crashes, clueless user can't do much about it - and that's bad. That's why these companies spend thousands of hours in testing and improving usablility.
On the other hand, reversers make tools. A specialized software for solving small and nasty problems, like hiding debugger, defeating specific protection or bypassing some authorization check. Tools are made by a reverser for a reverser, so there are completely different expectations for them. Nobody expects that today's DNGuard unpacker will work with next year's DNGuard binaries, or that DRM authors won't change their encryption mechanisms.
That's why reversers make tools that are just "good enough".
Olly, Confuser and de4dot
Funny thing happens when reversing tools suddenly become extremely popular. Newbies start using them, ordinary users start using them - and the expectations change. Suddenly the author is overwhelmed with extremely helpful "bug reports" like "cannot unpack latest reactor" or "obfuscation fails for my application". It's annoying, wastes reverser's time and is not helpful in any way. Therefore I totally understand 0xd4d's reaction:
There's no support. Don't email me if you can't use it or if it fails to deobfuscate a file obfuscated with an updated obfuscator.
Instead, try to update de4dot yourself. It's a lot easier than you think. If you can't, search the Internet and you should find a couple of forums where you can ask your question.
TitanHide is good enough
Earlier this month I made few posts about bugs in TitanHide. Are these real bugs? Yes. Is it important to fix them? Not really. Let's face it - there are literally dozens of ways to detect TitanHide. But until commercial protectors start doing that, nobody cares.
TitanHide works and does its job well - that's all that matters. smile
The two bugs I mentioned earlier
First bug was a confusion about CONTEXT_DEBUG_REGISTERS flags. You see, CONTEXT_DEBUG_REGISTERS is defined as
|
1 |
#define CONTEXT_DEBUG_REGISTERS (CONTEXT_i386 | 0x00000010L) // DB 0-3,6,7 |
which is quite unexpected. smile So, the code
|
1 2 3 4 |
OriginalContextFlags = Context->ContextFlags; Context->ContextFlags &= ~CONTEXT_DEBUG_REGISTERS; ... NTSTATUS ret = Undocumented::NtSetContextThread(ThreadHandle, Context); |
was accidentally removing CONTEXT_i386 flag from ContextFlags. Such call to should fail, I'm pretty sure it did fail in some cases in my VMWare, but in real world it works just fine.
Second bug is in checking if CONTEXT structure is writeable when calling SetThreadContext. Why should it be - SetThreadContext is only reading from it.. So, this pseudo-code lets you defeat TitanHide hardware breakpoint protection with ease:
|
1 2 3 4 5 6 7 |
CONTEXT cont = VirtualAlloc(0, sizeof(CONTEXT), MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); cont.ContextFlags = CONTEXT_FULL | CONTEXT_DEBUG_REGISTERS; GetThreadContext(hThread, &cont); cont.Dr0 = 0x00401000; cont.Dr7 = 0x000f0101; VirtualProtect(&cont, sizeof(CONTEXT), PAGE_READONLY, &dummy); SetThreadContext(hThread, &cont); |
Again, it's a small bug, nobody is abusing it yet, so there is no real reason to fix it.