04.05.05
Posted in General Posts at 11:17 am by sna
I have been using the Opera web browser for a long time now, but just the other day I decided that I wanted to know more about how the Wand feature works. Basically, what the Wand feature does is it saves form data such as login names and passwords and later recalls them at the click of a button. So for example, when you go to check your e-mail, instead of always having to enter the same login information over and over you can have Opera remember it and submit the form for you. Pretty handy, don’t you think?
My primary interest was not in the Wand technology itself (Internet Explorer has a similar feature called AutoComplete and I’m pretty sure FireFox has one as well). I was more interested in how the passwords are stored on disk. I did some research on the security of Wand files but there’s not much information to be found. The few relevant hits I did find are all rewrites of the same mailing-list response. The response originates from the Opera mailing-list, is about two years old (first published in February 2003) and can be accessed by going here.
The whole description of Wand security sounds pretty confusing but I get the feeling that it’s intentionally made out to be that way. The author of that post (Alex) also mentions that they’re using 3DES but knowing this is only marginally helpful. We still have to trace the code and see how it parses and processes the Wand data; hence, in time, we would have learnt about the cryptographic algorithm being used. My favorite part of the e-mail is “…it is possible to decrypt the wand.dat, however quite some Opera hacking and cryptography expertise would be necessary”.
I have tried making sense of the format of wand.dat but there is nothing sensible about it. It’s pure horror from beginning to end. Variable sized structures (possibly many different fixed size structures), unaligned data and a myriad of different flags. But, as luck would have it, there is a clean and straightforward structure for the actual encrypted blocks stored inside wand.dat. A highlighted block can be seen in this image. There are two very important points to note: The key length always equals 8 and, to try and put it simply, the size of the entire block always equals the size of the encrypted data plus 0×14.
Knowing this we can parse the blocks as we encounter them. It is sufficient to scan the Wand file for blocks and make sure any candidates conform to the observations we made earlier. The next logical step would be to figure out how the blocks are supposed to be decrypted. With a bit of debugging trickery it’s easy to find where Opera reads the key of a block and hashes it. Opera creates two hashes using MD5. The first one is of a hard coded key and the key from the encrypted block, and the second one is of the first hash, the hard coded key and the key from the encrypted block.
The resulting hashes together consist of 32 bytes of data. It’s around here somewhere that we are able to confirm what they said about 3DES. The first hash is split in two halves and used to schedule the same amount of keys. The second hash is also split into two halves. The first half is scheduled as a third key and the second half is stored away for a brief moment.
Let’s recap. We have three DES keys and a buffer with eight bytes in it, not to mention the buffer with encrypted data. The second half of the second hash is resurrected from wherever it was hidden away, and pushed on the stack. As now becomes apparent, Opera is using 3DES-CBC and the “extra” eight bytes are the Initialization Vector (IV). And that’s pretty much all there is to it. The unencrypted data will need to have any padding removed but that’s the story of Opera Wand passwords.
I wrote a small tool to do the decryption. It gives output similar to this and the source for it can be viewed and downloaded from here (needs OpenSSL to compile and link). By the way, the passwords shown in that image are bogus so don’t get your hopes up.
Supposedly, if you set Opera up to use a master password the Wand file will be encrypted in such a way that the password must be available to successfully decrypt it. I tried enabling a master password, but alas, it was all in vain as it refused to work. The master password dialog simply does not show and the Wand data is not encrypted differently. Visiting the Opera support forums I was able to confirm that this is a common problem as the forum is literally flooded with complaints about it.
I’m not sure exactly what the moral of the story is. It’s open to individual interpretation but if I were to comment on it I fear the subject would drift far from technical realms pretty darn quickly. Also, this is not an “attack” on Opera Software as I’m sure other browsers and their password-managers would be just as easily dealt with. I just happen to prefer Opera and use it for personal web browsing which is the only reason I chose it for this article.
As a final note, I’d like to suggest to Opera engineers that they hash the URL before storing it inside the Wand file. This limits the user in their ability to manage Wand passwords but it raises the security by so much that it is definitely worth it. It’s almost the same thing as having stolen a set of physical keys: If you can’t figure out which doors they open they’re not going to be of much use to you.
Edit: Somehow, when uploading this entry the second-to-last paragraph disappeared. It’s been fixed now.
Permalink
04.04.05
Posted in General Posts at 11:10 am by andreageddon
Yesterday I started a nice reversing job, a packer which is quite bastard! I loaded it with olly and… bam! The process terminates before the entry point is reached! Punching the case wasnt working, so i found the packer uses a simple but nice trick to execute code before the ep is reached, and trashes olly! It is not executed via dllmains or other external code, just the code in the exe image itself! I wont tell it for now 
i write a paper on it when i’m done this work.
Cheers!
AndreaGeddon
Permalink
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
Next entries »
