Gul

[Aniki]

Gul - Gui unfortunately leaks

This is a follow up on leandrotp's post about creating a "handle watcher". I think Gul is just that, albeit very naive, it scans the handle table for locations, groups, forces and rects and destroys them if they are "unreachable".

library Gul initializer init /*
*/ uses /*
*/     Memory, /* // both libraries can be obtained from:
*/     Version /* // https://www.hiveworkshop.com/threads/accessing-memory-from-the-script-its-time-of-the-revolution.279262/
*/

globals
    // scan for leaks every this number of seconds
    private constant real Leaks_Scan_Delay = 10.0
endglobals


globals
    // these are not used but are needed to fool jasshelper
    integer gul_typecast_integer
    location gul_typecast_location
    group gul_typecast_group
    force gul_typecast_force
    rect gul_typecast_rect

    integer l__gul_typecast_integer
    location l__gul_typecast_location
    group l__gul_typecast_group
    force l__gul_typecast_force
    rect l__gul_typecast_rect
endglobals

private function set_integer takes integer h returns nothing
    set l__gul_typecast_integer = h
    return // prevent jasshelper from inlining this function
endfunction

private function typecast1 takes nothing returns nothing
    local integer gul_typecast_location // jasshelper will implicitly rename this to l__gul_typecast_location
    local location gul_typecast_integer // jasshelper will implicitly rename this to l__gul_typecast_integer
endfunction
//# +nosemanticerror
private function integer_to_location takes integer h returns location
    call set_integer(h)
    return l__gul_typecast_integer
endfunction

private function typecast2 takes nothing returns nothing
    local integer gul_typecast_group // jasshelper will implicitly rename this to l__gul_typecast_group
    local group gul_typecast_integer // jasshelper will implicitly rename this to l__gul_typecast_integer
endfunction
//# +nosemanticerror
private function integer_to_group takes integer h returns group
    call set_integer(h)
    return l__gul_typecast_integer
endfunction

private function typecast3 takes nothing returns nothing
    local integer gul_typecast_force // jasshelper will implicitly rename this to l__gul_typecast_force
    local force gul_typecast_integer // jasshelper will implicitly rename this to l__gul_typecast_integer
endfunction
//# +nosemanticerror
private function integer_to_force takes integer h returns force
    call set_integer(h)
    return l__gul_typecast_integer
endfunction

private function typecast4 takes nothing returns nothing
    local integer gul_typecast_rect // jasshelper will implicitly rename this to l__gul_typecast_rect
    local rect gul_typecast_integer // jasshelper will implicitly rename this to l__gul_typecast_integer
endfunction
//# +nosemanticerror
private function integer_to_rect takes integer h returns rect
    call set_integer(h)
    return l__gul_typecast_integer
endfunction


globals
    private integer p_ef
    private boolean done_ef
    private force exec = CreateForce()

    // we only destroy a handle if it's unreachable (has a reference count of 1)
    // and has a handle table offset greater than this pivot's, i.e
    // the handle must have been created after the pivot;
    // we do it this way in order to avoid accidentally destroying handles created
    // in blizzard.j's globals block or our own handles (exec and our timer)
    //
    private location pivot
    private integer pivot_offset // pivot's offset into the handle table
endglobals

private function handle_table_base_p takes nothing returns integer
    return Memory[Memory[GameState/4+7]/4+103]
endfunction

