After today's update CS: GO SP (Revision as of April 20, 2016) gives this error:
SP does not work CS:GO
Re: SP does not work CS:GO
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
Re: SP does not work CS:GO
On linux running, on windows give error.
Re: SP does not work CS:GO
Yes, a signature must have changed from the update. We will get that fixed when one of us has time.
Re: SP does not work CS:GO
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
Re: SP does not work CS:GO
No, Linux uses symbols, not signatures. Symbols don't typically change, ever, whereas signatures very easily can.
Re: SP does not work CS:GO
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..
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..
Re: SP does not work CS:GO
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.
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.
Re: SP does not work CS:GO
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
although when i made the post i forgot that these major updates, dont usually happen
Re: SP does not work CS:GO
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.
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.
Re: SP does not work CS:GO
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
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
Re: SP does not work CS:GO
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
To answer you concern: There are Python libraries! E.g. diStorm
Re: SP does not work CS:GO
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 sure, if this is how it works, but the point is to automize the process
Re: SP does not work CS:GO
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.
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.
Return to “General Discussion”
Who is online
Users browsing this forum: No registered users and 17 guests