-
12/1/2016 bans...
Hi Everyone,
So it seams like quite a few people from lots of bots and tool were hit yesterday with a PermaBan. Does anyone have any ideas what caused this yet?
EDIT: I do use ExecuteBuffer and my trial account was banned
Last edited by -Ryuk-; 01-13-2016 at 02:50 PM.
|Leacher:11/2009|Donor:02/2010|Established Member:09/2010|Contributor:09/2010|Elite:08/2013|
-
Post Thanks / Like - 1 Thanks
hackerlol (1 members gave Thanks to -Ryuk- for this useful post)
-
Contributor
General idea is that LUA was the culprit, Would be nice to see how many people were just simply calling FrameScript_execute and maybe have been caught by the stack checking function. I am not banned but I also do not use ExecuteBuffer for anything.
-
Post Thanks / Like - 1 Thanks
hackerlol (1 members gave Thanks to aeo for this useful post)
-
12/1/2016 bans...
Also not banned; not hooking any functions or calling executebuffer. Lua is fully unlocked so it's not a detection of unlocked Lua, like you said almost certainly it's the hook function mentioned in the other thread.
There's another component to this - I'd be interested to know if anyone who has exclusively used x64 client was banned (that means you have not used the x86 client in many months)
-
Post Thanks / Like - 1 Thanks
hackerlol (1 members gave Thanks to Filint for this useful post)
-
Originally Posted by
Filint
Also not banned; not hooking any functions or calling executebuffer. Lua is fully unlocked so it's not a detection of unlocked Lua, like you said almost certainly it's the hook function mentioned in the other thread.
There's another component to this - I'd be interested to know if anyone who has exclusively used x64 client was banned (that means you have not used the x86 client in many months)
I also believe it to be the hooked function they have used for some time, it was off for a while and then after this mini patch it was back and now banned.
|Leacher:11/2009|Donor:02/2010|Established Member:09/2010|Contributor:09/2010|Elite:08/2013|
-
Not to derail this thread, but I'm curious why people use FrameScript::Execute et al? What do you use it for? I don't think I've ever had cause to use it...
-
Originally Posted by
namreeb
Not to derail this thread, but I'm curious why people use FrameScript::Execute et al? What do you use it for? I don't think I've ever had cause to use it...
Calling Lua
|Leacher:11/2009|Donor:02/2010|Established Member:09/2010|Contributor:09/2010|Elite:08/2013|
-
Elite User
Originally Posted by
namreeb
Not to derail this thread, but I'm curious why people use FrameScript::Execute et al? What do you use it for? I don't think I've ever had cause to use it...
It is a convenience wrapper around lua_load and lua_pcall. The bot detection stuff that I've heard about was in luaD_protectedparser which is called by something inside lua_load/lua_pcall. If it was this detection then neither FrameScript_Execute nor lua_pcall would have been safe to use.
Another thing worth noting is if you've been calling lua functions from a place you're not supposed to. Like inside EndScene/Present. If you want to be on the "safe" side you could append your lua code to existing calls that are made from the game every frame via binary introspection or a debugger.
Last edited by Master674; 01-13-2016 at 05:18 PM.
-
Post Thanks / Like - 1 Thanks
hackerlol (1 members gave Thanks to Master674 for this useful post)
-
Could just check for any code modifications or vtable hooks Would be a performance hit but still. I dont think they are going to be patching any code so checking the integrity of 200+ vtables would be easy. Could code a simple tracer and record all vtable calls. But then each lua function call would have different vtabled. So I guess its not the best. Unless they have code inside the lua function, then they dont need to hook at all. Also whats up with the PermaBan, I have only see 6 months. Was that b/c you are on a trial account?
Last edited by DarkLinux; 01-13-2016 at 05:36 PM.
-
Originally Posted by
Master674
It is a convenience wrapper around lua_load and lua_pcall. The bot detection stuff that I've heard about was in luaD_protectedparser which is called by something inside lua_load/lua_pcall. If it was this detection then neither FrameScript_Execute nor lua_pcall would have been safe to use.
Another thing worth noting is if you've been calling lua functions from a place you're not supposed to. Like inside EndScene/Present. If you want to be on the "safe" side you could append your lua code to existing calls that are made from the game every frame via binary introspection or a debugger.
For the last few weeks ive been using a hook that I think was your idea and then Jadd wrote a blog about. WndProc
@DarkLinux, Everyone I have spoken to has perm also, one for example used EWT only for anti-afk and was hit... but that used ExecuteBuffer to show a welcome message and other things
Last edited by -Ryuk-; 01-13-2016 at 05:37 PM.
|Leacher:11/2009|Donor:02/2010|Established Member:09/2010|Contributor:09/2010|Elite:08/2013|
-
Banned
I was not banned, I use this old method on live, with new offsets ofc https://github.com/winifix/FishBot-3...5a/Hook/Lua.cs
Mainly use DoString
-
Based off this, https://github.com/winifix/FishBot-3...a/Hook/Hook.cs its hooking endScene so it should be detected but at the same time I'm seeing FishBot-3.3.5a so I dont even know how its working.
-
Banned
I won't post my live source, but the do-string is identical, and i did say "with new offsets"
I can't say why I am not banned, I use dostring alot to cast spells in my rotation system, maybe the hook is done differently to yours, and I do some encryption on it (like HBRelog used to do)
-
Do-string is not the problem, its where you call it from. I'm lost, you just linked that source saying your not banned for using it then you say its different? And define "encryption". And based off what I remember of HBRelog, it did not hook anything ingame.
-
The function that receives the JMP patch on login is lua_load. Some of the stack trace:
Code:
Win 32-bit Build 6.2.3.20886
0x273EE FrameScript_Execute
0x271C5 FrameScript_ExecuteBuffer
0xB6DAC luaL_loadbuffer
0xB63A1 lua_load -> JMP is inserted here on login
0xBC75F luaD_protectedparser
In order to run LUA avoiding this JMP and without patching it with a regular prologue, you might consider implementing your own luaL_loadbuffer and lua_load by calling luaZ_init and luaD_protectedparser. FrameScript_ExecuteBuffer is called with the last 3 arguments == 0, which simplifies an equivalent implementation:
Code:
signed int __cdecl Another_FrameScript_ExecuteBuffer(int a1, unsigned int a2, int a3)
{
int v6; // edi@1
signed int result; // eax@6
v6 = s_context;
lua_rawgeti(s_context, 0xFFFFD8F0, s_errorHandlerRef);
if ( luaL_loadbuffer(v6, a1, a2, a3) )
{
if ( lua_pcall(v6, 1, 0, 0) )
lua_settop(v6, -2);
result = 0;
}
else
{
if ( lua_pcall(v6, 0, 0, -2) )
{
lua_settop(v6, -3);
result = 0;
}
else
{
lua_settop(v6, -2);
result = 1;
}
}
return result;
}
Or you could patch the JMP in lua_load and hope that it doesn't get scanned by Warden, which isn't currently scanning it.
Keep in mind that if you don't patch it, FrameScript_ExecuteBuffer can get called by FrameScript_ExecuteFile, which is called when you first open certain UI frames, such as the Mounts tab, Achievements, etc. If you hook FrameScript_SignalEvent or some other function, your hook will be in the stack and could be detected by the lua_load JMP.
In any case, I'm not confident that the detection came from this.
-
Member
All i used a few weeks ago was a fishbot, (3 weeks ago aproximately) and 2-3 days ago i used Tmorph. I don't know why they would make a "delayed" permanent ban? Or if Tmorph is what caused this ban for me?