Reading memory via JASS?

[sethmachine]

Hi,

Is there anyway to read WC3's memory via JASS?

e.g. suppose you would like to access the duration field of a particular spell. This information has to be in the map / held somewhere in WC3's current memory while playing the map, even if there is no native that reads it.

In Blizzard's Starcraft Broodwar (Starcraft I, not Starcraft II), adept programmers found ways to read SC's memory or even write to it by using memory overflows. This allowed triggering which SC didn't support and was otherwise impossible to do.

For context here is an example of using "extended" units / players (player values above the canonical ones, which apparently always crash WC3 but not SC): http://www.staredit.net/topic/15356/

In other cases, SC's custom editor has its own special memory condition that takes advantage of the fact that the death table (the data structure holding information about the number of deaths of each unit) is also next to other data structures, and so attempting to read in absurdly high values in the death table (e.g. player X suffered -1745653 deaths of unit X) actually reads memory in other places.

So is there anyway to read memory via JASS?

 

[PurgeandFire]

One or two of the ConvertXXX() abilities read memory out of their bounds, but I think most of them perform bound checks. See:
http://www.hiveworkshop.com/forums/triggers-scripts-269/hidden-attack_type-world-editor-227993/

Memory reading would be rather useless for reading object editor data. Databasing is simpler and faster. Just store the data you would need to read in a hashtable (based on the object editor). You can either do it manually or you can write a script to generate the code based on the object editor data in the map.

 

[Aisha Mizuki]

Actually what JASS stand for and what for? for make W3 WorldEditor goes faster? hmmm

 

[Bannar]

Jass is a scripting language created by Blizzard which is used throughout their games. It's designed to be used as trigger related/event-driven language, thus common scripts follows order: Event (action) -> Expression (reaction).

There is no "GUI" - it is just graphic interface wrapped around Jass api, when you convert your "trigger" into custom script, you will see what is really going on.

And yes, coding scripts by your own, without usage of GUI allows you to bypass some limits (due to lack of relatives of some stuff for GUI) and write code in a bit more efficient way.

 

[Aisha Mizuki]

Owh.. if you said that Jass is scrpting language, then i understand.

And JASS are more complicated than GUI right? and JASS exceed some limits that some GUI can't do♪(*￣ー￣)ｖ

 

[Xonok]

GUI is JASS and thus, it can do just as much if you extend it(doable).

 

[Bannar]

You probably didnt get excactly what I meant. I suggest you should visit GUI/Triggers and Jass tutorial sections for an additional info in regard to basic WE knowledge, required when working with Trigger Editor.

 

[chobibo]

Actually what JASS stand for and what for? for make W3 WorldEditor goes faster? hmmm

Just Another Scripting Syntax [source]

 

[Ezekiel12]

Okay, to return to the original topic:

In the past there was an exploit which enabled full memory reading (by Toadcop and others), it got patched though.
In the current version there are several natives which can read out of their bounds but its all quite of limited use.

Go play around with the ConvertXXX natives and such, if youre able to retrieve mouse coordinates or somehow even set new values at runtime in a save way, you will be the new hero.

 

[sethmachine]

Thanks Puregeandfire and Ezekiel12 for referring me to the ConvertXXX thread. Very interesting.

Just curious, though, why didn't Blizzard simply implement a condition to read memory? Reading is never dangerous AFAIK, unlike writing. Using Local Files Enabled would allow doing this, and also executing arbitrary code as well?

 

[PurgeandFire]

Blizzard probably doesn't want to allow people to know what memory is stored where. That is essentially the basis behind cheat engines.

 

[edo494]

yea, its always safe to read everything

image

 

[sethmachine]

That's the OS throwing an error, though. AFAIK, unless we are dealing with quantum physics (where "reading" / "observing" a value causes a change), there shouldn't be any danger in reading an arbitrary memory address, unless this is fundamentally wrong.

 

[Xonok]

He showed you what exactly can happen for reading the wrong memory(fatal error).

 

[sethmachine]

But isn't that the OS throwing the error to enforce compartamentalization (a program shouldn't read memory that doesn't belong to it)? Theoretically what is wrong with reading any memory address?

 

[Xonok]

Cheat engine and other similar programs read memory, so technically it shouldn't be a problem.
However, as purge said, blizzard might not want you to know the exact memory addresses of everything.

 

[Dr Super Good]

There should not be any such way as this would be a major security risk. If there is I would advise avoiding it as Blizzard could eventually patch it (not likely but still possible).

Exact memory locations outside of constants are likely to not be deterministic so would require synchronization before they can be used in multiplayer.

 

[edo494]

But isn't that the OS throwing the error to enforce compartamentalization (a program shouldn't read memory that doesn't belong to it)? Theoretically what is wrong with reading any memory address?

still nothing

warcraft 3

as you see, you cant read just any memory. You can only read memory that is assigned to your process. This is because several reasons. First is that every modern computer uses Virtual addressing, and if the value is not mapped to some physical address, what you do?

Also even reading can be dangerous. You dont need to write to get some SSH encryption keys out of someone's computer.

Also as mentioned, if it was possible to read the memory, you could write pretty much undetectable fog-vision, because afaik the game has all information it needs, it knows where the enemy army is even if it is fogged. If you even read that value, and is in consistant place, you will basically allow people to see in the fog(Professional programming)

 

[Rui]

Supposedly inter-process boundaries are already implemented by the operative system, so addressing memory of other processes shouldn't be a problem? In those cases it should definitely throw a fatal error.

If you look at it this way, there are many natives that read memory, just not all of it. Although, if you find any way to read more, be sure to tell us =P because Blizzard really failed by, for example, not allowing us to read every and all Object Editor fields. Major bummer, I know where you're coming from.

EDIT: About Mag's finding with player colors, I find it very awkward that the effects are different every time. Certainly it must be some kind of game instance value and SetUnitColor() is going to run a chuck of code with the address of that value.

 

[Dr Super Good]

Supposedly inter-process boundaries are already implemented by the operative system, so addressing memory of other processes shouldn't be a problem? In those cases it should definitely throw a fatal error.

It is not possible to address memory from one process in another process directly. A process can only access other process memory space by using I/O OS calls (if any) or mapping part of the other process memory space into itself (pages of memory can be shared between multiple processes at different virtual addresses).

Unless specifically given permission (run as an administrator with elevated permission), the OS will usually throw a security exception back at the process (not allow it). This will usually produce a process level fatal error as either the exception is left unhandled (propagates to main) or the process handles it but might as well shut down since it cannot perform its desired purpose.

EDIT: About Mag's finding with player colors, I find it very awkward that the effects are different every time. Certainly it must be some kind of game instance value and SetUnitColor() is going to run a chuck of code with the address of that value.

Where stuff is allocated in memory is not deterministic. The closest are the game code and constants which are usually loaded into memory in a certain order but even then the OS could load other things depending on version of required libraries or how the Anti-Virus operates.

 

[Rui]

edo created a thread to discuss this here.