private function leaks_scan_ef takes nothing returns nothing
    // make at most this many iterations so that we can avoid the op-limit
    local integer N = 2000

     // this many consecutive empty entries in the handle table denote its end;
     // we do it this way because we don't know how many entries are in the handle table =)
    local integer M = 5
    local integer m

    local integer p
    local integer q
    local integer rc // reference count
    local integer a // handle pointer
    local integer ty // handle type
    local integer ht_base_p
    // local integer hid // handle id

    set ht_base_p = handle_table_base_p()

    set p = p_ef
    loop
        set rc = Memory[p/4]
        set a = Memory[(p+0x04)/4]

        if a != 0 and rc == 1 and (p - ht_base_p > pivot_offset) then
            // get the handle's type;
            // note the unaligned memory read (Memory1);
            set ty = Memory1[Memory[(Memory[a/4] + 0x1C)/4]/4]

            // we don't have to destroy units because the game already does this =)
            // if ty == '+w3u' then

            if ty == '+loc' then
                // creating handles "out of thin air", a handle table offset really
                // set hid = 0x00100000 + (p - ht_base_p) / 0x0C
                // call RemoveLocation(integer_to_location(hid))

                call RemoveLocation(integer_to_location(0x00100000 + (p - ht_base_p) / 0x0C))

            elseif ty == '+grp' then
                call DestroyGroup(integer_to_group(0x00100000 + (p - ht_base_p) / 0x0C))

            elseif ty == '+frc' then
                call DestroyForce(integer_to_force(0x00100000 + (p - ht_base_p) / 0x0C))

            elseif ty == '+rct' then
                call RemoveRect(integer_to_rect(0x00100000 + (p - ht_base_p) / 0x0C))

            // elseif ty == '+tmr' then
                // we don't destroy "leaked" timers for now, because it might not be safe;
                // does gui even leak timers?
            endif

        elseif a == 0 and rc ==0 then
            set m = M - 1
            set q = p + 0x0C

            loop
                exitwhen m == 0
                if Memory[q/4] != 0 then
                    exitwhen true
                endif
                set q = q + 0x0C
                set m = m - 1
            endloop

            if m == 0 then
                set done_ef = true
                exitwhen true
            endif
        endif

        set p = p + 0x0C
    endloop

    set p_ef = p
endfunction

private function leaks_scan takes nothing returns nothing
    set p_ef = handle_table_base_p()
    set done_ef = false
    loop
        exitwhen done_ef
        call ForForce(exec, function leaks_scan_ef)
    endloop
endfunction

private function init takes nothing returns nothing
    local integer N
    local integer n
    local location loc
    local location prev_loc
    local integer p
    local integer pivot_p

    call ForceAddPlayer(exec, Player(15))
    call TimerStart(CreateTimer(), Leaks_Scan_Delay, true, function leaks_scan)

    // eat up all the free handle ids so that we can put pivot at the end of the handle table
    //
    set N = 16
    set n = N
    set prev_loc = Location(0.0, 0.0)
    loop
        set loc = Location(0.0, 0.0)

        if GetHandleId(prev_loc) + 1 == GetHandleId(loc) then
            set n = n - 1
            exitwhen n == 0
        else
            set n = N
        endif

        set prev_loc = loc
    endloop

    set pivot = loc
    set pivot_offset = 0x0C * GetHandleId(pivot) - 0x00C00000
endfunction

endlibrary

 

[Chaosy]

Obviously something highly wanted.
Would be awesome if you could post a demo for those pure GUI users out there.

 

[GhostWolf]

Yes.

 

[Dr Super Good]

One could possibly write an optimizing JASS compiler that detects most common leaks and automatically fixes them.

I am guessing this uses unsafe JASS mechanics such as non-standard type casting or arbitrary memory reading? Such mechanics might not be future proof as they are highly likely to be subjected to patching for security reasons.

 

[leandrotp]

One could possibly write an optimizing JASS compiler that detects most common leaks and automatically fixes them.

I am guessing this uses unsafe JASS mechanics such as non-standard type casting or arbitrary memory reading? Such mechanics might not be future proof as they are highly likely to be subjected to patching for security reasons.

We use what we have at our disposal.

Writing a new JASS optimizer with such functionality is certainly possible, but it requires much more time and effort. It's 2017 and we are still hacking around with the old Jasshelper, why? Because no one bothered to develop a new tool to fit today's needs.

We have a big power in hands with memory access, why refrain from using this power only because "it might not be future proof"? At 1.23 time, every map used typecasting, and no one complained about it, even though they knew Blizzard was going to fix it.

After all, it's Blizzard's responsibility to keep backward compatility with older maps. "Try not to break existing maps" is a top priority for their patch development. And if we make memory hack very popular, with a lot of maps using it, then they will be forced to keep compatibility with those maps, or at least give the developers a safer alternative.

And IMO, it's very unlikely that they remove typecasting completely. It is more likely that the code eventually fails because of game offsets, but I'm doing my best to keep it as most future proof as possible with automatic detection, and I've been successful until now.

The next update to Version library will have more structured code, and will use a bunch of static ifs so that it will only attempt to detect the offsets that are actually used by the map. This will certainly reduce even more the chance of failure in future patches.

 

