Gameguard bypass neuz.exe resolution problem

Making the AutoClicker/Bot

To make the bot I needed to be able to send two
types of messages to the game, namely clicks and key presses. I have
done this by posting messages to the game window's message queue. This
was done by the API PostMessageA. However GameGuard hooks this function
so I needed to bypass that first. This was done by what is known as a
trampoline. When GameGuard hooks a function in usermode, it goes to the
first 5 bytes of that function and replaces it with a jump to its own
procedure. It then goes around to all processes it can find and does
this. Now whenever any application calls this function (unless you hide
yourself from GameGuard), code execution will firstly go to GameGuard's
hook before it goes to the actual code of the function. GameGuard then
runs some sort of check to see if the function you are using is allowed
to pass and if not, it will block it. For example, for PostMessage, it
would probably check whether the window handle used matched the window
handle of the game it was protecting. So we can bypass this by
executing the real first 5 bytes ourselves first then jumping right
over GameGuard's hook and hence our function is never hooked.

So looking at the first few lines of the source for
the bot, I first of all use LoadLibrary and GetProcAddress to obtain an
address for PostMessageA. I then add 5 to that address to get it ready
for later use for the trampoline.
Next thing I wanted to do was to watch for FLYFF's
process and as soon as I found that, I could start looking for its
window. Bear in mind that the method I am using for finding FLYFF's
process will not work after GameGuard has loaded because it hides the
game's process.

To find the process, what I have done is to take a
snapshot of the current active processes with the API
CreateToolhelp32Snapshot. This fills in a PROCESSENTRY32 structure. I
can then iterate through this structure with Process32First and
Process32Next until I get a match of szExeFile (name of process). I
know when I have reached the end of the current snapshot because
Process32Next will return an ERROR_NO_MORE_FILES so I keep checking for
that and when that occurs, I can take a new snapshot.

Okay so now we have found the process in
PROCESSENTRY32 we can proceed to get a PID and handle for it. Another
member of the structure, th32ProcessID holds the PID for the process
selected. I then use OpenProcess to obtain a handle for the program.

Remember whenever you open a handle, to always close it again afterwards !
If not you will get what is known as a memory leak. If you are opening
a handle and not closing it in a procedure and your procedure is called
many times then you are basically using memory and not freeing it for
use afterwards so your machine will become bogged down and possibly
eventually crash.

Anyway once we have detected the process as active,
we can start watching for the window handle of the game. This is done
by looping FindWindow until it returns true. Btw you may be wondering
why we even bothered getting handle/PID earlier. Well I used this same
source to watch for a process for my DLL injector so that is what I
needed it for but I figured some people would want to see and maybe use
this code too.
To use FindWindow efficiently, to me this means not
just detecting by window name since that can lead to a wrong handle
obtained, I had to get the class name for FLYFF's window. I have
attached the application I made to do that also. All it does is use
FindWindow generally with only a window name and then uses GetClassName
to get the class name. Using class name and window name to detect a
window is much more reliable than just using the window name.

Okay so now we have a window handle to FLYFF. I'm
not sure how threads are usually made (being a beginner programmer) so
I'm not sure whether this method is strictly 'right' but it seems to
work anyway. What I did was created two threads, 1 for the clicker and
1 for the bot. I also created two events, one for each thread. Then I
created two new threads, passing the handle created from CreateEvent to
them.

Now I can have the 'main thread' wait for the other
two threads to finish before continuing with WaitForMultipleObjects.
After that, I can close all the handles, two from the events, two
thread handles and one target handle.

Let's look at the first AutoClick thread first. It
is in an infinite loop where 2 key presses are watched for. The hotkey
for ending the application and the hotkey for toggling the clicking. If
the toggle hotkey is pressed then we first fill in a POINT structure
using GetCursorPos to get the coordinates of the current mouse
position. Then we can send a click at that spot using our trampoline
function (I named it PostMessageX) and with WM_LBUTTONDOWN/WM_LBUTTONUP
as parameters (two calls need to made to PostMessage).

Now the other 'bot' thread does a similar thing. To
use PostMessage to send keys, lParam needs to be the scan code for the
key that is sent. So we can use MapVirtualKey to do that. And then the
same thing is done as above except with WM_KEYDOWN instead.

Now then, when F10 is pressed (to exit application),
both threads set the event that was created for them respectively and
then returns. The 'main thread' now continues and ends the program,
cleaning up open handles, etc.

Making the Draw Application

