> modifications to this static, read-only .code section. Checking .data for > modifications? You'll have your work cut out for you.
vtables in my MSVC go in .rdata. Even if they were in .data, you could take the resulting PDBs and build verification inputs. -dvander On 4/12/10 7:25 PM, HL-SDK Synths wrote: > Hi, memory editing under certain circumstances is safe. > > Since you asked: http://en.wikipedia.org/wiki/Virtual_method_table > These are used as lookup tables of functions related to an entity or > interface of sorts. The client (client.dll) provides an interface that > contains a function that constructs a CUserCMD to send/sync to/with the > server. Either way, suppose I have the base of this table (mind you, this is > in the .data section while the program is running, not .code - I believe > that may be the point of VMTs but I am no CS major), and I have the offset > into the table of the function I want. It is not impossible to save the > pointer to the original function, and "detour" the call through my own code > (in a separate module loaded into the game process). > > Alternatively, if I were to get the spread calculation CODE and overwrite > that in memory with NOPs, that would get me banned rather quickly (I hope!). > The reason for this is that it shouldn't be hard for someone to check for > modifications to this static, read-only .code section. Checking .data for > modifications? You'll have your work cut out for you. > > Hooking VIA MS Detours (great for winAPI redirection and semi-legit uses): > DETECTED > VMT Hooks: UNDETECTED > > @Keeper - that is not the case, I have created (and there exist by others) > legitimate programs that inject into games and hook D3D functions (in order > to draw graphics in-game). > Xfire does this, steamoverlay.exe (sort of...) does this, FRAPS does this, > etc. > > On Mon, Apr 12, 2010 at 5:32 PM, Saul Rennison<[email protected]>wrote: > >> Well what does trigger VAC then. >> >> Thanks, >> - Saul. >> >> >> On 12 April 2010 22:09, w4rezz<[email protected]> wrote: >> >>> Modifying game memory will NOT trigger in VAC ban. Proof: >>> http://kartoffel-hack.com/ >>> >>> 2010/4/12 Saul Rennison<[email protected]>: >>>> Yes, the point is: modifying game memory (hooking functions, etc.) will >>>> still trigger VAC. >>>> >>>> Thanks, >>>> - Saul. >>>> >>>> >>>> On 12 April 2010 21:10, HL-SDK Synths<[email protected]> wrote: >>>> >>>>> I have the hotdogs, let's now find some sticks on which to roast them. >>>>> >>>>> Hi, I am the author of the post on G-D you linked to. I appreciate >> what >>> you >>>>> have worked for, I truly do. It is unfortunate that more methods are >> not >>>>> available to you (it seems that simple by-name querying is as far as >> it >>>>> goes). >>>>> >>>>> As for bans, I'd like to clarify that using the plugin interface is no >>> way >>>>> at all ban proof. If I decide to overwrite game code, I can expect a >>> ban. >>>>> If >>>>> this "proofen" status was the case, I would be acting like Hatter does >>> on >>>>> Assault Cube: >>>>> http://forum.gamedeception.net/threads/19310-Assault-cube-Bo00om >>>>> >>>>> Headshotting the wntire team all at once without moving. Enough >>> hyperbole. >>>>> >>>>> *My point: "VSP" IS EXACTLY LIKE LOADING VIA INJECTOR, IT IS NO SAFER. >>>>> *The only benefit is the interface which provides load and unload. I >> can >>> do >>>>> all of that with an extra plugin emulating the VSP interface. You have >>> done >>>>> a good job of blocking namestealers and people who abuse sourcemod, >> and >>> for >>>>> that I am sure many servers are more playable.* >>>>> * >>>>> I have no analogies. >>>>> >>>>> On Mon, Apr 12, 2010 at 3:49 PM, 1nsane<[email protected]> wrote: >>>>> >>>>>> Bad analogy?! Perfect analogy! >>>>>> >>>>>> On Mon, Apr 12, 2010 at 2:53 PM, ics<[email protected]> wrote: >>>>>> >>>>>>> If you say that to an alzheimer patient, you have to say it again, >>> and >>>>>>> again, and again and they each time you say that, they forget it >>> soon >>>>>>> after. Ok ok, bad analogy but they aren't really paying attention >> or >>> it >>>>>>> would be fixed already, along with all the other exploits in the >>>>> engine. >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> To unsubscribe, edit your list preferences, or view the list >> archives, >>>>>> please visit: >>>>>> http://list.valvesoftware.com/mailman/listinfo/hlds >>>>>> >>>>> _______________________________________________ >>>>> To unsubscribe, edit your list preferences, or view the list archives, >>>>> please visit: >>>>> http://list.valvesoftware.com/mailman/listinfo/hlds >>>>> >>>> _______________________________________________ >>>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>>> http://list.valvesoftware.com/mailman/listinfo/hlds >>>> >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> http://list.valvesoftware.com/mailman/listinfo/hlds >>> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlds >> > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
