Description:
Warden implemented but not used for reasons we expect.
Current behaviour:
I can see multiple opened issues with the same subject that were actually dodged by the TrinityCore developers. TrinityCore is open-source project, and I really thank you guys for the work done. Still in this feeling of open-source where people are co-helping/working, I'm trying to create this issue hoping someone might understand the need and try to fix it.
Nowadays (on 3.3.5 servers at least), most of the players are using PQR/Gagarin softwares that injects the wow client to access or unlock protected LUA API.
These injectors are not UPDATED since a while (about more than 5+ years at least) so it could be easly decompiled I guess, and be understood like TrinityCore did for developing this educational game-server.
It's obviously related to TrinityCore since warden is existing for that kind of cheats.
Expected behaviour:
I would like you guys trying to commit a fix for PQR which is actually used by every random players.
This software is destroying the game.
Nowadays, it's impossible to find any tutorial about warden. Of course, github issues are not a forum, but exists for improve TrinityCore and players experiences. PQR is like a game leak which must be fixed.
Steps to reproduce the problem:
/
Branch(es):
3.3.5
All Systems
This issue is not considered valid because of the following reasons:
Please read http://bit.ly/tc-issuetracker-and-you and add the missing information to this issue. Thanks.
@lilirara Keep in mind, this is a educational development and not meant for public servers. For something small as signatures for Warden are not hard too update by yourself.
Here's some examples that I have:
(810, 243, '', '', 7728616, 2, '7503', 'Gagarin Fly 1'),
(811, 243, '', '', 9993834, 2, '7452', 'Gagarin Fly 2'),
(812, 243, '', '', 7248789, 6, '8DB0F4010000', 'Gagarin Warden Disabler'),
(813, 243, '', '', 7277083, 6, '0F8691000000', 'Gagarin Speed'),
(814, 243, '', '', 9995134, 2, '755C', 'Gagarin Fix Fly'),
(815, 243, '', '', 7714472, 2, '7506', 'Gagarin Wall Climb'),
(816, 243, '', '', 5419615, 6, '0F8CEDFDFFFF', 'Gagarin AntiAFK'),
(817, 243, '', '', 5284957, 6, '0F8472FFFFFF', 'Gagarin Rosetta Stone'),
(818, 243, '', '', 8767818, 6, '890D9C13D400', 'Gagarin Unlock LUA'),
(819, 243, '', '', 6355605, 2, '7F1D', 'Gagarin Show Levels'),
I appreciate your help, but it would be appreciable to understand how u came to these addresses. Is it working the same for PQR?
@lilirara This is a guide with ac-web.org:
https://www.dropbox.com/s/alupoclwus0fr9o/Warden%20Memory%20Checks.rtf?dl=0
In fact, Warden does not provide complete protection from some cheats, for example: Hitchhickers's Hack or WoW Admin Panel. To get rid of this, you need to add checks on the acceptance of client flags by the server, rewrite the system of movements and much more. In one of the discussions, Aokromes made it clear to me that no one would do it, as it is easier for him to think about the cheaters on the official server than to face the truth or at least go deeper into the client part, where there are hints of the presence of these checks server and implement them in TrinityCore.
@lilirara This is a guide with ac-web.org:
https://www.dropbox.com/s/alupoclwus0fr9o/Warden%20Memory%20Checks.rtf?dl=0
In fact, Warden does not provide complete protection from some cheats, for example: Hitchhickers's Hack or WoW Admin Panel. To get rid of this, you need to add checks on the acceptance of client flags by the server, rewrite the system of movements and much more. In one of the discussions, Aokromes made it clear to me that no one would do it, as it is easier for him to think about the cheaters on the official server than to face the truth or at least go deeper into the client part, where there are hints of the presence of these checks server and implement them in TrinityCore.
Thanks for you quick answer. But I guess PQR is not doing memory writes we can actually catch, since it's not exactly unlocking LUA. It adds a LUA_STR somewhere and this lua is ran unto a protected context.
Maybe could you provide me some use cases of LUA_STR option of warden?
@lilirara A friend of mine works on Warden for a few projects and he's pretty good at getting signatures for warden. These do work for the current warden system in TrinityCore, but the detection of them is not that great. The greatest issue this these signatures, is very high false positives. If I have the time too do so, I can try to port over my anti-cheat system for TrinityCore from my own project. Its a bit more developed then TC's right now.
@Krilliac
@Meltie2013 Example:
Client send to the server a packet with modified time 1970.03.12 21:52 and with the flag MOVEMENTFLAG_ON_TRANSPORT.
Official server: reject package.
TrinityCore: accept package.
Of course, I am not an expert, but it seems that it鈥檚 not necessary to write anti-cheat here and the problem is completely different.
As I said I suppose LUA_STR_CHECK must be used for PQR.. Would appreciate anyone giving informations about this
@lilirara I already gave you a link to the guide for which you can detect PQR. What does it specifically use, ask its developers.
https://community.trinitycore.org/topic/14569-ant-pqr-script/
Interesting read here, seems few servers have gotten around and are sending simple LUA script to be run clientside checking if protected lua is available.
However i couldn't reproduce this since i clearly don't have any clue of how the client handles the receiving Warden module functions.
Addresses are correct but it's not just executing it or it has exceptions handled silently.
@lilirara LUA_STR_CHECK Just doesn't work the client always returns 1 regardless whether the lua string is used or not.
Obviously someone is able to execute LUA from serverside as there are private servers running LUA to check for bots like PQR. But as far as I can tell the public information is not enough to replicate this. Even Vipher's information isn't enough alone to do this.
Did you ever figure this out @hamarz ?
@HelloKitty Did you?
@lineagedr Well, I tried it. Client doesn't seem to execute the LUA sent in the warden packet. Maybe clientside LUA needs to be unlocked? Does PQR allow for running protected LUA? Hmmmm, not sure but didn't seem to run any LUA on a regular 3.3.5 client.
I don't know if this can be helpful
https://github.com/Kittnz/AdvancedWarden
With the above PR I did, you can adjust the function address to be 0x00419210 and it will also allow for you to execute lua from your warden module
4125a81bb132c8d108f5bb07787f00a9fadf5838
i do not think 4125a81 fixes all issues outlined here, re-opening
@Treeston what exactly are all the issues? I'm not trying to have it closed right away but from what I read that was requested:
Expected behaviour:
I would like you guys trying to commit a fix for PQR which is actually used by every random players.
This software is destroying the game.
Nowadays, it's impossible to find any tutorial about warden. Of course, github issues are not a forum, but exists for improve TrinityCore and players experiences. PQR is like a game leak which must be fixed.
Now, with a program like PQR it doesn't perform memory writes on standard .text locations for you to add a scan for. To find the sections that are written to be found you'd need a hash to scan for (but they're also freed quickly) additionally PQR randomizes the ASM that it injects (also defeats the purpose of making a hash as the randomization would produce a different hash). This now leaves you with the using warden in the way it wasn't intended by making the second function portion to be for FrameScript__Execute. When I look above at other mentioned issues you have the memory addresses to scan for the other mentioned application Gargain. Could you please elaborate exactly what all the issues outlined are that still need addressing (within the scope of what warden is capable of doing)?
You can still detect some versions of PQR by querying PQR frames with GetText method, for other versions, even ::Execute won't help you much.
ie. search for PQR_EventFrame with standard LUA_STR check.
edit: There are versions out there that randomizes frames, some versions do not create frames at all.
If you really want to get rid of PQR, warden is not the way to go
@scizzydo I'm not a warden dev - we do not currently have a true warden dev on the project; the existing warden functionality is _very_ old.
However, it does not appear to me that 4125a81 is a functional change given the current TDB base (which, to the best of my knowledge, does not contain any Lua string checks).
The original issue was about specific anti-cheat tools, and the possibility of detecting them in TC.
If Warden is not the tool for that (possible, again, I am not a warden dev), then potentially the issue would need to be renamed - but it is still a valid issue.
tl;dr I see no reason to shut down discussion as long as there quite apparently are still things to discuss.
@Treeston to maintain the scope of what I assumed this project is I don't believe the answer is warden and it's creating something new that is outside the scope of what 3.3.5 servers had at that time. For the program PQR there is no LUA_STR_CHECK that you would do that would even check for PQR as none of it's variables are string variables. I can do a quick mock up server config to show you what I have done in my server to detect PQR but it is modifying the GetText to execute and also modifying the chat handler portion to deal with the SendAddonMessage for when it finds the PQR in the lookup.
If you're interested, here's a paste of what PQR actually sends to the client: https://pastebin.com/HfFjWm9U
Like @Riztazz said also, there are versions of PQR that randomize (which if you look up the creator/modifier for that, it's actually me). For versions like that, the reason why I did what I did was to make it undetected to further levels.
To accomplish what is asked for specifically for PQR isn't going to be possible from what I believe. I've spent much time working with Warden and have many use cases where I can bypass it for it to not find anything all together.
I am not entirely sure what LUA_STR_CHECK
's capabilities even are. Does it actually just check tostring(_G[key])
value against a check value? Does it send back the value tested for? Does it execute arbitrary code in the sandbox?
It's more low level than that as the check isn't being performed in lua, however that's the correct interpretation. If the check is for example a function, it returns nothing as a function isn't a string. Now let's say you do the GetText check for the variable CHAT_MSG_PARTY you would get the result "party" because that variable when loading WoW is assigned "party"
All the LUA_STR_CHECK is capable of doing is getting the result from a variable. The reason why you can pass the function address for Execute is they share a similar calling convention where the first argument passed is the check. That's why you can then execute lua
So it never goes into the sandbox, but retrieves the global in C and only returns a result for string type? So you can't even check if a should-be-nil injected function gives you "nil" (and fail if it does not)?
Maybe this will be a better example for you since you can see it:
https://imgur.com/a/6O6Ujft
GetText can return any variable that is assigned something like a number or a string, you can't return a function (CastSpellByName in the example), you can't return a comparison as GetText doesn't execute the lua, you can only get what's been assigned. Internally the function is just calling lua_getglobal(state, name)
Again, this function has almost the same calling convention as Execute, so if you just change the address you can execute the lua you want right there, but you don't have a way to get the result from it. In most hacks/programs they would use those 2 functions together. The first would be the Execute with something like:
'test = PQR_EventFrame ~= nil and "true" or "false"'
and then with GetText you check "test" which would return "true" or "false"
PQR will now be detected by base TrinityCore. (0531463)
Most helpful comment
PQR will now be detected by base TrinityCore. (0531463)