[Dr Super Good]

We have a big power in hands with memory access, why refrain from using this power only because "it might not be future proof"? At 1.23 time, every map used typecasting, and no one complained about it, even though they knew Blizzard was going to fix it.

Actually people did not know Blizzard was going to fix it. People assumed it was completely safe until the one person demonstrated how one could execute malicious code and someone made a malicious DotA Allstars map. Only reason Blizzard fixed it was because of that problem, which is also why they added the new natives to replace most of the required functionality. They did not replace the functionality to execute arbitrary code.

After all, it's Blizzard's responsibility to keep backward compatility with older maps. "Try not to break existing maps" is a top priority for their patch development. And if we make memory hack very popular, with a lot of maps using it, then they will be forced to keep compatibility with those maps, or at least give the developers a safer alternative.

Program developers have the responsibility to patch exploits, especially major ones such as arbitrary memory reading. If it breaks backwards compatibility it is then up to the users to fix their content, and we all know they never do.

And IMO, it's very unlikely that they remove typecasting completely. It is more likely that the code eventually fails because of game offsets, but I'm doing my best to keep it as most future proof as possible with automatic detection, and I've been successful until now.

It is highly likely they will eventually add tests to make sure JASS can only read the values it is intended to. After all you do not want it reading BattleNet authentication tokens or remnants of passwords and such. Hence why arbitrary memory reading is almost never a feature of user content in games.

 

[csh]

Actually people did not know Blizzard was going to fix it. People assumed it was completely safe until the one person demonstrated how one could execute malicious code and someone made a malicious DotA Allstars map. Only reason Blizzard fixed it was because of that problem, which is also why they added the new natives to replace most of the required functionality. They did not replace the functionality to execute arbitrary code.Program developers have the responsibility to patch exploits, especially major ones such as arbitrary memory reading. If it breaks backwards compatibility it is then up to the users to fix their content, and we all know they never do.
It is highly likely they will eventually add tests to make sure JASS can only read the values it is intended to. After all you do not want it reading BattleNet authentication tokens or remnants of passwords and such. Hence why arbitrary memory reading is almost never a feature of user content in games.

In fact, the built-in dll is widely used in chinese war3 map now, since memory writing exploit was not fixed even in patch 1.28（there is another way to achieve it）.

Several chinese map use dll to enhance map function, such as d3d hook, more japi, and built-in online shop, encrypting map is possible by using lua scripts to instead of jass, and when map was modified by others, the modified map will shutdown the computer and popup a window to notify the map is modified.

It's a long time since patch 1.28 released and so many chinese maps using dll, but blz still do nothing on this exploit, so i dont think blz will fix it.

 

[Dr Super Good]

Several chinese map use dll to enhance map function, such as d3d hook, more japi, and built-in online shop, encrypting map is possible by using lua scripts to instead of jass, and when map was modified by others, the modified map will shutdown the computer and popup a window to notify the map is modified.

And that is why it must be removed. Such malicious behaviour is only a step away from out right downloading malware, installing key loggers, encrypting all your files and demanding money etc.

The big question is why on earth is Blizzard taking so long to patch out this stuff seeing how it is clearly a critical security exploit? Are they honestly waiting until a Bad Rabbit or Wanacry style attack occurs on their players?

 

[Kakerate]

The big question is why on earth is Blizzard taking so long to patch out this stuff seeing how it is clearly a critical security exploit? Are they honestly waiting until a Bad Rabbit or Wanacry style attack occurs on their players?

It is odd to think Memory Writing exploits were patched out, but .dlls haven't been. Is Preload exploit still a thing in 1.28 as well? If so, the requirement of memoryhack being executed from within a .dll isn't even any solution, just an inconvenience. Let me use memory on bnet again damnit!

 

[Dr Super Good]

It is odd to think Memory Writing exploits were patched out, but .dlls haven't been. Is Preload exploit still a thing in 1.28 as well? If so, the requirement of memoryhack being executed from within a .dll isn't even any solution, just an inconvenience. Let me use memory on bnet again damnit!

One cannot patch out dlls as they are a core part of Windows OS. If you mean arbitrarily modifying or adding .dll files into a program files folder that will execute next time that program runs then that is a critical exploit that should be patched out.

 

[leandrotp]

