[G2O] SpeedBlock

[Patrix]

GO doesn't support pre-compiled scripts

This statement isn't correct, G2O is supporting precompiled squirrel scripts.
http://www.squirrel-lang.org/squirreldoc...suretofile

You can generate the bytecode via this function using squirrel, or this one using squirrel with c++
http://www.squirrel-lang.org/squirreldoc...iteclosure

To prove my point, i had attached a bytecode script, try to load it just as regular script.
It registers a global function called "hello", which doesn't accept any arguments and doesn't return anything, just call the function and check the result.

You can download script from here
https://www36.zippyshare.com/v/K37vyNnm/file.html

And no, you can't do the same in pure scripts

That depends what you mean, but surely similar security checks can be done on server side, as you've pointed out, there is only one advantage of using modules.
Efficiency. Still, using g2o scripts would give the 'decent' efficiency results, i don't that the difference in execution time would be that much big (sure, squirrel scripts are slower, but they aren't that much slow to detect speed hack).

It's not an open source to make eventual bypass methods less obvious

Your method can be still reverse engineered, maybe it is hard, but not for someone experienced. And this approach has the other side of the medal.
One person (you) is currently developing the code, if your method works well, then everything is ok, the problem occurs when someone wants to improve your module, while you are no longer supporting it. Having both binaries (for client & server) experienced hacker can still figure out how everything works (and maybe even patch the module(s)), but this isn't very easy solution.

Client scripts can also be manipulated while module contains some special algorithm to detect that it's loaded and in desired form

Everything on the client-side can be manipulated, even your module (ofc not the 'back-end' module). Hell, someone can even prevent your module from loading by simply deleting it, or replacing it with it's own version (if the server isn't checking the file hash, then someone can replace this module with the 'fake' one). Even if someone is checking the checksum, there are still easy ways to prevent your module from loading (someone can inject it's own dll and then take ownership of the loading module process via bytepatch hook). Those methods that i've mentioned are one of many, it's plenty ways to mess with the game on your own pc.

No one can know for sure if I didn't include any malicious code into module. Same goes to GO, Windows, vaccines, etc.

That's true, still, making the module source available for public is propably the best solution, at least in my opinion (everyone has it's own opinion).

[Marbar]

Patrix,

I made that statement (about pre-compiled script) after testing output from https://github.com/mabako/squirrel-compiler, ended with index '<function_name>' does not exist error. Did second try with simple hello script and it's seems that it is this compiler case. So I revoke that statement.

I've experimented with many different time measurements, with both native and script code. The highest relative error with defined period within my module was below 1.7%. With squirrel script on G2O I managed to get 55% relative error. That's completely unreliable.

Publishing this source code would be equal to providing clear solution to nearly everyone, not for someone who's able to mess with reversing.
Deleting client-side module won't suffice. It will call event on server side. There is no need for additional hash checking, because modules are already handling it. Careless patching of the module will also be detected in a few cases. It contains some server validation with randomness and basic crypto. However, I see many possible attack vectors. I'm well aware of methods you mention. I do not intend to make it immune to any possible interference. In it's first release, bypassing is harder while source code isn't public. That's designed to stop most of users. For now. Current state allows to bypass module with just creativity, any knowledge is not essential (with source code).

I will gladly share the source code, but conditionally. Only when it meets Kerckhoffs's assumption.

[Patrix]

Good luck with you project then, looks that you're know what you're doing .

[Patrix]

If i may ask, i'm really interested how you've built the communication layer between your modules.
Have you used sockets, or something like that? I know that's implementation details, but i'm curious if this method have some downfalls comparing to using squirrel to handle the network connection (using different port to communicate with the server-side module?).

As i'm suspecting modules are using it's own communication layer due to efficiency reasons and propably easier setup for user (scripter).

[Marbar]

Modules are currently using script-side RakNet packets. Whole server validation has to be improved and rewritten. Currently, very few packets are transmitted between. That of course has some potential pitfalls connected with onPacket event. For example if someone uses similar structure of packet or differs with data type. If it stays like that (after future redesign), I will provide additional configuration of packet recognition. In terms of efficiency, by using scripts I avoided second TLS negotiation.
Actually, some improvements can be implemented with pre-compiled script. Currently, modules are using sq_compilebuffer function to provide scripts to VM. That client-side check to instantly detect missing module won't be required if it will be loaded by default way, separately from module.

[Piootrek86]

Wrzuciłem tak jak napisane, moduły się ładują ale i tak gre wywala po paru sekundach przez onSpeedBlockModuleMissing coś jest nie tak

[Sative]

IMO same can be done in pure scripts, also how someone can know for sure if you didn't include some malicious code into your module?

Super opcja, zastanawiałeś się nad wykryciem procesu cheat engine ?

Instead detecting cheat engine process, you can for example, detect dll injection.
https://reverseengineering.stackexchange...e-detected

Detecting one program isn't a good option, this can be easilly bypassed:
https://itstillworks.com/12458787/how-to...ocess-name
https://forum.cheatengine.org/viewtopic....063c0b99be

Keep in mind that any detection like this on c-side can be easily bypassed by an expierenced reverser.
You could also monitor some values periodically and check if their content is valid.

IMO it's better to focus on implementing server-side secure code, rather than making client-side security systems which can be bypassed one way or another.

We HAD dll-injection detector before, but we've got some problems due to several antiviruses injects them own dlls.