Staredit Network

Staredit Network -> Concepts -> EUD Condition offsets?
Report, edit, etc...Posted by yoni45 on 2006-06-02 at 14:39:39
Well, I'm fairly sure their called the offsets, but anyway...

Since the last patch screwed those up, it doesn't look like the new ones have been updated for uberation or posted in general...

Any chance someone plans on doing this in the near future? Is there perhaps a simple way to explain how these could be found and I could try to do it myself?
Report, edit, etc...Posted by Noober on 2006-06-02 at 15:11:11
Well, I think you use Artmoney as the memory searcher, but that's all I know.
Report, edit, etc...Posted by SuperToast on 2006-06-02 at 15:15:48
It's very doubtful anyone else will do it. It took quite a bit of work to find them in the first place, and seeing as that they aren't even supposed to be used at all, it's doubtful if anyone will do it. You should use the downgrader if you really need EUDs.
Report, edit, etc...Posted by yoni45 on 2006-06-02 at 15:43:22
QUOTE(SuperToast @ Jun 2 2006, 01:15 PM)
It's very doubtful anyone else will do it. It took quite a bit of work to find them in the first place, and seeing as that they aren't even supposed to be used at all, it's doubtful if anyone will do it. You should use the downgrader if you really need EUDs.
[right][snapback]497831[/snapback][/right]


