I didn't forget, just real life work had me swamped. Alright, will give it an install and check if the table works as is or needs updating. Will return with feedback. The table could be available on my Ko-Fi page as a single download. Their membership/monthly subscriptions model doesn't work well, has a lot of issues, so I can't add benefits like table updates for X game updates etc.
EDIT: One aspect you most certainly won't like is the fact that the table will have to be updated regularly. Blizzard is using
Arxan to mutate code, which basically makes any protected executable different in looks (not in how it works) than the previous one. So with each game update, the ASM layout changes, which means any signature I scan for changes as well. Which means new table update and so on. If you check the StarCraft 2 or similar topics on this forum, you'll see how many times the user had to update his table because of this. So.. if you're happy with paying 10EUR for a table that will work with current version and -maybe- 1-2 updates, then let me know. If otherwise, I'd like to know before starting to update my stuff.
I had the table working for v1.35.0.19887. I see now that it's v1.36.1.20719 and it still works 90% as is (10% requires updating.. cuz yes, Arxan once more fucked up the constants, splitting them into some other forms -- for example, a "MOV r64,[const]" can be done as "MOV r64,[some_other_const_1] + ADD r64,[some_other_const_2] + SUB r64,[some_other_const_3]" <-- the result of those operations would give you the 'const' in the beginning):
P.S.: You can read some user stuff about Arxan here:
[Link]. It's used by Blizzard, Rockstar (Red Dead Redemption, GTA V has it too), then I saw it even in some online games. Its basic aim was to mutate assembly code dynamically, so if, say, some exe were to be hacked, the developer could easily update the exe and ship it to paying customers to resolve that "breach" (to patch hacks). Unless you'd be able to run an older version (it has checks against that, too), you would constantly have to update your work. Not only that, but at times, due to mutation working in random ways, you'd have issues even pin-pointing the locations where you know a hack would work being applied. Gotta love it, eh?
The last paragraph in that article explains it best: it makes no sense to buff up protection when you can devise a good one that can easily be shipped as update so it basically makes it harder for the hacker to keep up with the updates
That's the strategy Blizzard applies, hence the 321739817391 updates of StarCraft 2 per month, as an example... They piss us off with tons of meaningless updates, just to change the exe, till we give up...
What Blizzard doesn't understand, sadly, is that when you ship
debug symbols with your game, it really doesn't matter how much mutation or virtualization you use, you're fudged:
So what if it's for the original Warcraft 3 (32-bit/x86)? Do you really think they've made super major changes when they moved to 64-bit?
No wonder people complained same bugs happen in this one as they happened in the original. Reforged is just a port to x64. If you're used to working with cpp or reverse engineering on a daily basis, determining an x86 function in an x64 binary is a cake-walk
Here's an example of a function from Reforged:
So do we care that the function, internally, looks like this?:
That's what Arxan does.. it pretzles the code with ASM instructions that do nothing or have the same effect, called as
junk code. If you run the entire flow, you will deduct at the end of it all what the actual code is doing and even simplify/remove the junk part. But.. if Blizzard is reading this now, expect a new game update where the exe changes and I'll have to show NEW screenshots with different locations and different form of that SAME code. Cuz that's the whole tactics they're playing: fast updates to kill cheating.
BR,
Sun