Yeah, I learned tons about Windows internals. Three standouts:
1: We never hit a limit to what you could do to the stack. It was trivial to write a function F that would fake the stack such that you would then "return from" some other function G (that had never actually been called) to yet a third function H that did something you wanted. This turned out to be useful in creating self-deleting executables.
2: There were several cases in which backward-compatibility APIs created opportunities for the clever. One example was the handling of registry strings. They are, internally, WinNT counted unicode strings, but are generally accessed by older Win32 apps, which use C strings. This means that you could create a registry key using the WinNT APIs, where the string identifier for the key had a null byte in the middle. Then Win32 apps (like some written by competitors to kill our apps, and also regedit) would be unable to do anything to that registry key, because it literally could not express the key's name.
3: windows is CRAZY hackable. It supports an API called CreateRemoteThread, which lets you start a thread in some other, random process, running arbitrary code that you specify. This means that if you can get a file down to the machine and execute it, it can load a bunch of bytes into memory, tell other processes to execute them, and terminate, using 1: above to delete itself. This made it a fairly hard target for most removal techniques-you'd have to find all the threads, out of all the threads running on the system, that were running my code, and kill them before they could replicate into another process and/or find the processes that were killing their siblings and retaliate.
Windows also allows random processes to tell the OS that they are SO IMPORTANT that the OS should immediately BSOD on that process terminating. We never used that one.
As far as stuff I still use today, no specific technical techniques, but lots of general things:
- It's crazy how fast you can level up with a hard problem and room to run. I knew basically nothing when I started, and within a year or so, the team I ran and I had done some pretty cool stuff, and beat the hell out of a lot of other companies. For a while, I was told that installing our adware was the best way to uninstall some obscure but horrendous russian malware.
-Tools trump humans. Lots of other companies were trying to clobber us at the same time we were clobbering them. We mostly won, and in several cases completely ran the table against the other company. (by which I mean we wiped them completely off the machines that had both their client and ours, without losing a significant number of machines ourselves). It wasn't that they were dumb or we were geniuses, but we would write like 10 lines of scheme and they would have to write a whole new executable, probably a few thousand lines. Probably lots of coders were faster than us, but not many were 100X faster.
There were probably others, but those are the standouts.
Having had my Milgram immunization, I would probably be able to resist the temptation. :)
That said, I doubt anyone would be particularly interested: all of this is pretty out-of-date: I was pretty good with Wins ME, 98, and XP, but I don't know anything about Vista and more recent versions. It wasn't _that_ hard to figure this stuff out-the TLAs must have vastly better people.
It does make me wonder what's going on in China, though: I'm told they are basically all XP. Is there an insane amount of hacking going on there? I've periodically thought about setting a honeypot to see what's up. It turns out to be really hard: you can't just run XP in a VM, because most VMs are (were?) detectable by even a moderately sophisticated attacker. The best idea I had was to have an external box record all the traffic in and out, and have a process on-box watch for new processes and track them. Maybe I would find some interesting beasties.
What do you mean you could write 10 lines of scheme where there would have to write a whole new executable? Did you have some really applicable template or something, or are you just implying that Scheme is vastly more productive than C?
I talked with some of the opposition later in job interviews, and they would typically write/modify a program in C that would find and kill our client. Their process tended to be: get a machine with our client, write a program that would find some trace of us and kill it, but not get everything, edit C, reinstall, recompile, repeat.
My process was: get their client installed, poke around in repl until I was confident I could find it and all its friends, write a function to clobber all of that, then iterate if needed. Where they would have to edit/recompile/run, I would just do a new thing in a repl. Then, too, my code was shorter, mostly from scheme vs. c and partly because I had better libraries than they did.
1: We never hit a limit to what you could do to the stack. It was trivial to write a function F that would fake the stack such that you would then "return from" some other function G (that had never actually been called) to yet a third function H that did something you wanted. This turned out to be useful in creating self-deleting executables.
2: There were several cases in which backward-compatibility APIs created opportunities for the clever. One example was the handling of registry strings. They are, internally, WinNT counted unicode strings, but are generally accessed by older Win32 apps, which use C strings. This means that you could create a registry key using the WinNT APIs, where the string identifier for the key had a null byte in the middle. Then Win32 apps (like some written by competitors to kill our apps, and also regedit) would be unable to do anything to that registry key, because it literally could not express the key's name.
3: windows is CRAZY hackable. It supports an API called CreateRemoteThread, which lets you start a thread in some other, random process, running arbitrary code that you specify. This means that if you can get a file down to the machine and execute it, it can load a bunch of bytes into memory, tell other processes to execute them, and terminate, using 1: above to delete itself. This made it a fairly hard target for most removal techniques-you'd have to find all the threads, out of all the threads running on the system, that were running my code, and kill them before they could replicate into another process and/or find the processes that were killing their siblings and retaliate.
Windows also allows random processes to tell the OS that they are SO IMPORTANT that the OS should immediately BSOD on that process terminating. We never used that one.
As far as stuff I still use today, no specific technical techniques, but lots of general things:
- It's crazy how fast you can level up with a hard problem and room to run. I knew basically nothing when I started, and within a year or so, the team I ran and I had done some pretty cool stuff, and beat the hell out of a lot of other companies. For a while, I was told that installing our adware was the best way to uninstall some obscure but horrendous russian malware.
-Tools trump humans. Lots of other companies were trying to clobber us at the same time we were clobbering them. We mostly won, and in several cases completely ran the table against the other company. (by which I mean we wiped them completely off the machines that had both their client and ours, without losing a significant number of machines ourselves). It wasn't that they were dumb or we were geniuses, but we would write like 10 lines of scheme and they would have to write a whole new executable, probably a few thousand lines. Probably lots of coders were faster than us, but not many were 100X faster.
There were probably others, but those are the standouts.