There are many bits of code which are very similar
or the same to the other application. First of all we set up the
trampoline but this time for TextOutA (I'm not even sure if it's hooked
but I set up a trampoline just in case). We then also watch for the
process by making snapshots and walking the PROCESSENTRY32 structure.

Now comes the interesting part. To draw directly
onto the game's screen, we had to first obtain a handle to the device
context that the game created for itself to render its graphics. Bear
in mind that the method I use results in flickering graphics but
DirectX/hooking DirectX is just that bit more complicated and I don't
want to go into it yet.

Anyway, we could just do a simple trampoline for
GetDC (which is hooked in ring3) but one thing to watch out for is that
the first 5 bytes is not the standard stack frame set up code that is
for most procedures, ie.


Code:

mov edi, edi
push ebp


mov ebp, esp

So it is better to get the bytes dynamically
and that is what I have done. In the IAT hook procedure, we first hook
the module's IAT so calls to GetDC no longer go to GetDC but to our own
function prototype declared as IATTrampoline. We need to use
VirtualProtect several times to first change protections so we can
write to the two places we are going to write bytes to and also to
restore the old protection.

After altering the IAT to point to our own function,
we now need to dynamically fetch and write the first original 5 bytes
to IATTrampoline. As you can see, that is done with some simple code
just below that. Notice if you scroll down that I made the first
instruction of IATTrampoline "push ebp" prior to writing the 5 bytes.
There is no reason you can't just have 5 NOPs there instead though.
Only reason I put that there was because OllyDbg (program I use for
debugging) does not recognise the procedure as a proper procedure
unless I did that (fussy bastard). I also added a possible exit
condition for the same reason (the exit condition can never be met of
course).

I know I have not gone through the process of the
IAT hook very clearly but I have written a short article explaining
exactly how to do it before so if anyone needs more help understanding
or wants to see it explained more fully, just shout and I'll post a
link.

Anyway after the IAT hook, we can call GetDC without
problems from GameGuard and get a device context for FLYFF's window.
The rest of the code from there on is pretty self explanatory. Remember
that neither of these applications are supposed to be complete
programs. Think of them as skeletons. I have given you source and
explained it so you can add any function you want or you can rip
functions out of it that you want and use them in your own applications.

Hope the source will be useful to some people and
sorry if you don't like my coding style, I'm still pretty new to
programming. Any questions ? Ask below.

How to use :
#1.) Run flyff.. (Wait till its fully loaded..)
#2.) Run the bot..
#3.) Click "Set Handle"
#4.) Click the flyff window (At the top bar where the title is)
#5.) If you did it right "Handle" and "Window" should not say "Not Set"
#6.) Log in to flyff...
#7.) Take out your pet and drag your feed to a hot-key..
#8.) Set the "Key" to witch ever hot-key you used (F1 - F9)
#9.) If you would like to use the "Alarm" click the little check-box..
and then you can set the time *Read "Notes" if you use this feature
#10.) Click "Start Feeding" and if you set it up right it should work!
Notes :
• Sometimes you have to use "Set Handle" more than once..
• Alarm : It has to be in the correct format I.E. (12:00:00 AM) if the
number is less than 9 then add an extra 0 in front on it.. I.E.
(12:01:05 AM) (AM / PM) must be in CAPS and it must be
Hours:Minutes:Seconds also when the set time is reached the selected
window will close and the bot will reset.. (This is safe..)
• The little "Slider" bar at the bottom changes the bots transparency..
• The cool thing about this bot is that the selected window dose not need focus..
• All functions have been tested and seems to work 100% (Report all bugs!)
Tray options :
• The tray has 2 menus "Bot" and "Target"
• The "Bot" menu includes : Start, Stop, Hide, Show, Exit.. yes you can hide the bot while its on...
• The "Target" menu includes : Hide, Show.. yes you can hide the Target
while the bots on meaning : it works even if the window is hidden
Credits :
Me for writing the bot..
Joostp for writing the "Bypass.dll" (Thanks!!)
Reminder :
If you use the bot please give me a thanks!
Also.. give Joostp a thanks : [Only registered and activated users can see links. ]
And if you find any bugs please report them back here...
Screen-shot :

Bot information :
Scripted in : AutoIt v3.x
Project type : Open source (Source included in download)
Bot version : 1.0
Download :
Host : Media Fire
File name : Feeder.zip
File size : 373.16 KB
Link : [Only registered and activated users can see links. ]