It is odd to think Memory Writing exploits were patched out, but .dlls haven't been. Is Preload exploit still a thing in 1.28 as well? If so, the requirement of memoryhack being executed from within a .dll isn't even any solution, just an inconvenience. Let me use memory on bnet again damnit!

As DrSuperGood said, there's no way to "fix" DLLs, but the key difference here is that they require the user to explicitly install 3rd party stuff on their computer, so users are responsible for anything they install, as opposed to an exploit, where you achieve arbitrary code execution from where you're not supposed to.

Think of a web browser page, it runs javascript, but suppose someone found an exploit that allowed direct memory access from javascript: it would be terrible, even if it would be used for a browser game, for example.

However, the developer of such a game could instead distribute a custom browser plugin for their users. It would no longer be a problem since the users are explicitly trusting the developer, and installing the plugin themselves, so it's their responsibility.

Of course such a plugin should be designed in a safe way, so that it can only be used by the developer's own code, and doesn't expose vulnerabilities that could be exploited by other websites. But history has shown the opposite. (Virtualbox has deployed a lot of vulnerable and digitally-signed kernel drivers, that are still used by today's exploits to achieve kernel-level access under Windows.)

One cannot patch out dlls as they are a core part of Windows OS. If you mean arbitrarily modifying or adding .dll files into a program files folder that will execute next time that program runs then that is a critical exploit that should be patched out.

Injection of DLLs into WC3 is something that simply cannot be patched. But as I said, it's not a problem if the user is downloading and installing 3rd-party stuff by himself, this is not an "exploit". The problem only exists when a map is able to export a DLL from its own MPQ (or even download it from the web) and inject it into WC3, without user interaction, as it opens the possibility for anyone to spread viruses over bnet.

 

[Dr Super Good]

Injection of DLLs into WC3 is something that simply cannot be patched. But as I said, it's not a problem if the user is downloading and installing 3rd-party stuff by himself, this is not an "exploit". The problem only exists when a map is able to export a DLL from its own MPQ (or even download it from the web) and inject it into WC3, without user interaction, as it opens the possibility for anyone to spread viruses over bnet.

Exactly. Such an exploit was demonstrated with the arbitrary code exploit before it was patched long ago. A demonstration map was made that would change the desktop image next time the computer restarted. The same type of attack shown there could also be used to inject kernel level DLLs, delete user's data or worse.

It eventually resulted in a fake DotA map, which was specially seeded to cause a hash collision with the real one so would show up as the real one from the game list. Victims joined the lobby, downloaded the map near instantly, were pushed in game instantly there after and then the map went to work. Among the many things it did, one of them involved deleting all Warcraft III from the computer. It almost certainly did other stuff such as installing malware.

Any such exploit must be patched.

 

[karaulov]

There would be no need to create exploits if we had access to all object parameters and other variables, and it is also possible to create inverse functions for any actions, access to keyboard keys, mice and so on.



Unity, Unreal Engine can't be used for create malwares ? (Can be uses clean c++ c# code!)

 

[Dr Super Good]

Unity, Unreal Engine can't be used for create malwares ? (Can be uses clean c++ c# code!)

One needs to actively download and install such a game, which is up to user if it is safe or not and usually needs administrator access anyway.

A WC3 map is something completely different. One does not except it to contain malware. Similar to how one simply receiving an email should not give you malware (believe it or not in the old days this actually could give you malware due to various exploits).

 

[Kakerate]

I think there's an obvious diffference between opening an email, and running software made by a non-legal entity. There's an obvious risk with any software of which you do not know the source. Comparing .w3x's to emails is Apples & Oranges, really.

 

[GhostWolf]

For once I have to agree with DSG. These are definitely not apples & oranges, because the user is trusting Blizzard to supply a safe platform, much like you trust Gmail to supply a safe platform that doesn't infect you with viruses.

That being said, obviously I agree that all of these things should be natively supported, which will remove the need for exploits in the first place.

Until then, let the awesome hacks continue.

 

[karaulov]

One needs to actively download and install such a game, which is up to user if it is safe or not and usually needs administrator access anyway.

A WC3 map is something completely different. One does not except it to contain malware. Similar to how one simply receiving an email should not give you malware (believe it or not in the old days this actually could give you malware due to various exploits).

Warcraft III is engine
Every map - new game.


Unreal Engine / Unity - engine.
...

 

[karaulov]

Need more context and abilities (full access to objects and other data) for more quality games.
Memory Hack (Inject dlls files, etc) give this abilities, fully.



And for example possible wrote own game using Warcraft protocol, just remove all warcraft objects and using own engine writted in c++ loaded using Memoryhack.

 

[Dr Super Good]

I think there's an obvious diffference between opening an email, and running software made by a non-legal entity. There's an obvious risk with any software of which you do not know the source. Comparing .w3x's to emails is Apples & Oranges, really.

I said nothing about opening an email. In the old days simply receiving one (action of it landing in the in box) was enough to get malware. Now even opening emails usually is not enough, you need to actively run the malware attached.

 

[Kakerate]

because the user is trusting Blizzard to supply a safe platform, much like you trust Gmail to supply a safe platform that doesn't infect you with viruses.

Right. but its not. All custom maps are still just war3s VM. Blizzard has no way to safeguard against unexpected behavior, like crashes. The preload exploit still trashes your computer. Before memory was patched, nothing malicious was done on battlenet. Viruses could still be just as easily spread through .dlls. But they're not. This group of malicious people doesn't exist. But even if they did, wouldn't you still just host the official versions of the maps you play and be fine?

 

[~El]

Right. but its not. All custom maps are still just war3s VM. Blizzard has no way to safeguard against unexpected behavior, like crashes. The preload exploit still trashes your computer. Before memory was patched, nothing malicious was done on battlenet. Viruses could still be just as easily spread through .dlls. But they're not. This group of malicious people doesn't exist. But even if they did, wouldn't you still just host the official versions of the maps you play and be fine?

The Preload exploit was patched to only allow writing in CustomMapData with the latest patches. You can't write to any file anymore with it.
Saying that nothing malicious was ever done on battle.net is naive - there HAVE been incidents and proof of concept trojan maps floating around, especially before the return bug was fixed, and everyone thought it was the end of it. Blizzard saw the potential danger in pre-1.24 patches and patched it out - exactly because it was dangerous. And WC3 was much more popular back then. It was relatively safe for a long while because nobody knew that this exploit existed.
Hosting only official maps is fine - yet, do you expect every single player to be aware of the risk? Map signatures have been forged in the past to make it look like you're downloading a map that you already have - unattentive or clueless users will have no idea that it might be malicious. All it takes is a single malicious host, and you potentially have 12 infected players.

A sophisticated enough trojan could even alter the wc3 executable to infect all played maps. Potentially, if an infected user hosts any map - they will infect everyone else in the same game as them. Just because nobody has done it, doesn't mean it's impossible. Just because you don't know about it - doesn't mean someone hasn't tried already.

Host bots remedy this to an extent, since they can't be infected (they don't actually run wc3), but what about platforms where host bots aren't prevalent, like Garena?

