Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[G2O] SpeedBlock
#11
Marbar Wrote: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

Marbar Wrote: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).

Marbar Wrote: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.

Marbar Wrote: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.

Marbar Wrote: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).
Reply
#12
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.
Reply
#13
Good luck with you project then, looks that you're know what you're doing Wink.
Reply
#14
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).
Reply
#15
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.
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  [New G2O][Client-Side] LocalStorage Patrix 0 280 08.05.2020, 15:38
Last Post: Patrix
  [New G2O] Module example Patrix 4 3,636 17.05.2019, 00:30
Last Post: Patrix
  [New G2O][Client-Side] Clipboard Patrix 7 4,528 07.02.2019, 00:45
Last Post: Patrix
  [New G2O][Client-Side] Music Module Nubzior 3 2,569 24.05.2018, 07:07
Last Post: Nubzior
  G2O - Client Side Bots(0.0.4) KimiorV 16 7,889 16.01.2017, 09:47
Last Post: KimiorV
  [DEV] G2O Bot module Sative 64 27,339 25.11.2016, 19:13
Last Post: HammelGammel
  G2O Client side bots KimiorV 4 2,411 09.06.2016, 19:11
Last Post: KimiorV

Forum Jump:


Users browsing this thread: 1 Guest(s)