Helpful tips needed...

I'm going to ask a few questions, hopefully you guys are nice enough to answer them. lol.

Now I've been doing a little looking around and I've seen a lot of people with externals and internals, and I'm just wondering if it is just preference or is there a lot more that you can do with internal?

Coming from a c# perspective, I know a bit more than the "beginner" stages of C++. What would you recommend as a book for me to read?

I have heard a lot about sigs and everything like that. What are they and how would it be possible to change them?

I am looking at sources (for research not c&p) and see a lot of [junk] code. How would I successfully implement something like such and remain "undetected" for a long period of time? (What I would create would be private)

Would you say that creating your own classes for reading/writing memory would be better than to use what has already been created for beginners?

Where are some good directx/opengl tutorials on creating in-game visuals and stuff like that?

*EDIT* How would I be able to inject into a process as I've heard injecting into chrome or skype has worked in the past. How would I be able to do that and should I create an injector or go with a publicly available one?


I appreciate if you took the time to answer some/all of these questions and your effort won't be ignored. Thank you.

Internal = lets you call and hook methodes + faster

I didn't need to read a book, depends on how much experience you aleady have.

In code every method is put into asembly. With this asembly code you can create a fingerprint that will only fit to the method you "scanned" the signutures you will find are actualy the bytes that represent the asm code. You can create them with ollydbg or ida. http://www.mpgh.net/forum/showthread.php?t=1083252

if you dont share your hack and dont c+p too much and also dont send broken data (e.g. a ViewAngel that is not possible) you are fine.

Yes thats a good exercise

injecting into a process (not csgo) will not make that big of a difference especially if you dont share your hack. Your hack wil simply run in a subprocess instead of having its own. However it is necessary to inject into csgo if you want to be internal bc that way your cheat can acces the games memory directly without the win functions. You are fine with using a public injector

As you do have C# experience already you know you can do C# internals for csgo?
it's a bit of hussel but it works. I would post a link but I am not allowed to. pfft.

Orinion77 really useful tips thanks

@Orinion77 has already answered your questions, however, i'll answer them aswell with my opinions and thoughts.

How do cheats work?

Cheats are small little programs that manipulate the games memory. A game can use a variable for the players health which is stored in memory. If you reverse engineer the game you can find out how the game works and where this variable is located. After that you can keep writing 100 to that address to maintain your health. You could also find out how this address is accessed and NOP ( no operation instruction ) the instruction that subtracts health from your health address.

External

If you are external, you've got your own process. You can control your process while reading and writing memory from the game. However, reading and writing memory via ReadProcessMemory is very slow compared to direct access. It's still fast, you can still get over 100 RPM / WPM calls in a second, but it's alot slower than direct access. You can also call the games functions, however, not as easy as internally. You have to allocate space for each parameter in the game's process, copy the parameters in the allocated space and call CreateRemoteThread. To do so you need the functions address. You can easily find that by using a FindPattern function.

Internal

If you are internal, you've made yourself a Dll which you injected into the game's process. You are now part of the program, which means that you have direct access. The problem is, that you don't have the source code and therefore can't directly access certain variables via name since your compiler doesn't know about these variables. You can access memory via their addresses, however, reading that internally is much much faster. You can dereference pointers ( your memory address ) and get your values like that. To read the LocalPlayer pointer, you can just do
instead of having to get the modules base address by iterating through the processes, getting the process id and a handle to the process, iterating through the modules and getting the base address from a MODULEENTRY32 struct, then reading the pointer via ReadProcessMemory.

Also, since you are now part of the program, you can call game functions much easier. You don't have to allocate space for the parameters, you are now part of the game. If you got the address of a certain function, just call it. To do so you need a function pointer and a function declaration. The source engine however lets you cheat internally even easier. Each module of the game has to communicate to a different module in a certain way. They do so via an exported function in the modules called CreateInterface. It will pass you a pointer to a specific interface with virtual functions. You can call them by recreating these interfaces and calling CreateInterface. You can recreate interfaces by getting the functions declarations. You can look at some examples for calling vtable functions. You can also hook functions by replacing the virtual table pointer. The virtual table is a table of all the virtual functions this interface has. It contains all the function pointers to the functions. You can grab this pointer, replace it with your own function which has to have the exact same parameter types / order / calling convention, otherwise the game tries to push the parameter on the stack and call your function and you can't accept the parameter and thus result in a crash. Once your function is called you have access to the original parameters and you can do the stuff you want. After you've done your stuff you can call the original function again to not miss the games behaviour.

External via Dll

You can also create yourself a Dll which you inject into any other 32 Bit program and call ReadProcessMemory / WriteProcessMemory from there.
It behaves like an external cheat without having your own process.

You can read any book, however, i would recommend you the books from Bjarne Stroustrup, the creator of C++.
You can find them here: http://www.stroustrup.com/books.htmlⓘ .

http://www.mpgh.net/forum/showthread.php?t=1083252 .

Change your code in a way that the compiler will translate your code into different instructions. Knowing asm and how the compiler translates them is a good way to know how you will actually change the signature of your cheat.

Copy pasting public code will result in a signature which is publicly available. If you start from scratch and write your own cheat you'll in 99,999% of the cases end up with a unique signature which is not publicly available. Valve bans for public signatures, as long as you don't share your binary publicly, you won't have any trouble with VAC detections.

It's good to know what those classes are actually doing, though it's not necessary to create your own if a public one is doing the job just fine without leaking any memory. ( YES YOU STUPID STUPID PUBLIC EXTERNAL FINDPATTERN FUNCTION, YOU ARE STUPID AND LEAKING MEMORY! ). Sorry.

You can learn DirectX via online tutorials, however i strongly suggest you learning it via a good book or via university. The concept of graphic programming is a huge one and shouldn't be learnt via YouTube tutorials.

Some people claim using a public injector gave them a ban.

You can write your own LoadLibrary injector in 20 lines of code, there are some examples around there. What you basically do is you allocate memory for the path of your Dll, write it into the games process and call LoadLibrary via CreateRemoteThread. It'll do just fine and you shouldn't have any problems with detection because of your own injector.

Injecting into Skype will only work with an external dll. It's yet again slower than reading / writing memory internally.