Working /dump for Protected functions in 3.2.0a

[mach1920]

If you go into the World of Warcraft/Data/enUS folder (replace enUS with your region), and move or rename the patch-enUS-2.MPQ (again replacing enUS with your region) file, you can once again use /dump along with protected functions as seen in other threads.

For example, I just renamed this file to patch-enUS-2.MPQ.bak and it works fine. I hope everyone else has as much luck.

[toxicsnipe]

works for me.

[earthFlower]

I highly recommend not using this for a disadvantage in arena or such, it will get you banned.

[toxicsnipe]

what about pve? that'll be fine?

[pulse1200]

Worked but how traceable is this if you dont mind me asking. I feel the Banhammer drawing closer with each step.

[Palumir]

What's /dump?

[mach1920]

For more information in /dump and what it can be used for, see http://www.mmowned.com/forums/wow-ex...functions.html

As far as how safe it is, the actual renaming/removing of the file is no more dangerous than using any conventional model swap, as it is client-side. As far as actually using /dump, I'm not sure if Blizzard has anyway of detecting if someone is using it or not, but one way to be cautious is to not store /dump commands in macros on Blizzard's server, as pointed out by jt12852 (http://www.mmowned.com/forums/wow-ex...ml#post1655969)

[jt12852]

Now that Blizzard has made it completely clear in the patch notes that they consider abusing a secure code path this way to be an exploit, you can be certain that any evidence they discover of people still using it will be dealt with harshly. There is no longer any "innocent" excuse for it.

Even in PvE, players may still find your macroed actions suspicious, and could report them for any number of reasons. Consider the following scenarios:

"I was in a dungeon with a rogue today whose interrupts seemed to be timed exceptionally well. He was even interrupting casts that posed no threat and rogues would normally ignore. According to the combat log, he didn't miss a single one. It seemed suspicious so I thought I'd report it."

"In our Ulduar raid tonight, I saw one of our holy paladins go from his typical 15% overhealing done all the way down to 2% overhealing done, with no extra casualties. Our raid leader is now not satisfied with the rest of us. I'm almost certain the pally must have been using a hack, so I'd appreciate it if you'd investigate what happened."

"I saw an unholy DK killing quest mobs for one of the Icecrown dailies today. I was really impressed with how consistent his rotation was. When I asked him how he managed to do it, he said it was a secret and if he told me, he'd have to kill me. I know he was joking about that last part, but his timing really did seem too-good-to-be-true. I'm not accusing him of cheating, but if there's an exploit out there, I'm sure Blizzard would want to know and look into it."

As you can see, it's certainly possible for well-intentioned players to notice your improved performance. If they observe it long enough, they're likely to become suspicious. If your actions affect them, or if they simply "want to do the right thing", they may even report you for it.

Whether or not Blizzard can directly detect abuse when players block the upgraded DevTools remains to be seen. Since this requires the removal, renaming, or modification of an entire archive file that's normally expected to be present at runtime, it's quite possible that it can be easily detected and communicated back to them. To me, it seems like there is excessive risk in this workaround and it's one I won't be trying with my main account. (Your tolerances for risk may be higher, in which case, I wish you good luck!)

In any case, you should not be storing any /dump macros on Blizzard's servers, as has previously been mentioned. Those servers themselves don't exactly know whether macros are being synchronized (it's purely a client setting), they only know the last time the macros were uploaded or downloaded. So (pardon the double negative) not synchronizing your macros may not be a red flag for them.

Another way for Blizzard to investigate this is to find patterns in their server combat processing logs. Since these macros tend to be extremely precise, this makes patterns even easier for Blizzard to find. Combine that with the fact that thousands of players are typically copying and pasting the exact same macros using the same sequences of abilities and timing, and Blizzard may even be able to automate this kind of suspicious activity detection.

Blizzard should have resigned all their signed addon code and included a new key in the WoW executable to match the new versions. Instead, they just hacked together a quick change to the devtools to prevent casual or even unintentional abuse of the secure code path. It's likely that a "real" fix will come along in 3.2.1 or 3.2.2 after the few good UI developers Blizzard still has can be ripped away from the Next-Gen-MMO project they've been reassigned to.

So, if you're brave, enjoy it while it lasts!

[Cryde]

wow after that post you have definitely earned yourself a cookie jt

[Ssateneth]

Sorry, I just renamed patch-enUS-2.MPQ to patch-enUS-2.MPQ.bak and /dump now does nothing at all, but there is no tainted force popup now.. Instead, with LUA errors turned on, I get..

[string "Interface\FrameXML\BasicControls.xml:
Does anyone know for a fact that they got /dump working like in the previous patch? If so, tell me how, or give me some sort of patching program ~_~

[mach1920]

Did you disable addons first? And did you edit any other files previously?

[Ssateneth]

Did you disable addons first? And did you edit any other files previously?

All addons were disabled. I ran a repair after trying one 'fix', and the repair said it repaired successfully, so I'm assuming it got reverted to 3.2.0a specifications. Tried it again, same deal. For some reason, I won't believe it until I see a video where one opens WoW, logs in, etc etc, attempts to run a /dump and see it gets blocked by tainted whatever, exits how, does the fix, logs back in and runs the same /dump and it works. I don't know, maybe I permabroke it when I ran repair.exe. Ran a diff between the two Dump.lua and modified the one in the tiny mpq to match the one in the original big mpq, same result of an LUA error, though a second Repair.exe possibly broke /dump.. I guess I'll have to find a way to revert, somehow.

edit: i'm copying some files over from a 3.2.0 version of WoW that hasn't been patched yet (everything from enUS folder)

[shadow143]

First yeah i have been here for a while and not posted but this is a good topic...

All the people saying its still not working, maybe your doing something wrong? It works fine for me after doing this. Mabey break it down more.

1.) Goto "World of warcraft" Directory
2.) Goto data
3.) Goto "enUS" or whatever your region is
4.) Find "patch-enUS-2.MPQ"
5.) Rename it to "patch-enUS-2.MPQ.bak"
6.) ????????
7.) Profit

[Ssateneth]

First yeah i have been here for a while and not posted but this is a good topic...

All the people saying its still not working, maybe your doing something wrong? It works fine for me after doing this. Mabey break it down more.

1.) Goto "World of warcraft" Directory
2.) Goto data
3.) Goto "enUS" or whatever your region is
4.) Find "patch-enUS-2.MPQ"
5.) Rename it to "patch-enUS-2.MPQ.bak"
6.) ????????
7.) Profit

Yeah yeah... I changed my mind and am reverting just to 3.2.0a files to fix stuff I broke mucking around with an mpq editor, then I'll rename to see if it'll work.

Edit: Works now. Guess I shouldn't mess with MPQ editors.

[mach1920]

I just tried this again on another computer, and found that the first time I renamed the patch-enUS-2.MPQ file, it still told me that I could not use the function. I had disabled all addons, but I did not check "Load Out of Date Addons." I went back and checked this and it then started working fine. If anyone is having difficulty getting this to work, perhaps make sure that you check Load Out of Date Addons.