And how do you know that a mapmaker you know hasn't decided to inject a trojan into his map? Are you going to deprotect his map and go through swaths of obfuscated JASS just to make sure there's nothing there? A trojan can lie dormant for many days, weeks, or even months - doing nothing and triggering no detection, until the author decides it is time to activate it.

The only reason this might have not happened yet is because WC3 is already dead, and nobody wants to bother with it anymore. So, perhaps, as an enthusiast's last resort to breathing some new life into an old game - it works. But if this somehow brings a swath of new players into it - you can be 100% sure that with those new players it will bring people willing to exploit this new playerbase. Especially because it is so easy.

EDIT: And what if someone hosts an infected version on a hosting bot? How many players can a bot go through per a day? Dozens? A hundred? What if it's particularly popular? What if it's in a community with dozens of different bots? There's no way to tell that a map is infected without rigorous reverse-engineering and analyzing.

EDIT2: Also, saying that Blizzard can't safeguard against exploits is also naive. Sure, they don't have omniscience and infinite foresight - but the whole purpose of the JASS VM is to allow mapmakers to customize maps without subjecting the player to danger. If they can fix something dangerous - they absolutely should - and thankfully, they have done that.

 

[Kakerate]

For 1.5 decades you could easily ruin somebodys computer, (much easier than by writing your own worm to run inside war3). But it never happened. Also, back the first time the malicious maps rolled around, no one was aware of the risk. Now people are.
The patch migration is annoying as fuck btw, runs really slow and is totally unnecessary. Bnet is stuck with the capabilities war3 had back in 2012, or whenever the 8 MB limit remover came out. Enjoy shitty 2012 API, I'll be doing new things over here in 2017.

