Crazy question about execute non-protected lua.

[Tambel]

Hello. As i know ingame lua not allow IO operations.
So if we need to call some helpfull non-protected functions we can:
1) call it directly by injection or CreateRemoteThread.
2) Reverse it and find related offsets.

What about something like that?:

We declare some variables in addon script with values that help us to find them through memory scan.

task=87654321.12345
result  =87654321.12346

Then we change the "task" variable on needed command value, and read result from second variable.

function onupdate(self)
    if task==1 then
        result=GetQuestLogLeaderBoard(1) --for example
    end
end

Is this no matter for warden which memory in modified?
I know that any modification or call it is non-out-of-process, but how much risky to change some variables in custom addon, and how much this idea stupid at all? =)
Thank You.

[Jadd]

It's possible, but I can't see the difference between reading memory from where these Lua variables reside as opposed to reading information about quests, etc. directly.

Another option would be to transfer information via. images and pixel reading - Lua addon gathers information, displays the info as a bitmap on the screen (RGB = you can fit 3 bytes of information into 1 pixel), then the bot reads pixel colours at that position. This totally saves you from even opening a handle to the WoW process. You could even fit ~30KB of info into a 100x100px bitmap.

But obviously this is all totally unnecessary, Warden in it's current state does not justify these lengths to hide your bot/tool. Sounds like a fun idea though.

Edit: Didn't read your post properly, mine does not cover writing memory/information to the client. In my scenario the Lua addon would be in charge of choosing the information which is displayed.

[Tambel]

It's possible, but I can't see the difference between reading memory from where these Lua variables reside as opposed to reading information about quests, etc. directly.

It can save us from search of many offsets and debugging isn't it? If we for some reason do not want call this functions "in-process".

About pixel reading, I think its great! And You right, it is not necessary to write memory to control the addon, better put all needed lua functions in loop.

[ioctl]

I've been using a scheme like you describe for a while. I serialize useful info into a string, stick it in a global variable, and parse it from my bot. Going the other way, I create a giant string in lua, and then clobber the contents with serialized messages from my bot.

I also did pixel reading for a while -- it's a little trickier than it sounds because the modding api doesn't give you a lot of control over graphics. I ended up making a 1x1 font, and using the text markup language to colorize the "text". It's significantly slower than extracting data from LUA variables, and building the text causes a lot of GC thrash.

[Tambel]

I also did pixel reading for a while -- it's a little trickier than it sounds because the modding api doesn't give you a lot of control over graphics. I ended up making a 1x1 font, and using the text markup language to colorize the "text". It's significantly slower than extracting data from LUA variables, and building the text causes a lot of GC thrash.

So we cant change single pixel color directly?

[verysimplenick]

we can create frames and change color of frame.

[Torpedoes]

Another option would be to transfer information via. images and pixel reading - Lua addon gathers information, displays the info as a bitmap on the screen (RGB = you can fit 3 bytes of information into 1 pixel), then the bot reads pixel colours at that position. This totally saves you from even opening a handle to the WoW process. You could even fit ~30KB of info into a 100x100px bitmap.

Ha ha, I wrote a research paper on that very topic during my last year of university It was largely successful but you'll run into issues with string encoding and performance. You're also quite limited to what you can extract, so ensure what you want to extract is actually accessible and can be encoded in an image. But honestly, it's way easier to just read memory directly...

[lolp1]

Is properly coded pixel analysis on a tiny image really going to be much more of a performance cost than using ReadProcessMemory? RPM is extremely slow.

[-Ryuk-]

Is properly coded pixel analysis on a tiny image really going to be much more of a performance cost than using ReadProcessMemory? RPM is extremely slow.

Which is why you go fully injected and read directly

Injected or fully OOP, you face the same risks(or will do shortly) so there is no reason not to be injected anymore.

[Torpedoes]

Is properly coded pixel analysis on a tiny image really going to be much more of a performance cost than using ReadProcessMemory? RPM is extremely slow.

Using the standard BitBlt method is actually pretty slow, and less flexible. I'm also not entirely sure how safe it is, in theory Blizz could detect the addon displaying the pixels and axe at.

Injected or fully OOP, you face the same risks(or will do shortly) so there is no reason not to be injected anymore.

Could you please elaborate on the "same risks" statement, is there some new information regarding detection that I'm unaware of?

Also, despite what people are saying you can get really good RPM speeds with caching. The problem comes from performing too many RPM's, so just reduce the total number of RPM's you do and you can get comparable speeds to injected apps. You can also split the task across multiple cores of the CPU for an even bigger boost. This technique can be seen in Sonar, an OOP application. Even in dense regions, I'm still able to achieve real-time performance.

[lolp1]

Using the standard BitBlt method is actually pretty slow, and less flexible. I'm also not entirely sure how safe it is, in theory Blizz could detect the addon displaying the pixels and axe at.

There are many ways to analyze pixels at much faster speeds.

