Source.Python forums

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

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

On linux running, on windows give error.

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

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

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

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..

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.

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

D3CEPTION wrote: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.
So, this is easily possible without any changes! We just need to use different signatures.

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

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

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

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.