but what about platforms where host bots aren't prevalent, like Garena?

No reported issues from people on Garena, despite the R I P E opportunity.

Map signatures have been forged in the past to make it look like you're downloading a map that you already have - unattentive or clueless users will have no idea that it might be malicious. All it takes is a single malicious host, and you potentially have 12 infected players

Also, saying that Blizzard can't safeguard against exploits is also naive.

But they can't. .dll's will always be able to infect you. Buggy maps are still going to crash.

Your points essentially boil down to someone who can't accept the possibilites memory allows for. I thought war3 programming community was pretty much intent on hacky ways to get a good result, though the worst result from them was a crash (as far as we know o: o: O: SP00KED)

 

[HappyTauren]

I love it when the 1.26 crowd presumes nobody has suffered due to malicious maps, just because they haven't. It's as hilariously ill thought out as saying that nobody ever gets raped or robbed because hey, they have been coming home late all their lives, but it never happened to them. And yes, people have had their accounts stolen, and I am not talking about just wc3/bnet accounts.

 

[TempMail]

I love it when the 1.26 crowd presumes nobody has suffered due to malicious maps, just because they haven't. It's as hilariously ill thought out as saying that nobody ever gets raped or robbed because hey, they have been coming home late all their lives, but it never happened to them. And yes, people have had their accounts stolen, and I am not talking about just wc3/bnet accounts.

Oh come the fuck on, you have no proofs either, but u heavily insists there are. People get scammed all around world, giving their data to everybody in a blink of an eye. Yet of course you're on ur way to protect them. Go ahead (away).
The only future wc3 can have is ghost bots, not user-hosted maps. And platforms are able to make contact with dev to proof the map.

 

[~El]

For 1.5 decades you could easily ruin somebodys computer, (much easier than by writing your own worm to run inside war3). But it never happened. Also, back the first time the malicious maps rolled around, no one was aware of the risk. Now people are.
The patch migration is annoying as fuck btw, runs really slow and is totally unnecessary. Bnet is stuck with the capabilities war3 had back in 2012, or whenever the 8 MB limit remover came out. Enjoy shitty 2012 API, I'll be doing new things over here in 2017.


No reported issues from people on Garena, despite the R I P E opportunity.






But they can't. .dll's will always be able to infect you. Buggy maps are still going to crash.

Your points essentially boil down to someone who can't accept the possibilites memory allows for. I thought war3 programming community was pretty much intent on hacky ways to get a good result, though the worst result from them was a crash (as far as we know o: o: O: SP00KED)

Crashes were never a problem - you just crash and restart. Big deal. The effect is only temporary. This isn't the same with a trojan.

When a player installs an additional DLL, they take the risk upon themselves. Whether or not they are aware of that risk is their problem. Everyone should know that running .dlls/.exes from the internet incurs a risk. This isn't specific to WC3, but computer usage in general. WC3 maps were never meant to come with that risk, however, it's a different story.

For 15 years these exploits were unknown, or if they were known - they were being kept secret by the few people that did know. That pretty much kept collateral damage to a minimum, since only the most advanced users even knew of this exploit's existence.

Now everyone knows. Anyone with enough dedication can do exactly what I outlined. That is the problem. Publicity.

I'm all for hacky ways to squeeze out additional use cases from WC3. However, I value security above utility. I don't want to use a tool that has the chance of killing me in the process. I don't want to run a game that has a chance of infecting my computer.

 

[Kakerate]

And yes, people have had their accounts stolen, and I am not talking about just wc3/bnet accounts.

id like to see any documentation from anybody of their personal info being stolen as a result of wc3 attack. I'm genuinely curious, 'cause I kinda doubt it. Have you ever run the code yourself to see what it does? Or are you just presuming things? I'm not saying it's not possible, I'm saying you don't know if it has happened or not.

Now everyone knows. Anyone with enough dedication can do exactly what I outlined. That is the problem. Publicity.

Maps verified on THW aren't going to give you viruses, that's for sure. If you're playing my game through my server, you can be assured you're not going to be getting a fake version of the game. What you're saying would be a violation of US law 'Computer Fraud and Abuse Act' which is such a punishing crime that you can just be assured it won't happen here on hive.

 

