I've met some problems with a similar cheat i wrote myself

[ciaoSora]

Hi, jpxue, are you still working on it? Recently I've written a widowmaker aimbot, but it just cannot work very well. In my aimbot, when I click the midButton, it will automatically locate an enemy. Here's some of my problems: 1) After I click the midButton, there's a delay of about 10 ms I think, before widowmaker shoots. I think it's because the process of capturing a screenshot is slow. But in your demo video, your bot works pretty well. 2) The red line around an enemy are not the only thing that is red, so my bot cannot always choose the right target. Can we get in contact? Thanks :D

[ciaoSora]

By the way, in my first question, I mentioned that maybe it's the process of capturing a screenshot that caused the delay. However, I've read your Capture.cpp and found that I use the same way to capture a screen. Now I think maybe it's my algorithm of finding an enemy is slow. I cannot quite understand the 'findPlayer' function in your screenshot.cpp, please help me. Thank you :D

[jpxue]

1. I cannot really guess what your problem is, I haven't touched this in years. Maybe you're not running on RELEASE but DEBUG mode (there A LOT of overhead in debug mode). I doubt that the problem is with screenshot capturing but you should try benchmarking to find if this is indeed true or not. A screenshot takes 31ms on my current machine (mid tier core i5) which is pretty fast seeing that it would allow you to perform 30+ operations per second. The findPlayer function takes only a few ms too. Maybe it's problem with mouse.cpp? Have you inputted the correct sensitivity and tried playing with the aimspeed global variables?

10ms is really negligible, the average human reaction time is ~200ms, I doubt that you'd notice 10ms :P.

For benchmarking in Release build you use timer.cpp i.e: Time t; t.timerStart(); //Code or Function() that you want to benchmark cout << "Benchmark: " << t.timerStop();

This should give you some information if you require it.

2. Yes, that's true. I developed this in the training room were the only red pixels were target borders. In other maps it's probably better to just scan for the health bar (255,0,19) and just offset a certain amount of pixels from the origin of the health bar. If I had tested this out in actual MP maps I would have implemented it like I just outlined here but I never really cared about trying this against players.

---

If I recall correctly findPlayer() works like this:

1. Find a health bar (255,0,19)
2. Scan underneath the health bar looking for red pixels. There are conditions to stop searching if the complete player model seems to have been fully scanned (for example: player model may just be 80x100 pixels, bot would scan 100x150 pixels and would stop searching and move onto the next task instead of needlessly scanning the whole 1920x1080 screenshot - I'm inventing numbers out of my ass just to demonstrate the point but most of the weird conditions are there to save time for precisely this point)
3. Calculate players center (add all the coords together and calculate the average) or headshot (make use of the average in the X plane and one of the top Y coords).

[ciaoSora]

Thank you so much for such long reply :D. I will try to find out what's wrong with my program. But I am a little confused: 1) Your program first search for the health bar and then search for a player model. What if he is an enemy whom you haven't dealt damage to? In the game, health bar will appear only when you deal damage to an enemy. What makes me more confused is that in your demo video, the training bot is unhurt, but your aimbot can still work. 2) A screenshot takes 31 ms, which means it takes at least 31 ms to analyze a screenshot. Then your FPS must be 1000 / 31, that is about 33. That is so low. But in your demo video, it seems that the FPS is much more than 33.

Thank you again for your timely reply! I really appreciated it. :D

[jpxue]

1. It's not unhurt, the aimbot only kicks in when the health bar is showing 100%. The video is just me making the first shot for the health bar to show and then letting the bot do it's work and I demonstrate the difference between two different aim speeds.

2. Idk what you're basing this on, but 33 actions PER SECOND is pretty good. Again this is not a memory aimbot so if you're going to base your opinion by comparing it to memory based models then that's not even fair. An external color aimbot will never be as good as a memory. In the video that I was showing the action per second was closer to 15-20 actions per second, being able to find an aim at a target 15x per second is much better than any human possible.

From experience I can also assure you that increasing the actions per second isn't helpful past a certain point because it is simply unnoticeable/too much (not to mention that it introduces new issues). I have implemented a version which hooks Present() to get a screenshot in ~3ms (1ms to intercept and get the screenshot buffer location and 2ms to memcpy it into a memory map for inter process communication) and the difference isn't noticeable. This method does however bypass OW's screenshot lock but again capturing in GDI is still good enough.

[ciaoSora]

Thanks a lot! Your source code and your replies really help me a lot. Thank you.

[ciaoSora]

Sorry to bother you again, but I've met a new problem. Somehow, what I am doing these days is detected by Blizd, and now I'm not allowed to get screenshot using GDI. You said that you have implemented a version which hooks Present() to get a screenshot and this method can bypass OW's screenshot lock. Could you please be more detailed? Is it about DirectX? Thank you. :D

[jpxue]

If you're not familiar with injection, hooking and direct3d then I don't know how I can explain it to you sufficiently: Hooking is basically a form of function interception, in the case of dxgi games a screenshot is displayed when a function called Present() is called, for older direct3d versions EndScene() is used; thus we need to intercept Present().

1. You need to get the address of Present(), to do this you can make use of what is called a virtual table - a table containing the addresses to various functions. You can look up VTable for dxgi online (people post these all around forums), all you need to know is that Present() is the 8th function, thus you need to get that address at position 8. From that address subtract the address of the dxgimodule and you'll obtain the offset. EDIT: I DO ALL THIS IN A DUMMY WINDOW (create a new window and init dxgi in it and read the vtable)
2. Inject a .DLL into overwatch, obtain overwatch's dxgimodule address and to that add the offset which we found previously and you'll get the memory address of Present() for overwatch.
3. You now have the address pointing to Present(), so you can now intercept it. To do this you need to learn about hooking - I do this using byte patching (most common way to hook but there are other ways such as VTable Hooks).
4. Once you install your hook and the function is intercepted you can get the screenshot directly from: D3D11_MAPPED_SUBRESOURCE.pData (a void pointer to the screenshot buffer - there are 4 bytes [argb] in each pixel screen width screen height - so you should memcpy all that). You need to get the backbuffer pointer on the swap chain and you can use CopyResource followed by Map to create the D3D11_MAPPED_SUBRESOURCE which I mentioned earlier.

I would recommend reading about: injection, hooking and basics of Direct3D; my explanation barely covers everything that you need to do and I left out a lot of detail which would have been pointless anyway. Good luck

[ciaoSora]

Oh, thank you so much! Actually, I'm pretty new to windows programming, and I have only learnt a little about DirectX before. It seems that I have a lot of things to learn. Thank you, really.