philosecurity » Blog Archive » Interview with an Adware Author

Via acb, if you ever wanted the lowdown on what a useless PoS platform Windows is, in terms of what it lets the programmer get away with and the (in)security it provides, you really need to read this – though I must admit the use of scheme is pretty cool; I bet he was talking about siod.

my emphasis below

[…]

IE has a mechanism called a Browser Helper Object (BHO) which is basically a gob of executable code that gets informed of web requests as they’re going. It runs in the actual browser process, which means it can do anything the browser can do– which means basically anything. We would have a Browser Helper Object that actually served the ads, and then we made it so that you had to kill all the instances of the browser to be able to delete the thing. That’s a little bit of persistence right there.

[…]

The next thing that Direct Revenue did– actually I should say what I did, because I was pretty heavily involved in this– was make a poller which continuously polls about every 10 seconds or so to see if the BHO was there and alive. If it was, great. If it wasn’t, [ the poller would ] install it. To make sure the poller was less likely to be detected, we developed this algorithm (a really trivial one) for making a random-looking filename that was consistent per machine but was not easy to guess. I think it was the first 6 or 8 characters of the DES-encoded MAC address. You take the MAC address, encode it with DES, take the first six characters and that was it. That was pretty good, except the file itself would be the same binary. If you md5-summed the file it would always be the same everywhere, and it was always in the same location.

Next we made a function shuffler, which would go into an executable, take the functions and randomly shuffle them. Once you do that, then of course the signature’s all messed up. [ We also shuffled ] a lot of the pointers within each actual function. It completely changed the shape of the executable.

We then made a bootstrapper, which was a tiny tiny piece of code written in Assembler which would decrypt the executable in memory, and then just run it. At the same time, we also made a virtual process executable. I’ve never heard of anybody else doing this before. Windows has this thing called Create Remote Thread. Basically, the semantics of Create Remote Thread are: You’re a process, I’m a different process. I call you and say “Hey! I have this bit of code. I’d really like it if you’d run this.” You’d say, “Sure,” because you’re a Windows process– you’re all hippie-like and free love. Windows processes, by the way, are insanely promiscuous. So! We would call a bunch of processes, hand them all a gob of code, and they would all run it. Each process would all know about two of the other ones. This allowed them to set up a ring … mutual support, right?

So we’ve progressed now from having just a Registry key entry, to having an executable, to having a randomly-named executable, to having an executable which is shuffled around a little bit on each machine, to one that’s encrypted– really more just obfuscated– to an executable that doesn’t even run as an executable. It runs merely as a series of threads. Now, those threads can communicate with one another, they would check to make sure that the BHO was there and up, and that the whatever other software we had was also up.

There was one further step that we were going to take but didn’t end up doing, and that is we were going to get rid of threads entirely, and just use interrupt handlers. It turns out that in Windows, you can get access to the interrupt handler pretty easily. In fact, you can register with the OS a chunk of code to handle a given interrupt. Then all you have to do is arrange for an interrupt to happen, and every time that interrupt happens, you wake up, do your stuff and go away. We never got to actually do that, but it was something we were thinking we’d do.

We did create unwritable registry keys and file names, by exploiting an “impedance mismatch” between the Win32 API and the NT API. Windows, ever since XP, is fundamentally built on top of the NT kernel. NT is fundamentally a Unicode system, so all the strings internally are 16-bit counter Unicode. The Win32 API is fundamentally Ascii. There are strings that you can express in 16-bit counted Unicode that you can’t express in ASCII. Most notably, you can have things with a Null in the middle of it.

That meant that we could, for instance, write a Registry key that had a Null in the middle of it. Since the user interface is based on the Win32 API, people would be able to see the key, but they wouldn’t be able to interact with it because when they asked for the key by name, they would be asking for the Null-terminated one. Because of that, we were able to make registry keys that were invisible or immutable to anyone using the Win32 API. Interestingly enough, this was not only all civilians and pretty much all of our competitors, but even most of the antivirus people.

We also wrote a device driver and then a printer driver. When you write a device driver you get to do all sorts of crazy things, even crazier than the things you typically get to do in Windows. This was right around the time that the company [ got sued by Eliot Spitzer and started shrinking ]. They made a somewhat poor business decision at the same time to get visible, and they branded their ads and everything at the same time that they were having me kick all of our competitors off and we were doing all that persistence stuff.

There was also of course Scheme. Eventually, we got sick of writing a new C program every time we wanted to go kick somebody off of a machine. Everybody said, “What we need is something configurable.” I said, “Let’s install a Turing-complete language,” and for that I used tinyScheme, which is a BSD licensed, very small, very fast implementation of Scheme that can be compiled down into about a 20K executable if you know what you’re doing.

Eventually, instead of writing individual executables every time a worm came out, I would just write some Scheme code, put that up on the server, and then immediately all sorts of things would go dark. It amounted to a distributed code war on a 4-10 million-node network.

S: In your professional opinion, how can people avoid adware?

M: Um, run UNIX.

Comments

One response to “philosecurity » Blog Archive » Interview with an Adware Author”

  1. Craig Overend

    The most interesting part of the story for me, was the symbiotic-like relationship that formed. He the symbiot with a host performing the removal of other competitors adware and viruses.

Leave a Reply

Your email address will not be published. Required fields are marked *