[csh]

It is odd to think Memory Writing exploits were patched out, but .dlls haven't been. Is Preload exploit still a thing in 1.28 as well? If so, the requirement of memoryhack being executed from within a .dll isn't even any solution, just an inconvenience. Let me use memory on bnet again damnit!

Memory Writing exploits were not patched even in latest patch in fact.

There's another way to achieve it, and the exploits were widely used in chinese maps.

 

[Kakerate]

Memory Writing exploits were not patched even in latest patch in fact.

Right, but until a proper LUA script and instructions become known it might as well be.

 

[Marcos_M]

Memory Writing exploits were not patched even in latest patch in fact.

There's another way to achieve it, and the exploits were widely used in chinese maps.

Do you have a link for a Memory-writing map working on 1.27b+?

 

[EdgeOfChaos]

There is a big reason not to use methods that will be patched in the future. Some maps will use methods like this, and then quit mapmaking or move on for other reasons. Then it gets fixed, and suddenly we have unplayable maps. This is what happened with the return bug - there are still broken maps that will never be fixed, games that are dead because people did not pay attention to this.

If a technique can be used to alter state outside of WC3's little environment, it will be fixed. They have shown this by patching the return bug, and more recently patching writing text files with alternate extensions (like .bat) that could alter computer.

 

[csh]

There is a big reason not to use methods that will be patched in the future. Some maps will use methods like this, and then quit mapmaking or move on for other reasons. Then it gets fixed, and suddenly we have unplayable maps. This is what happened with the return bug - there are still broken maps that will never be fixed, games that are dead because people did not pay attention to this.

If a technique can be used to alter state outside of WC3's little environment, it will be fixed. They have shown this by patching the return bug, and more recently patching writing text files with alternate extensions (like .bat) that could alter computer.

You are right, but the fact is the new return bug and memory hack system was not patched for more than one year, one reason may be that the agent of blizzard game in China need these exploits to save map developers.

 

[Kakerate]

the agent of blizzard game in China need these exploits to save map developers.

I think the majority of the Hive community has shown this isn't true. Most people don't care to learn how war3 actually works, and thus immediately jump to the bandwagon of it being a 'bad' thing. If you consider how many times Cucktivision-Blizzard has split the War3 community, you'd be wiser than to think they won't do it again. That being said, I'm totally willing to help update offsets for memory librarys to get them running on current patch. Would be a good way to show people that the best modders around CAN and WILL make use of War3s engine, to the fullest.

 

[csh]

I think the majority of the Hive community has shown this isn't true. Most people don't care to learn how war3 actually works, and thus immediately jump to the bandwagon of it being a 'bad' thing. If you consider how many times Cucktivision-Blizzard has split the War3 community, you'd be wiser than to think they won't do it again. That being said, I'm totally willing to help update offsets for memory librarys to get them running on current patch. Would be a good way to show people that the best modders around CAN and WILL make use of War3s engine, to the fullest.

The game.dll and storm.dll will be inlined into warcraft III.exe in patch 1.29, i dont know if they will fix the exploit or not, but it is sure that memory hack system shall be changed alot to be compatible with the new patch.

 

[pyf]

The game.dll and storm.dll will be inlined into warcraft III.exe in patch 1.29 [...]

Source, please? tia

 

[csh]

Source, please? tia

I saw the screenshot of internal test version for patch 1.29 from a friend working for blizzard.

 

[DracoL1ch]

I saw the screenshot of internal test version for patch 1.29 from a friend working for blizzard.

You're full of surprises. What the reason to keep up with official patches anyway if China is about platforms? Or Bnet somehow still prevails?

 

[csh]

You're full of surprises. What the reason to keep up with official patches anyway if China is about platforms? Or Bnet somehow still prevails?

The popular platform in China is NetEase's platform, NetEase is the offical agent of blizzard game in China who push blizzard to update the warcraft3, so you can find the NetEase's platfom icon inside mpq from patch 1.27a, which had been discussed on HIVE(an icon with two letters “NB”, which means NetEase and Blizzard, you can find it in each 1.27+ patches).

NetEase will force players to update their game to latest version, so this is the reason, but still a lot of chinese players keep old patches and play WC3 on the other platfoms or offline.