How is that remotely related to what I just said?
i replied to the wrong thing smh
okay. this is a great bypass. rip juice wrld
i like kai cenat and ishowspeed
Make me mad an i will probably have to fanum tax you.
This post is insanewy innapropwiate pwease refwain fwom making deez posts or I may have to repwort you to higher authworities
I donât know how to quote the getnamecallmethod() line in this message but this is inaccurate information because it will just change the __index metamethodâs 2nd argument, namecall does not utilize null-bytes
Yes right I forgot to edit this out
Well you clearly donât understand how metamethods works, that fakenamecall function will always return the same function regardless if you add \0 at the end or not, youâre not magically getting some other function so game.GetFullName and game[âGetFullName\0â] would be exactly the same as they return the same function. So this is really pointless as it serves no protection against exploiters
SafeCFakeNamecall = function(self, Method, ...) --> Does not invoke __namecall, but will invoke __index instead.
return self[ProtectMethodString(Method)](self, ...)
end
before namecall is called internally setnamecallmethod() is called, after that it calls namecall so whatever method is set before will be used. You cannot obtain that function and spoof your own namecall methods from a non exploit environment.
Interesting, so how do you stop exploiters? I know about metamethods, and I know that you can negate some exploiters with certain methods like renaming serverscriptservice etc. But you might have a solution? Because if your posting to tell someone is wrong, I donât mind that, but where is the solution ? Because us arguing about exploiter protection and working together to solve the problem is two different things.
I am just stating that namecall one is pointless, sure other methods like SafeCNewIndex, SafeCIndex youâve posted here are effective and help in combating cheaters while the namecall one may just mislead other users researching this kind of topic
So no constructive feed back to help the problem? Got it⌠I see so many people fight about exploiters and how to âStopâ them but no one ever post a solution lol.
I wonder if you even read what I have wrote before, there are no similar solutions for namecall as there are for index and newindex.
As for constructive feedback Iâve already explained on how that is misleading certain people on this forum who want to research this topic as that method regarding namecall serves no protection not to mention your misleading explanation on how it works because thats not how it works, and it doesnât even call namecall in the first place.
Because
getnamecallmethod()
will instead return something along the lines ofGetChildren\000\000\0004154565.1561216
(\000 being null bytes, which are string terminators in C++, meaning the rest will be ignored) which is NOT equal toGetChildren
.
And you should really tone down your ego.
I have zero ego, because I know that there is always someone out there that is way better at scripting vs exploiters than me. The point of this place is to learn and have teamwork, I donât really see anything like that in your post. When I go to my boss with a problem I normally get asked the same question, âWhere is the solution.â I donât think you get that concept yet so I will let it go at that. Thank you for your post in attempts to belittle the OP. But I donât anyone is learning anything from you.
It does work for when exploiters use __namecall
hooks, as it wonât even trigger Namecall, hence why âFakeNamecallâ. One could use hookfunction
which can be detected with coroutine.wrap
as stated above in my post. Why are you being so negative?
Sure but yet again this has nothing to do with namecall and is just spreading misinformation
Because
getnamecallmethod()
will instead return something along the lines ofGetChildren\000\000\0004154565.1561216
(\000 being null bytes, which are string terminators in C++, meaning the rest will be ignored) which is NOT equal toGetChildren
.
Yes it does have something to do with __namecall
, as itâs goal is to completely not invoke it.
and then its an awful practice, for one namecall hooks are expensive, individual functions are much cheaper to hook, so youâre doing exploiter a favour in terms of optimization. Its better to use namecall than to get barely any security out of this method
So is it true that exploiting is quickly dying? Not sure about that statement but I just came back from a multiple year hiatus
itâs slowly returning due to a dedicated team of devs and the fact Hyperion seems to have ran out of detections
Why is this thread still ongoing anyway? These client-sided anti-cheats can be pretty performance expensive, and will still get bypassed sooner or later. All it takes is for someone to bypass it, post the source code online on a website or a platform where skids regularly visit, and your game is doomed.
That could work if you have no sense of security whatsoever. If thereâs a way to bypass, thereâs a way to detect.