Memory Questions

[Zen]

Hi all.

I remember reading somewhere about some program that patches a DLL in memory when it is loaded, so that it doesnt have to be modified (I think it was something like one of the windows theme DLL's). But when I was thinking back to college, is memory not supposed to be protected? i.e. If I make 2 programs, one should be able to access data from the other (unless im using DDE or some other method). So why is this possible and why is it used?

Lewis

[Mike Stefanik]

What you may be thinking of is the ability to inject a DLL into another process, which is possible to do (on Vista it would require that you run with elevated privileges and there's still some additional restrictions because it's a common technique used by malware to "hijack" a process). Now, if you're talking about self-modifying code, that's something that was nuked in Windows XP SP2 with the introduction of DEP. With DEP enabled, it's not possible to execute code that's marked as data.

[Zen]

Well I think what it was, was the "Injecting". I've remembered now that it was a program that patches the uxtheme.dll in memory (thats what it said) because windows would not allow users to use themes if they were not digitally signed by microsoft.

But how does this actually work? Would someone need cracking skills or something? Don't wory im not getting up to no good Just curious as usual.

Lewis

[Ionic Wind Support Team]

I have seen that program I don't think it patches it in memory, just patches the DLL after freeing the library.

Unless it patches it for only one process.  DLL's are mapped into each process address space that uses them.

[Zen]

I think it was StyleXP or something along those lines. I am not exactly sure of how it did it, just thats what I thought it was anyway.

The thing I don't understand though is how does it actually attach or attack the process and then how does it know what it is actually looking for? I guess its not your aerage every day programming stuff

Lewis

[Ionic Wind Support Team]

Actually it is not too hard.  Using the debug helper DLL from Microsoft you can attach to any running process as a debugger, find the handle to a loaded DLL and read and write that processes memory, changing memory security bits as needed.

[Zen]

Ohh right. But how would you know what it is in the memory you are reading? For example if I made a program with a load of classes in the memory and UDT's in the memory, someone who didn't know that, how would they know what it is?

Lewis

[Ionic Wind Support Team]

Two different things.  Getting the handle to a a loaded DLL is easy as the system keeps a list of each processes use.  Since they know the name of the DLL, and where the check is for digital signatures (probably by reverse engineering, disassembly, etc) then modifying it just depends on verifying it is the correct size and version before the patch.

[Zen]

Ohhh right. So things like patching the uxtheme dll is more of a thing for crackers and asm guru's. Are there any other real uses for things like this other than Debuging and hacking windows lol?

Lewis

[Mike Stefanik]

Programs that depend on the ability to inject code into other processes and so forth are going to quickly find themselves on a very short leash. Particularly when 64-bit systems start becoming common place where everything, including the kernel, can be locked down tight as a drum. Vista is really the transition to a more secure Windows platform, just a taste of what's to come. I like to use the analogy that the transition to Vista is similar to how Windows 95 was the transition system to the 32-bit world.

A lot of the "clever" things that programmers have been able to manage in Windows is being systematically eliminated. In some cases they'll be replaced with official, approved methods supported by the operating system. In others, they just won't work anymore. Slowly but surely, Microsoft is intentionally transforming Windows from a "wild, wild west" type of environment where anything goes to something that is a lot more restrictive. People will snivel, of course. But in a world where every computer is being connected to one another over the Internet, it's a necessity. With computers, I do believe security should trump the freedom to do whatever you want.