September 11, 2011 at 00:23Ridiculous nonsense
It just so happened that in my free time from my main job I started writing programs. Correct (possibly) programs, programs that I liked (and like) to write - programs that I like to use. While there are as many as two of them). In principle, these are quite large programs (more than 2 MB of source code each). When creating them, I came across “incomprehensible oddities” quite “wrong”, at first glance, the behavior of the compiler / program and the operating system. After the debriefing, once again I made sure that I was SZZB (to myself an evil pinocchio ). In any case, a couple of examples of how I was buggy and how to do it is not necessary (everything under vin32 - intel86).
Example One
Wasp(the name is what)). A program that intercepts calls of functions of third-party processes to dlls, and allows you to change the input / output parameters of these intercepted functions. The blended functions themselves are executed on the stacked machine - there are no problems with them. But in order to transfer control to them, you need to initialize the stack machine. To do this, you need a bit of memory where the jump will jump either from the beginning of the function being intercepted (of course, provided that it is successfully disassembled), or from the import tables of other PE files (exes and dllocks) loaded into the process memory. Memory can be taken in three places:
• To find a place in sections of a downloaded file - in the general case, is impossible.
• On the stack - perhaps, but troublesome.
• A bunch - and chose it.
The wasp loaded the dll into the memory of a third-party process, it allocated memory for the bytecode and filled it, allocated memory for pure x86 code that prepares the stack machine and calls it. And it worked. Everywhere. Almost everywhere). It was on whist that two instances of launched Far manager with an interval of less than 3 seconds, with intercepted file access functions, died. The processes said that they performed an illegal operation and will be closed. After spending an hour at the debugger, I realized the simplest truth - the memory allocated to the process from the heap may not be executable. For some reason, this had never crossed my mind before (heh, strange why). Sometimes, in certain situations, certain versions of Windows, when allocating memory with the new operator, can do what they have the right to give memory with an unexecutable attribute (read and write only).
An example of the second
Visual C ++ vs OSProtector
Protectors, they try to protect programs from evil hackers). And they also need memory, memory in the executable file. They take the memory either by increasing the size of the last section, or adding new ones, or even replacing the old ones (usually with the packaging of the sections). In any case, the protectors change the section table (located at the beginning of the file). Currently, Visual C ++ in the start code of compiled applications checks the integrity of the section table. If it has changed, then Runtime error R6002 floating point not loadedwhen you start the application. When trying to protect the same Far manager (v 1.7) with a protector, everything was fine. When trying to protect Far manager (v 2.0) with a protector, everything was not good - obviously it was compiled by a newer version compiler. Googling showed: www.manhunter.ru/underground/65_runtime_error_r6002_floating_point_not_loaded.html
One way or another, OSProtector, before transferring control to the start code, now restores the original attributes of sections of the protected file.
Example One
Wasp(the name is what)). A program that intercepts calls of functions of third-party processes to dlls, and allows you to change the input / output parameters of these intercepted functions. The blended functions themselves are executed on the stacked machine - there are no problems with them. But in order to transfer control to them, you need to initialize the stack machine. To do this, you need a bit of memory where the jump will jump either from the beginning of the function being intercepted (of course, provided that it is successfully disassembled), or from the import tables of other PE files (exes and dllocks) loaded into the process memory. Memory can be taken in three places:
• To find a place in sections of a downloaded file - in the general case, is impossible.
• On the stack - perhaps, but troublesome.
• A bunch - and chose it.
The wasp loaded the dll into the memory of a third-party process, it allocated memory for the bytecode and filled it, allocated memory for pure x86 code that prepares the stack machine and calls it. And it worked. Everywhere. Almost everywhere). It was on whist that two instances of launched Far manager with an interval of less than 3 seconds, with intercepted file access functions, died. The processes said that they performed an illegal operation and will be closed. After spending an hour at the debugger, I realized the simplest truth - the memory allocated to the process from the heap may not be executable. For some reason, this had never crossed my mind before (heh, strange why). Sometimes, in certain situations, certain versions of Windows, when allocating memory with the new operator, can do what they have the right to give memory with an unexecutable attribute (read and write only).
An example of the second
Visual C ++ vs OSProtector
Protectors, they try to protect programs from evil hackers). And they also need memory, memory in the executable file. They take the memory either by increasing the size of the last section, or adding new ones, or even replacing the old ones (usually with the packaging of the sections). In any case, the protectors change the section table (located at the beginning of the file). Currently, Visual C ++ in the start code of compiled applications checks the integrity of the section table. If it has changed, then Runtime error R6002 floating point not loadedwhen you start the application. When trying to protect the same Far manager (v 1.7) with a protector, everything was fine. When trying to protect Far manager (v 2.0) with a protector, everything was not good - obviously it was compiled by a newer version compiler. Googling showed: www.manhunter.ru/underground/65_runtime_error_r6002_floating_point_not_loaded.html
One way or another, OSProtector, before transferring control to the start code, now restores the original attributes of sections of the protected file.