Could you please elaborate on the "same risks" statement, is there some new information regarding detection that I'm unaware of?

As far as I can tell injecting a manual mapped module into a process and only accessing direct memory locations from the module has never been any more dangerous or less safe than an external process calling ReadProcessMemory on a process.

despite what people are saying you can get really good RPM speeds with caching. The problem comes from performing too many RPM's, so just reduce the total number of RPM's you do and you can get comparable speeds to injected apps.

I really hope no one looking into programming reads that and believes it and goes on to skip learning C++/related stuff. It's a critical stepping stone to hacking games if you ask me, even if you end up set on external in the end. You simply can not even come with in the realm of the speed of an injected module accessing memory directly with calling ReadProcessMemory. Even with all the caching and parallel multi thread operations in the world you will be massively behind in speed of direct memory access. I honestly would not be shocked if in some cases it is 500-1000x+ faster.

[-Ryuk-]

Using the standard BitBlt method is actually pretty slow, and less flexible. I'm also not entirely sure how safe it is, in theory Blizz could detect the addon displaying the pixels and axe at.



Could you please elaborate on the "same risks" statement, is there some new information regarding detection that I'm unaware of?

Also, despite what people are saying you can get really good RPM speeds with caching. The problem comes from performing too many RPM's, so just reduce the total number of RPM's you do and you can get comparable speeds to injected apps. You can also split the task across multiple cores of the CPU for an even bigger boost. This technique can be seen in Sonar, an OOP application. Even in dense regions, I'm still able to achieve real-time performance.

You can easily bypass the warden scans(all types) by being injected. It wont be long until warden is updated to get the same scans that Hearthstone & D3 now have.
Yes its true that they could (and have in the past) add functionality to the client to detect you, however they could also do this for your OOP products as well.

I seriously don't see the point of being OOP anymore, when its so much easier to manipulate wow from an injected product.

There are many ways to analyze pixels at much faster speeds.


As far as I can tell injecting a manual mapped module into a process and only accessing direct memory locations from the module has never been any more dangerous or less safe than an external process calling ReadProcessMemory on a process.


I really hope no one looking into programming reads that and believes it and goes on to skip learning C++/related stuff. It's a critical stepping stone to hacking games if you ask me, even if you end up set on external in the end. You simply can not even come with in the realm of the speed of an injected module accessing memory directly with calling ReadProcessMemory. Even with all the caching and parallel multi thread operations in the world you will be massively behind in speed of direct memory access. I honestly would not be shocked if in some cases it is 500-1000x+ faster.

Although you are correct that RPM is slow, however Torpedoes is correct. If you choose to stay OOP you can get some very nice speed improvements which would make it equal to what most people do. However you take that method of splitting the work across the entire CPU and make it work with direct reading and writing RPM will lose every time

[lolp1]

I agree Ryuk but there is a distinct difference between jumping through hoops to get into an acceptable speed range using RPM, and RPM being "close to injected speeds".

You might be able to bring it to speeds that are acceptable with work, but it will still be 100's of times slower at best than direct memory access. There is no need to split the work of reading direct memory across several cpus. It's ridiculously fast.

[Torpedoes]

It wont be long until warden is updated to get the same scans that Hearthstone & D3 now have.

Even with all this new detection coming out, I'd argue OOP is still safer in the long run. I say that for two reasons, the first is I suspect Windows containers (whenever they come out) will provide the isolation we need to prevent Blizzard from scanning external processes. The second is running your code through some sort of interpreter (e.g. Java, Autoit, etc.) which will make it more difficult for Blizzard to detect without more advanced analysis, which you could easily block.

I seriously don't see the point of being OOP anymore, when its so much easier to manipulate wow from an injected product.

Injected is not that easy, and arguably less flexible, unless you're doing some sort of combo method of injected + OOP.

You might be able to bring it to speeds that are acceptable with work, but it will still be 100's of times slower at best than direct memory access. There is no need to split the work of reading direct memory across several cpus. It's ridiculously fast.

Sure it's slower but in practice it's comparable. I'm not sure what you're doing that you require such blazing speeds. Even if the bot takes 100ms to read the game, that's still not bad because you're usually 300ms behind when you play the game anyways. It won't make your bot perform any worse is all I'm saying.

[lolp1]

Injected is not that easy, and arguably less flexible, unless you're doing some sort of combo method of injected + OOP.

It's easier if you ask me. No worries about speeds, and you are working directly with the source you want to access. In which way is it less flexible?

Sure it's slower but in practice it's comparable.

I agree all the way. RPM can be made to acceptable levels. There are cases where it is an issue though. What if you want to make a hyper responsive "chicken" based on a large set of dynamic conditions, and since it is a chicken caching the values will not be any good. In this case, the only solution is to actually read the current data on each game tick. If you have 10 ms, you can imagine how easily that could become a mess.

If the above case used direct memory access and not RPM, you could easily do that with no effort.