Well, it seems like the original find took some work, but finding the specific mem adresses seemed pretty straightforward (for whoever knows what they're doing)...

Map hacks probably come out the next day after a patch, and i'm fairly sure they work on the same concept... You're not implying people here are lazier than map hackers, are u? tongue.gif
Report, edit, etc...Posted by Doodle77(MM) on 2006-06-02 at 17:04:24
map hacks work on a different concept - they dont use buffer overflows.
you use a memory searcher to find the offsets, then memcalc to calculate what you need.
Report, edit, etc...Posted by yoni45 on 2006-06-02 at 18:53:12
QUOTE(Doodle77(MM) @ Jun 2 2006, 03:04 PM)
map hacks work on a different concept - they dont use buffer overflows.
you use a memory searcher to find the offsets, then memcalc to calculate what you need.
[right][snapback]497895[/snapback][/right]


w00t ok, I'm running ArtMoney and I think I've found the adresses for the text display messages...

Memcalc shouldnt be affected by new patch seeing as I've got the new adresses correct? happy.gif

Erm, ok, what's the "Object ID" field? =/

I have the mem adress, as well as the number of values I want to edit, shouldnt this be all that's required? MemCalc seems t require an "Object ID"...

http://homework.f2o.org/memcalc.py
Report, edit, etc...Posted by Mr_Mooo_Cow(U) on 2006-06-02 at 20:21:25
well there is a way to get most of them... I had a more updated list but I haven't been the most active person on sc so I probably lost it. For the majority of the offsets the patch simply 'pushed' the table rather than "scrambling" them. aka old offset + offset created by patch = new offset. so go find where a offset used to be and where it is, add that difference to any other you want and most likely you will have calculated the new offset without searching for it again.
Report, edit, etc...Posted by DT_Battlekruser on 2006-06-03 at 03:09:00
QUOTE(yoni45 @ Jun 2 2006, 03:52 PM)
w00t ok, I'm running ArtMoney and I think I've found the adresses for the text display messages...

Memcalc shouldnt be affected by new patch seeing as I've got the new adresses correct? happy.gif

Erm, ok, what's the "Object ID" field? =/

I have the mem adress, as well as the number of values I want to edit, shouldnt this be all that's required? MemCalc seems t require an "Object ID"...

http://homework.f2o.org/memcalc.py
[right][snapback]497960[/snapback][/right]


"Object ID" is the raw ID of whatever you're editing. If you're reading Unit Properties, then it is the Unit ID of the unit you are reading (Terran Marine is 0).

If you're reading current HP, Object ID is the LocalID of the unit.

If you're readin something that only occurs once, the Object ID is 0.
Report, edit, etc...Posted by yoni45 on 2006-06-03 at 03:20:54
QUOTE(Mr_Mooo_Cow(U) @ Jun 2 2006, 06:21 PM)
well there is a way to get most of them... I had a more updated list but I haven't been the most active person on sc so I probably lost it. For the majority of the offsets the patch simply 'pushed' the table rather than "scrambling" them. aka old offset + offset created by patch = new offset. so go find where a offset used to be and where it is, add that difference to any other you want and most likely you will have calculated the new offset without searching for it again.
[right][snapback]498043[/snapback][/right]


Erm, I'm pretty sure I've already found them...

My problem currently is using MemCalc to convert those into conditions...

The "Advanced" mode seems to require 3 values...

One for the "Memory Offset (Hex Value)", which I assume is simply the memory adress...

one for the "Value Length", which i assume is for how many values you want to edit (say, 006650AE-006650AF would be a length of 2 values)...

The 3rd, is "Object ID", which I can't figure out what that refers to... providing different object IDs results in considerabely different numbers...

Further, logically, I wouldn't imagine there should be another variable at work if one knows which mem address he's looking to edit =/



Btw, on the same note, it seems like the mem address alternates between 11 lines in sequence, not based on the position on which the line happens to be on the screen, but simply each message sent takes on the "next" mem address, as it cycles through 11 lines...

e.g. message 1, regardless of order on screen, will go on mem adress X, message 2, regardless of order on screen, mem adress X+Y, message 3, mem adress X+2Y etc... In this case, i'd imagine 1 message would pop up on different mem adresses for different players based on private messages they may have recieved beforehand, which could result in a possible server split...

If I make 11 triggers with 11 identical conditions but with each refering to the "next" line for the mem address, and I also keep the actions the same, would that cause a server split?

Basically, if different triggers run for different people, but they all run at the same time and generate identical results, would the different systems recognize each other desyncing or would it keep going as normal?

ADDITION:
QUOTE(DT_Battlekruser @ Jun 3 2006, 01:08 AM)
"Object ID" is the raw ID of whatever you're editing.  If you're reading Unit Properties, then it is the Unit ID of the unit you are reading (Terran Marine is 0).

If you're reading current HP, Object ID is the LocalID of the unit.

If you're readin something that only occurs once, the Object ID is 0.

[right][snapback]498279[/snapback][/right]


Ah, you replied just as I was replying...

So, just to humour me, I'd appreciate it if you could confirm what I'm doing as correct (or incorrect heh)...

According to ArtMoney, mem address 006650AE is the first letter of any message I send under the nickname ReaL2gRanD.

Say that for the time being, just to start myself off and making sure I'm getting somewhere, I just want to test for that particular letter, and let's say I'm looking to test for the letter 'k' in that position...

So, I go into MemCalc, punch 006650AE into the Memory Offset (Hex Value), Set Value Length to 1 (as I only want to test for one value), and Object ID to 0...

I get: "To achieve this offset, use Unit ID 28801 with player 3 on byte no 3 "

I go back to create an "action" based on this, for the "add value" I punch in 107 as that is the value of a 'k' in that particular mem adress, and get:

SetDeaths(P3,Add,7012352,28801);

At this point, i go into SF, and as a condition, I set:

Deaths(P3,AtLeast, 7012352, 28801);

Now, granted, I should probably also set a cap on that depending on the other possible letters, but thats the gist of it correct?

Going through that, I found what a previous error of mine was... I'll be testing the above now happy.gif

Update: Erm, no dice... doesn't go through... did I miss something? =/
Report, edit, etc...Posted by Ice_Inferno_X3 on 2006-06-03 at 09:13:39
hm...i thought all of the EUD stuff was patch. i guess iill have to try some of it out now.
Report, edit, etc...Posted by DT_Battlekruser on 2006-06-03 at 14:58:03
The use of EUD actions to modify RAM was patched out of Starcraft in patch 1.13b (I think it's 1.13b, but it was patched out somewhere for sure). Thus, while that trigger is correct, it won't do anything because EUD actions are disabled in the current patch.

However, if you are trying to detect what value is there, using a Deaths() condition for the same location should work; where the death value on the byte is the ASCII of the character.

The only reason Value Length and Object ID are in MemCalc is because in the days of EUD actions, the most popular thing was to edit units. All the two latter values do is move the result location (ValLen * ObjID) bytes so that you are editing a different unit.
Report, edit, etc...Posted by Ice_Inferno_X3 on 2006-06-03 at 16:26:15
QUOTE(DT_Battlekruser @ Jun 3 2006, 02:57 PM)
The use of EUD actions to modify RAM was patched out of Starcraft in patch 1.13b (I think it's 1.13b, but it was patched out somewhere for sure).  Thus, while that trigger is correct, it won't do anything because EUD actions are disabled in the current patch.

However, if you are trying to detect what value is there, using a Deaths() condition for the same location should work; where the death value on the byte is the ASCII of the character.

The only reason Value Length and Object ID are in MemCalc is because in the days of EUD actions, the most popular thing was to edit units.  All the two latter values do is move the result location (ValLen * ObjID) bytes so that you are editing a different unit.

[right][snapback]498625[/snapback][/right]


hm...i see. why does blizzard wanna ruin our fun. i guess it did make starcraft unstable or whatever. thanks for info DT
Report, edit, etc...Posted by Noober on 2006-06-03 at 16:47:13
They probably patched it for other reasons - hacks. Getting rid of EUDs was probably a side effect.
Report, edit, etc...Posted by Doodle77(MM) on 2006-06-03 at 17:30:54
No, EUDs were intentionally patched because you could create a virus with one.
Report, edit, etc...Posted by SuperToast on 2006-06-03 at 19:30:13
Did they ever prove that you could make a complete virus (system compromising i.e. running actual code outside of just a buffer overflow) in a EUD and not just something stupid like a BSOD or similar?

I remember a huge fight over whether you could or could not make a real virus with EUD's but never did find out how it was resolved.
Report, edit, etc...Posted by Zeratul_101 on 2006-06-03 at 20:33:11
i think someone did create a viral map, he then sent it to blizzard as proof and they quickly patched it up after that. at least thats what i've heard
Report, edit, etc...Posted by yoni45 on 2006-06-03 at 21:23:38
QUOTE(DT_Battlekruser @ Jun 3 2006, 12:57 PM)
However, if you are trying to detect what value is there, using a Deaths() condition for the same location should work; where the death value on the byte is the ASCII of the character.


If the byte we're happening to test for is not the first (as in, its the 2nd, 3rd, or 4th byte), wouldn't I need to account for its position relative to the first byte?

If checking for ASCII character #1 in byte 2, shouldnt we be testing for a "256" value in that particular set of 4 bytes? If its in byte 3, we should test for "65536"?

QUOTE(DT_Battlekruser @ Jun 3 2006, 12:57 PM)
The only reason Value Length and Object ID are in MemCalc is because in the days of EUD actions, the most popular thing was to edit units.  All the two latter values do is move the result location (ValLen * ObjID) bytes so that you are editing a different unit.
[right][snapback]498625[/snapback][/right]


Ah, indeed, when setting either one of them to 0 and the other to any number, you get the exact same result...

It's pretty safe to say I need one of them at 0 when looking for the unit who'se deaths can be tested to check the text display?



For the record, does what I'm doing above seem correct? Any particular reason why that wouldn't work? Am I missing something? =/
Report, edit, etc...Posted by Darkomni on 2006-06-03 at 21:55:49
guys, whats the use of trying to get Actions again? their just gonna get patched again with another stupid virus map... :/
Report, edit, etc...Posted by DT_Battlekruser on 2006-06-03 at 22:11:41
I'm not entirely sure what you are saying, but I will try to provide a brief summation of how EUDs work.

Each value for the number of deaths of a unit owned by a player is a 4-byte long. using hexadecimal to represent the byte value, the long looks like this:

00 00 00 00

Let's say you have found the correct memory offset for a specific line of text. If my Battle.net screen name is dtbk (case sensitive), the first four bytes of the RAM for that line of text would be the hex-ASCII equivalents of dtbk and the four-byte long would look like this:

64 74 62 6B

You can use any standard ASCII to hex chart to find values for each character.

When these four bytes are combined to make a long, they are read in reverse order (starting with byte 4) to form an 8-digit hexadecimal number. Given the name dtbk, the number is


64 74 62 6B

6B627464

Converted from hexadecimal to decimal, this becomes the integer 1801614436. Therefore, if my name is dtbk, then the death value starting here is 1801614436.

The next four bytes will be for the deaths of the same Unit ID, with a player one greater than the last (if Player 12 was previous player, it loops and becomes Player 1 with a Unit ID one greater [remember, -1001 + 1 = -1000])

If we are trying to see if I typed 'ya', then the next 4 bytes should have the ASCII : ya (that's colon, space, y, a).

We use the same byte technique used above:



3A 20 79 61

6179203A

1635328058.

Therefore, if both the conditions

Deaths(Unit,Player,Exactly,1801614436);
Deaths(Unit,Player,Exactly,1635328058);

are met, then the given line must conatin

dtbk: ya

as the first eight characters.

QUOTE(SuperToast @ Jun 3 2006, 04:29 PM)
Did they ever prove that you could make a complete virus (system compromising i.e. running actual code outside of just a buffer overflow) in a EUD and not just something stupid like a BSOD or similar?

I remember a huge fight over whether you could or could not make a real virus with EUD's but never did find out how it was resolved.
[right][snapback]498876[/snapback][/right]


No, the only thing ever possible (it is proved) with EUD triggers is a buffer overflow. However, buffer overlows are sufficiently dangerous to warrant a patch.
Report, edit, etc...Posted by SuperToast on 2006-06-03 at 22:27:52
So it was just a buffer overflow problem and no specific malicious code being executed. That at least makes me feel slightly better for acting like such a tool back during that whole virii/safe debate bit.
Report, edit, etc...Posted by yoni45 on 2006-06-05 at 02:23:43
QUOTE(DT_Battlekruser @ Jun 3 2006, 08:11 PM)
I'm not entirely sure what you are saying, but I will try to provide a brief summation of how EUDs work.

Each value for the number of deaths of a unit owned by a player is a 4-byte long.  using hexadecimal to represent the byte value, the long looks like this:

00 00 00 00

Let's say you have found the correct memory offset for a specific line of text.  If my Battle.net screen name is dtbk (case sensitive), the first four bytes of the RAM for that line of text would be the hex-ASCII equivalents of dtbk and the four-byte long would look like this:

64 74 62 6B

You can use any standard ASCII to hex chart to find values for each character.

When these four bytes are combined to make a long, they are read in reverse order (starting with byte 4) to form an 8-digit hexadecimal number.  Given the name dtbk, the number is


64 74 62 6B

6B627464

Converted from hexadecimal to decimal, this becomes the integer 1801614436.  Therefore, if my name is dtbk, then the death value starting here is 1801614436.

The next four bytes will be for the deaths of the same Unit ID, with a player one greater than the last (if Player 12 was previous player, it loops and becomes Player 1 with a Unit ID one greater [remember, -1001 + 1 = -1000])

If we are trying to see if I typed 'ya', then the next 4 bytes should have the ASCII : ya (that's colon, space, y, a).

We use the same byte technique used above:

3A 20 79 61

6179203A

1635328058.

Therefore, if both the conditions

Deaths(Unit,Player,Exactly,1801614436);
Deaths(Unit,Player,Exactly,1635328058);

are met, then the given line must conatin

dtbk: ya

as the first eight characters.



Alright well, that all makes sense (the need to reverse the characters I didn't know about, but hey, live and learn happy.gif)

Now, the issue I seem to be having is getting the correct player number / unit number on which to compare 'deaths'...

Using ArtMoney, I'm finding that mem adress 00665188 (for example) is the first character after the space after the colon that's after your name after you send a message... ie, "ReaL2gRanD:_X", where mem adress 00665188 holds the X...

when going to memcalc, punching in 00665188 into the memory offset, and 0's for the val length and object ID, it returns:

To achieve this offset, use Unit ID 28805 with player 10 on byte no 1.

So, if I say anything whatsoever (11 times to make sure the correct line picks it up)

Deaths(P10, AtLeast, 1, 28805);

should be true. However, its not, and P10 deaths for unit #28805 seem to always be 0, no matter what happens (tested as 'Deaths(P10, AtLeast, 0, 28805);' in which case the trigger runs)...

whatever that death points to seems to never change from 0, even though the adress does change according to ArtMoney...

I've tried the mem adress for a different line as well and that doesn't go through... and I've tried using the "exact" phrase you posted earlier... considering the value doesnt go above 0 (likely because I'm looking at the wrong mem adress?), it doesnt seem to work =/

Ideas? =/
Report, edit, etc...Posted by Kookster on 2006-06-05 at 05:39:37
So have you guys found the offset yet or looking, i read the replies but im not quite sure what it all ment, Im not that in depth, wish i was tho
Report, edit, etc...Posted by yoni45 on 2006-06-06 at 01:01:08
DT_Battlekruser, where art thou? tongue.gif
Report, edit, etc...Posted by LegacyWeapon on 2006-06-06 at 01:25:30
uBe2:
CODE
Public Function GetPlayerIDz(ByVal newPos As Double) As Long
startingPos = "&h00513874"

Offset = newPos - startingPos

GetPlayerIDz = Int((Offset Mod 48) / 4)
End Function

CODE
Public Function GetUnitID(ByVal newPos As Double) As Long
startingPos = "&h00513874"

Offset = newPos - startingPos

GetUnitID = Int(Offset / 48)
End Function
This probably won't work because the startPos isn't 00513874 anymore (I don't think).

I can update uBe2 if someone would give the the offset amount (difference between original and new).
Report, edit, etc...Posted by Kookster on 2006-06-06 at 04:04:17
hey if anyone wants to list the programs i would need to search for the new begining, ide gladly look, cause I want EUD conditions back and Im sure others would like them back too
Next Page (1)