Alright, in response to some of the aimbot posts made in support, etc.. I decided to take some time and write a pixelsearching proof of concept Aimbot. I figure now when people ask for help about writing aimbots we can refer them to this thread .
I was actually surprised by the speed of PixelSearch. I was expecting it to be significantly slower than it was over such a large area. I did a few timed tests before I went forth and wrote this and the results warrented spending a little time on it. (40-60 miliseconds for a 1024x768 area!!)
However, you can tell that when the object is moving at a decent rate, pixel searching the entire screen would not be possible. In the Camper Strike example, when you have the setting "On + Autoshoot" you can see how it sometimes trails behind the faster moving targets. However, if you set it to "Snap-To Autoshoot" because it has a small search area... the targets are easily brought down.
-Snap-to (Scans an area 50sq pixels surrounding your mouse and if you get near a target it will snap to the target. It will then only scan an area of 10sq pixels while locked onto the target. Much faster)
I think the best aimbot for a FPS written in autoit (at least.. the best/easiest) would be a pixelsearch of a box around your mouse position and force you to "snap" to the heads of enemies. With the speed of pixelsearch in this proof of concept, I think it would be deadly.
Yes.. well, Lets say I was writing an aimbot for a FPS. Pixelsearching the entire screen might be a little too slow, but if I pixelsearched a reasonable square area around your mouse you would simply have to move the mouse "somewhat" close to your enemy, then it would snap to their head.
It has nothing to do with what process your AutoIt script "looks like". They progmatically block you from using commands like Send(), MouseClick(), etc, etc. Which is why the fake device driver gets around it. It emulates an actual mouse so the program can not tell the difference.