SP does not work CS:GO

[MrMalina]

After today's update CS: GO SP (Revision as of April 20, 2016) gives this error:

[D3CEPTION]

server structure changed due to the new mm system, there might have been some internal changes. someone eager could write an offset parser and integrate it @ server init. not sure if this would be in the interested of the devs though

[MrMalina]

On linux running, on windows give error.

[satoon101]

Yes, a signature must have changed from the update. We will get that fixed when one of us has time.

[D3CEPTION]

im not sure at all, but from what ive seen in ida, linux assemblies have much easier readability, basically string 1:1 comparison.. so maybe mb sp already added some offset fixer if the server is running linux? and thats why its working? just curious

[satoon101]

No, Linux uses symbols, not signatures. Symbols don't typically change, ever, whereas signatures very easily can.

[D3CEPTION]

okay, so never mind the word "offset fixer". string literal -> function call on linux?
as long as the byte structure of the functions doesnt change, shouldnt my idea with an offset parser for windows work?
sp -> entrypoint into server memory -> assembly decode -> signature array -> insert into python code
(shouldnt this be possible on python-level?)

this might even clean up the .ini files, in case there is no other use of them ofc..

[Ayuto]

I have updated the global pointer data. CS:GO on Windows should work again:
https://github.com/Source-Python-Dev-Te ... 27051bb481

So, what you are suggesting is getting the signature of a function + a signature to retrieve the offset to the pointer? We could simply use signatures that directly point to the pointer. Then the offset would always be 0. The only thing I would need to change would be the script I'm using to create the signature. It might be worth updating the script. However, usually not only offsets change, but the function's signature as well. So, I would end up updating the data anyway.

[D3CEPTION]

yes, route directly to the desired class/function. as long as valve doesnt obsfuscate the byte structure, which wont happen, it should always have the same decode-algorythm, right? do you use the inis for any other purpose?

although when i made the post i forgot that these major updates, dont usually happen

[Ayuto]

as long as valve doesnt obsfuscate the byte structure, which wont happen [...]

It happens when they update a function, use different compiler settings or the compiler itself decides to generate different bytes, because it has been updated, changed or whatever. That's exactly the reason why signatures break from time to time.

I hope this example helps to understand what I was talking about.

Code: Select all

Random example bytes:
8B 0D FC DB 9D 10 8B 35 64 DB 86 10 46 8B 01 8B 40 08 FF D0 84 C0 74 06 8D 9B 00 00 00 00 E8 48 63 F7 FF
            |                                               |
            Start of the function                           Start of the pointer
           
Current procedure:
1. Get a signature for the start of the function (e.g. 9D 10 8B 35 64 DB 86 10 46 8B 01 8B 40 08).
2. Get the number of bytes from the start of the function to the start of the pointer (e.g. 16).
3. The pointer address is at "function address" + "byte count".

Other possibility:
1. Get a signature for the start of the pointer (e.g. 84 C0 74 06 8D 9B 00 00 00 00 E8 48).
2. Since that signature already provides the correct address, we don't need to add an offset.

So, this is easily possible without any changes! We just need to use different signatures.

[D3CEPTION]

my terminology just was complely off, im not used to this field of coding. ive looked into ida again and ofc im not talking about bytestructures, im talking about writing mechanisms in python for each function, to decode opcodestructures performed by subroutines. the subroutines, how registers etc get handled, shouldnt get changed by valve, as long as they dont update how the function works internally, right?

and yeah, once you get direct access, you dont need any "middle pointers", like you are using right now, that was your point right?

im not sure, if i complely overjudge pythons possibilities in decoding machinecode, though. would be interesting to know if my idea, at all , were possible

[Ayuto]

What's the point of decoding the opcode bytes? ASM code and opcode bytes is basically the same thing.

To answer you concern: There are Python libraries! E.g. diStorm

[D3CEPTION]

the idea was to set identifier-algorythms(opcode decoding) for each server function that source python needs to use. these algorythms then @serverinit identifiy their respective functions through a python dissambler, that then takes the functions signature that boost python uses to create the correct c-object pointers?

not sure, if this is how it works, but the point is to automize the process

[Ayuto]

Not worth the effort, to be honest. And I'm not sure if that would even work very well.

Btw. a Python disassembler disassembles Python byte code. What you mean is probably an x86 disassembler. Moreover, Boost.Python has nothing to do with the search mechanisms for signatures. It's our memory module that does the stuff.