03.18.05
Posted in General Posts at 10:58 am by sna
I was asked yesterday to have a look at a computer (yes, I need to get this t-shirt, but only right after I get this mug) that was behaving oddly. In the process of “brooming and trimming” I ran across a number of adware/spyware and decided to take some of them with me, for later analysis. The one specimen that fascinated me the most was a 2821 bytes large file. It is recognized as Trojan-Downloader.Win32.IstBar.gen by Kaspersky Lab, but there’s no description available for it.
The reason it caught my attention in the first place is its size. Viruses discovered in the wild have over the last couple of years moved more towards using VBS and being written by 14-year olds. So finding this file (YES THIS IS A VIRUS DO NOT BLINDLY RENAME AND EXECUTE IT) sure felt like a fresh breeze.
Upon closer examination it turns out that the header is far from standard as it’s been modified to span the smallest area possible. You could remove some of the directory slots to make it even smaller but I suspect older versions of Windows wouldn’t approve. The overall structure of the file is a complete mess and there’s both code and data inside the header. If you look at the section headers you’ll see that the space reserved for a section name, 8 bytes, have been used to stuff functions into!
Moving on, the entry point is located near the end of the file, a mere 10 bytes from the end actually. Near the end of the file is also the import table. They share the space there and the entry point points inside the first and only import descriptor. It points at the time and date stamp which holds a jump to code located inside the header (yes, again the header). This is all pretty neat considering what it does for the file size but code in the header is a big no-no as generally a virus scanner would pick up on it immediately. A major abnormality also related to the import table is the fact that there’s no terminating empty import descriptor. I expect a number of common tools to choke on this, because the PE specification states that “The Import Directory Table consists of an array of Import Directory Entries, one entry for each DLL the image references. The last directory entry is empty (filled with null values), which indicates the end of the directory table”. Microsoft’s tool dumpbin handles it pretty well since at least it doesn’t crash or display random data.
As a side-note I can mention that earlier versions of HIEW fail to correctly disassemble the jump at the entry point. Without having investigated it I can only guess that this is because those versions of HIEW assume only sections are relevant jump targets. Luckily, it’s been corrected somewhere between version 6.85 and version 7.10.
The first section doesn’t exist on disk, but is expanded by the PE loader when the virus is mapped into memory. This way the virus doesn’t need to bother with memory allocation which in turn shaves another couple of bytes off of the total size. Code found in the header unpacks the real virus into the first section, then loads dependencies and resolves symbols. And all in less than 200 bytes… can you say efficiency?
Something tells me there were two or more people working on putting this file together. While the envelope is a sight for sore eyes, what follows after it isn’t nearly as exciting. Standard CRT startup code can be observed interfacing with the dynamically loaded runtime library. Then when it’s time for the good stuff what have we if not a bunch of calls into MFC code. Basically, what the entire virus does is it downloads a file and executes it. Knowing this, I’m not as impressed with the size of it as I was when I started writing this article. But the envelope almost made it worth the time…
Permalink
03.17.05
Posted in General Posts at 10:54 am by Devine9
VB6 Self-Modifying Code by SneakCharm
=====================================================
Resources : www.google.com
: brain
=====================================================
Self-Modifying code is a nice way to confuse and toy with crackers.
I enjoy doing it very much so, so I will present the theory behind it and
a working prototype!
The visual basic 6 language does not allow the use of inline assembler.
Thus, we must look elsewhere and a class module (COM) answers
our call.
The typical every day class module consists of a virtual table.
This table contains pointers to every method in our class. In theory, we
should be able to allocate a block of memory, move machine code there,
and rewrite the virtual table to point to the allocated memory.
This solves the problem of inline assembler, and then to self-modifying
code? All we have to do is rewrite the block of memory!
The real trick is mixing this with pcode compilation.
It’s a deadly mix of protection 
Download: support-files.zip
SneakCharm
March 17, 2005
Permalink
03.09.05
Posted in General Posts at 10:53 am by sna
I’ve written a C++ class based on the idea I presented last time. There’s not a whole lot to say about the code except that I hope it works. I haven’t had the opportunity to test it on Windows 98 or Millennium Edition but I don’t see why it wouldn’t work there (more on this later).
The class is called ‘RealAddress’ and since a picture says more than a thousand words, here’s what a test application using the class shows when you run it: Testing RealAddress on Windows 95.
The tiny test application gets the address of MessageBoxA by using GetProcAddress. It also imports MessageBoxA so it then fetches the address from out of its own IAT. Those are the top two addresses shown in the message boxes in the picture above. Note that these two addresses could be faked and point to debug thunks. To get the real addresses the test application turns to RealAddress.
RealAddress has a function, GetProcAddress, which works just like the real GetProcAddress, except it tries to bypass any debug thunks Windows throws at it. RealAddress also has a second function, GetThunkAddress, which you can use when iterating through an import address table. It too tries to bypass debug thunks.
The header file for RealAddress is here and the source code is here. Set tab width at 4 cols for pretty code.
Oh, I’ve commented out the check that tests if addresses are above 2GB. I figured it doesn’t really add anything and it locks the code down a lot. What if some weird Windows version decides that it wants to build the debug thunks on the process heap instead? BOOM! The class wouldn’t work any more. But with the check disabled it should work just as good anywhere else as it does on Windows 95.
There’s a super rare case where disabling the check is un-good. It happens when you’re using GetThunkAddress and the application is importing a variable. Imagine that the variable’s least-significant-byte is 0×68 and five bytes further away you find a pattern that matches the debug thunks’ jump pattern. It’s incredibly super unlikely that this will ever happen – but it could happen. The long jump really makes it all so much harder for it to happen, but beware.
Permalink
03.07.05
Posted in General Posts at 10:52 am by sna
On the now ancient Windows 95 and Windows 98 platforms, you can exhibit a rather strange behavior from GetProcAddress. The API will behave differently if the process invoking it is ran under a debugger. This effectively breaks one of the cardinal rules of debugging – rule number two states “Don’t change the behavior of the target app”.
Robbins mentions the problem both in an MSJ column of his and in his “Debugging Applications” book, but I am not completely content with his description of it:
“…under Windows 95, calling GetProcAddress in your program while it is running under a debugger returns a different address than when it runs outside a debugger. What is actually returned when running under the debugger is a ‘debug thunk’ – a special wrapper around the real call.”
And he goes on to say:
“Windows 95 doesn’t implement copy-on-write in the operating system. With copy-on-write, the operating system will share a common code page in memory, but when a process writes to that memory, the memory is copied so that the individual process gets its own copy that will not interfere with any other process. In the Windows 95 architecture, any memory that is above the 2GB line is shared among all processes. If one process were to write a breakpoint to this shared memory area without the copy-on-write, the breakpoint would apply to all processes, not just the one being debugged.”
So when you do GetProcAddress on a symbol it returns the address of a debug thunk. Note that with this design you cannot export anything other than pure functions from the system DLLs. The thunk consists of a measly two instructions, a push of the real API address and a jump to some function inside the kernel. Unfortunately I do not own a copy of Windows 9x (I assume Windows ME is also affected by this problem) so I have not been able to debug the kernel function. However, I know someone that does own a copy, and he was kind enough to let me run some tests on his Windows 95.
I prepared a small test application that resolves the LoadLibraryA and MessageBoxA API functions using GetProcAddress. The application also imports these functions through its Import Address Table (IAT) and upon running it the return values from GetProcAddress and the function addresses pointed to by the IAT are displayed in a message box.
There are three different cases that are of interest to us. The test application can be run normally, outside a debugger (1). It can also be started under a debugger (2) or it can be attached half way through (3). Here’s a figure showing the result of each of these cases: GetProcAddress tests
The leftmost box looks just like what we had expected, nothing to add there. The middle box, however, is a bit more concerning. You can see that the addresses do not point to the real functions, but what’s really annoying is that the address in the IAT and the address returned from GetProcAddress are not the same! As confirmed by the third box, if you attach a debugger half way through, the IAT will be patched to reflect the fact that the process is now being debugged.
I prepared another test that would call GetProcAddress and store all unique return values in a list so they could be counted. We ran the test for a while and the list held nearly 300 000 different addresses before the test was aborted. What I do not understand is this: Why are debug thunk addresses not cached? If they were, and the same thunk was recycled, breakpoints would actually work and trigger like they should!
What would have been better is of course if they hadn’t used debug thunks to begin with. It would be up to the debugger to know not to write anything above the 2GB line. Oh well…
But even with the current design it’s usually a non-issue. The problem only arises when we have a need to know what a particular IAT entry points to. With the IAT being filled of pointers to debug thunks, there’s no telling which entry points to what. A workaround proposed by Robbins is to traverse the original first thunk instead, and because it is essentially mirroring the IAT you will know what the real IAT entries are. This will usually work, unless, of course, there is no original first thunk. And as you may know Borland compilers do not emit an original first thunk.
I have another idea that might work. Debug thunks seem to always be constructed above the 2GB line, so if we invoke GetProcAddress a couple of times with the same symbol and get back different addresses all above 2GB, it would seem to indicate that we are being set up. We can then read the address being pushed in one of the thunks and save it for later. Also, don’t forget to take note of where the jump in the thunk goes.
When later looking through the IAT, if an address is above 2GB, we can see if what it points to matches the pattern of a thunk (0×68, ??, ??, ??, ??, 0xE9, ??, ??, ??, ??). If it does we read out the supposed jump target and compare it with the previously saved one. If the jump targets match we know that we’re looking at a debug thunk in the IAT.
I could write and post some code later to try the idea out.
Permalink
03.06.05
Posted in General Posts at 10:41 am by Devine9
Welcome to the newest addition to the reverse engineering team website. We’ve been considering some sort of file dump or blog system for a while now and during our last meeting decided that this was the best route to take. We’ll try this out for a while and see how everyone likes it.
We encourage anyone visiting this section of the site to take part in any topics that are presented and try to comment on them and provide more information on whatever the topic may be. Also, if you have any ideas or questions about this portion of the site, please contact us through the comments portion of the message forum.
Over the time that we have been around, members of RET have found that we have done a number of projects but just did not get them to a point where we wanted to release them. We will be using this website for the purpose of dumping these loose ends out to the public. If you feel that you are interested in whatever the project may be then we encourage you to take part in working on the loose end and sending back your comments via this blog. Perhaps this method might bring about some finished releases from what would otherwise have turned out to be a lost cause. Anyway, enjoy the blog, and we’ll see where it takes us.
~Devine Right
Permalink
