Page 5 of 6

PostPosted: Thu Mar 05, 2009 5:29 pm
by WhiteHat
Aspras wrote:Also found a pointer to the purple slot's damage stat.

[[Game.dll+0xA705FC]+0x1E4]+0xA0


So sorry for double post.. I can’t edit my previous one..

I tried the complex address into expression evaluator when in-game, it was
unobtainable.. The value at address Game.dll+0xA705FC was equal to zero..

PostPosted: Fri Mar 06, 2009 12:18 am
by Aspras
Thats the pointer to the purple player's damage address I had found, though a day after I realised that if you edit that value all of the AI heroes' damage changes as well, treants' too. So its not really working correctly though Game.dll+0xA705FC does not give me zero even now : / .

PostPosted: Fri Mar 06, 2009 12:50 pm
by WhiteHat
That’s quite strange....

[Game.dll+0xA705FC] returns 0 (zero) for me all the time..
But, that perhaps we’re playing different version of WC3 ?

PostPosted: Wed Mar 11, 2009 10:38 pm
by Aspras
I have the same version as yours.

Re: DOTA Players’ Gold: Complex Address (...answering Felhea

PostPosted: Sun Mar 15, 2009 11:50 am
by Fishy
So i was just trying this out and everything is working fine.

But i do not understand what you mean about
Whitehat wrote:From those two pictures above, i got the registers values:
- EDX = 0x18610010 (got it from the 1st ASM code)
- EAX = 0x2A (got it from the 2nd ASM code)


After picture 6a and 6b

PostPosted: Mon Mar 16, 2009 1:16 pm
by WhiteHat
Remember that I was doing auto-hack to address 0x18610164 and got those 2 codes (pic 6a and 6b):

Image

the result in Auto-Hack window as follows:

Here is pic 6a:
Image
from the highlighted code, we can’t easily determine the value of EAX since it was written after the code executed..
But we can determine the value of EDX from Registers Window below, which was 0x18610010..

In other word, the value of EAX in the Registers Window below was not the one we were looking for (false EAX)..

Here is pic 6b:
Image
from the highlighted code, we can’t easily determine the value of EDX since it was written after the code executed..
But we can determine the value of EAX from Registers Window below, which was 0x2A..

In other word, the value of EDX in the Registers Window below was not the one we were looking for (false EDX)..

Using those two codes and their registers info, we get the correct value of EDX and EAX:
0x18610164 = EDX+(EAX*0x8)+0x4
- EDX = 0x18610010
- EAX = 0x2A

0x18610164 = 0x18610010+(0x2A*0x8)+0x4
0x18610164 = 0x18610010+0x150+0x4
0x18610164 = 0x18610164

PostPosted: Mon Mar 16, 2009 8:06 pm
by Fishy
Ok i understand all of that now.. Thank you

Last part im stuck on is how you came up with the equation

EDX+(EAX*0x8)+0x4

PostPosted: Fri Mar 20, 2009 3:05 am
by Aspras
EDX+(EAX*0x8)+0x4 is a pointer. Breaking that pointer up you notice it is made up of an address with an offset added to it, EDX holds that address and (EAX*0x8)+0x4 is the offset.

PostPosted: Fri Apr 10, 2009 9:22 am
by Fishy
White-Hat you know the addresses since they patched it to 1.23?

PostPosted: Sat Apr 11, 2009 10:18 am
by WhiteHat
Haven’t patch to version 1.23 yet, cause i’ve been busy lately...
However, i’m quite sure that we only have to change the static base address, from any available complex addresses...

Example for gold value in ver 1.22:
Code: Select all
Player #01 (Red) : [[["Game.dll"+0xAA4178]+0xC]+(0x002*0x8)+0x4]+0x78


For version 1.23, we only need to replace the offset of "Game.dll"+0xAA4178, that is 0xAA4178 into some value else, so the complex address for version 1.23 will be something like this:
Code: Select all
Player #01 (Red) : [[["Game.dll"+(OffsetForVer1.23)]+0xC]+(0x002*0x8)+0x4]+0x78


The best way to do this probably is to use MHS Expression Search to find the Static Base Address...

PostPosted: Thu Jun 04, 2009 12:43 am
by tkbnj
L. Spiro wrote:Fixed-point decimals != encryption. Read below.

And encrypting executables has nothing to do with how the game processes these decimals—such an obtrusive modification could not possibly be done reliably; executable encryptors guarantee run-time reliance, exceptions not owing to encryption itself.

They may, however, inject useless code that may end up multiplying values by 10 and juggling them around in various ways, but these values are never saved anywhere (you can not find them via searching) and all registers are backed up before and restored after these useless operations to guarantee once again that the packer has not in any way interfered with the executable it is packing.

Furthermore, these and some other packer-related features are macro’ed into the project when it compiles to generate special byte sequences that the packer can find to distinguish what it is allowed to do and where. That is, if the packer is allowed to modify some part of the code, the programmer has to use macros while coding the game to indicate which code it is allowed to modify and how.


Sychotix wrote:To stay on topic... It must be encrypted then. Age of conan does something similar with their mana/hp/stamina. It is behind and encryption method of x*100 and then it rounds up. For example, the value could be 123412 and your mana is 1235. It could be 123401 and your mana is still 1235. Now if it is 123400, your mana is 1234. Make sense?

This is not encryption. It is a newbie implementation of fixed-point decimals. It allows them to transparently keep track of your mana to a degree of 1/100th of a unit, which allows them to give you, for example, 0.5 mana points. This is done behind the scenes without the player knowing, but it is an important feature in many cases because it decreases rounding errors.
If they gave you 0.5 mana points twice but they only track your mana by units of one, you would have 1234 + 0.5 + 0.5 = 1234 (rounded down due to lack of precision). Whereas 123400 + 50 + 50 = 123500.

This is a newbie/simplified implementation. The correct implementation uses shifting of bits, not multiplication and division (due to speed). For example, on Nintendo DS, 1.0 equals 0x1000 (1 << 12). 1.5 equals 0x1800, etc. This gives them an accuracy of 1/4096th of a unit.


L. Spiro


thanks, i understand fix point decimals but my question is, if ive never seen this thread, how will i know that the number is being represented in this way (3500 is in fixed point decimal rather than say unsigned long)? if they had juggled around with these numbers a bit more would we still be able to find these numbers? i apologize if these are newb questions.

PostPosted: Thu Jun 04, 2009 6:48 am
by L. Spiro
When you start off hacking a game you are not going to have any clue how they store what.

Health may be a decimal from 0 to 100 (Doom 3). Maybe it is a float from 0.0f to 1.0f (Perfect Dark/GoldenEye 007). Maybe it is a fixed-point number from 0000.0000 to 0001.0000.

It doesn’t matter what game it is or what format they use; you always start off not knowing the format and just taking guesses until you get it right.
For each failed search you generalize your search parameters even more. And again this is something you automatically do regardless of the format of their data.


With fixed-point data, you are likely going to fail several search attempts until you end of resorting to “Unknown” followed by “Decreased” and “Increased” until you find a number that, although strangely displayed, followed your health up and down.


When you notice the number is always “health × some number”, you have just realized that the value is fixed-point.



If they juggle around with the numbers a bit more (what does that mean?) then you will just find it later rather than sooner.
But there are only 3 formats games are ever going to use: Decimal, floating-point, and fixed-point.


L. Spiro

PostPosted: Tue Jun 16, 2009 1:24 am
by tkbnj
thanks, that last post made a lot of sense

has anyone tried this successfully in 1.23? I keep running into that linked list loop. can you guys explain how you got around that again? i have tried josse's method with not much success.

PostPosted: Wed Sep 23, 2009 4:57 am
by toffey
Thank you so much for this tutorial. I've read it over plenty of times, but was constantly confused by the EAX and EDX you used. After reading through the thread again and your post at the top of this page I finally understand what you did.

This should prove quite useful, thanks WhiteHat! (And L. Spiro, and everyone else who has helped out on these forums)

PostPosted: Sat Oct 03, 2009 8:59 pm
by WhiteHat
WarCraft 3 version 1.24.1.6374, that is patch 1.24b English...

Code: Select all
Complex Addreses for GOLD:
============================================================================
Player #01 (Red)        : [[[0x6FACE5E0]+0xC]+(0x002*0x8)+0x4]+0x78
Player #02 (Blue)       : [[[0x6FACE5E0]+0xC]+(0x02A*0x8)+0x4]+0x78
Player #03 (Aquamarine) : [[[0x6FACE5E0]+0xC]+(0x052*0x8)+0x4]+0x78
Player #04 (Purple)     : [[[0x6FACE5E0]+0xC]+(0x07A*0x8)+0x4]+0x78
Player #05 (Yellow)     : [[[0x6FACE5E0]+0xC]+(0x0A2*0x8)+0x4]+0x78
Player #06 (Orange)     : [[[0x6FACE5E0]+0xC]+(0x0CA*0x8)+0x4]+0x78
Player #07 (Green)      : [[[0x6FACE5E0]+0xC]+(0x0F2*0x8)+0x4]+0x78
Player #08 (Pink)       : [[[0x6FACE5E0]+0xC]+(0x11A*0x8)+0x4]+0x78
Player #09 (Grey)       : [[[0x6FACE5E0]+0xC]+(0x142*0x8)+0x4]+0x78
Player #10 (Cyan)       : [[[0x6FACE5E0]+0xC]+(0x16A*0x8)+0x4]+0x78
Player #11 (Dark Green) : [[[0x6FACE5E0]+0xC]+(0x192*0x8)+0x4]+0x78
Player #12 (Brown)      : [[[0x6FACE5E0]+0xC]+(0x1BA*0x8)+0x4]+0x78
============================================================================


Still the same, modified the static base pointer address, only this time MHS unable to read modul names in my PC...