Idea: RoMbot + MultiHack (keypress collaboration)

[Tsutomu]

Sorry that doesn't help, you didn't read my post well. I'm writing memory ok, but this specific address is write protected, need to set flag to READ_WRITE instead of readonly and neither of functions from the link doesn't do that (been through them couple of times thinking i might have missed one that has the ability but not actually)

Any workaround? Idea?
Could it be implemented? I would try wrapping it for micromacro if you have no time just tell me where to search as i suck at Lua. :/

Thanks.

[Administrator]

The openProcess() function opens with debugging permissions, which means it should be able to do 'everything'. Are you sure that it's succeeding? What OS are you using? Can you post a copy of log.txt?

[rock5]

The latest revision 584 can move in 3 dimensions now so you should be able to use it with your fly hack.

Enjoy.

[Tsutomu]

Yes Rock, Thx i saw that great feature !!!

This is for the wallclimb hack, and the issue is when i use the command memorywriteFloat it returns false, script continues working no error, but this issue i saw on other implementations in cpp.

So the command is not succeeding, i figgure because of the readonly flag for this address in the mem, at least other people implementing this hack have had troubles because of that, and solved it with:
VirtualProtectEx(opClient, (void *) 0x0091D3B4, 4, PAGE_READWRITE, &oldData); in C.
Now i'm not sure about if they have opened process with debug flag, but i see they open with PROCESS_ALL_ACCESS and i asked 1 programmer whyt happened before he changed address flag to readwrite and he said it haven't been succeeding of writing a value to the address, returned FALSE. Just what's happening to me. I can post my code here but i doubt there's smthng wrong with that as only some addresses-offsets are changed from other addon-userfunct which works fine.

So this is how it's done in C:

Code: Select all

GetWindowThreadProcessId(rClient, &processID); //Get the process ID from the HWND and assign it to our "processID" variable.
   opClient = OpenProcess(PROCESS_ALL_ACCESS, 0, processID); //Open the process and assign it to our "opClient" handle.
   VirtualProtectEx(opClient, (void *) 0x0091D3B4, 4, PAGE_READWRITE, &oldData); //This address is protected from modification, let's fix that.
   WriteProcessMemory(opClient, (void *) 0x0091D3B4, &whVal, 4, 0); //Write the new value
   VirtualProtectEx(opClient, (void *) 0x0091D3B4, 4, oldData, &oldData); //Restore the protection

my code for wallhack:

Code: Select all

--0x96ADCC <<-- ADDRESS
local wallhack_addr = 0x96ADCC;
local whacked = 0.2; --default hack value (set from 0.1 to 3.9)
--value of 0.2 works just fine but 0.1 climbs everywhere (90 degrees) so you might need it somewhere
local wnormal = 4; --unhack, wnormal used to revert the hack back to no climb

function memoryfreezewall()
	wh = memoryReadFloat( getProc(), wallhack_addr);
  printf("wHACK VAL [%d]\n",wh);
	if (memoryWriteFloat(getProc(), wallhack_addr, whacked)==false) then printf("failed writing mem"); end
	wh = memoryReadFloat( getProc(), wallhack_addr);
  printf("wHACK VAL [%d]\n",wh);
end

function wallon()
	registerTimer("wallTimer", 100, memoryfreezewall);
	printf("Wallhack ACTIVATED!\n");
end

function walloff()
	unregisterTimer("wallTimer");
	memoryWriteFloatPtr(getProc(), wallhack_addr, wnormal);
	printf("Wallhack DEactivated.\n");
end

[Administrator]

I've changed the templates for memoryWrite* and memoryWrite*Ptr. Try using the attached executable.

[rock5]

I've been able to confirm
memoryWriteFloat(getProc(), 0x96ADCC, 2)
doesn't work and returns 'false'.

Although, I was able to change it with Cheat Engine.

I didn't try that download.

[Tsutomu]

Yes, cheat engine works for it, probably uses READ_WRITE flag by default for any changes it makes.

I'll give it a try (experimental download), and write what happens. Thanks.

[Tsutomu]

I've changed the templates for memoryWrite* and memoryWrite*Ptr. Try using the attached executable.

Application cannot start - missing alut.dll file?

When i DL alut.dll ver: 5.10.2914.0 it says cannot find procedure entry point for AlutCreateBufferFromFile in file alut.dll.

Why is this alut added in this version it's openAl file?

[Administrator]

Here's the missing files. This is an experimental version with added functionality, hence the addition of OpenAL DLLs.

[Tsutomu]

Yes, works perfectly.

Thank you! Uploading working and tested wallhack...

[rock5]

This is an experimental version with added functionality

What's the added functionallity? Anything interesting?

[Administrator]

This is an experimental version with added functionality

What's the added functionallity? Anything interesting?

Just stuff you already know about, such as the sound support and window flashing.

[Tsutomu]

UPDATED Speedhack addon! 20.03.2011.
Please download newest file from 1st post in this topic.

[MinMax]

How did you read out the "real" speed ( 50..59.. ) and the percent of gain ? I am testing a littlebit your addon, and i want to check ingame the actually speed. To read out the HEX/DEZ values are not really helpfull for this.

[Tsutomu]

No other way then CE - Cheat Engine, but you can't actually read 50 - 59 there as they didn't store it like that, you need to read it in HEX sry. You have in my addon file addresses so get to the address and use this:
HEX : VALUE
6F : 60 (you'll have pullbacks if you go higher than 59 most likely)
6A : 59
66 : 58
62 : 57
5F : 56
5A : 55
56 : 54
52 : 53
4F : 52
4A : 51
46 : 50
---------

[MinMax]

I try to build a hex/value table. Thank you for your values.

[Tsutomu]

It may be that it's going with 3 steps up :/
Like: 46,4A,4E,52,56,5A,5E,62,66,6A,6E - i think it's actually like this
as i wrot prrevious much too quickly.
Just test if value 5E or 5F works good or breaks the client or stops your char disables moving and you'll know which is good table.

[MinMax]

Now i take this for checking the speed:

function speedinfo()
local playerAddress = memoryReadIntPtr(getProc(), addresses.staticbase_char, addresses.charPtr_offset);
local checkspeed = memoryReadFloat(getProc(), playerAddress + 0x40);
setTextColor(cli.red);
printf("Speed : "..checkspeed.."\n");
end

[Tsutomu]

I don't think it'll work that way.
Try this:

Code: Select all

local staticcharbase_address = 0x9BC394;
offsetsx = {0x598, 0x42};
local curspeed = memoryReadBytePtr(getProc(), staticcharbase_address, offsetsx);
printf("Speed: %d\n", curspeed);

This works with int values made from those tables i gave you.
Use windows scientific calculator to get int values to hex and vice versa.

For.ex. 46 HEX = 70 INT (50 speed) you will have 70 in your curspeed var.
Also.... 6A HEX = 106 INT (59 speed) you will have 106 in curspeed var.

Apply this for entire table, i don't actuallly know the way they calculate this as this is taken by testing this offset value in CheatEngine using Multihack from RoMeo.

You can use that too, to determine values you need.

[Tsutomu]

Okay i have nothing to do so i'll explain it better for you just in case u need.

Game stores the variable in address that we reach from 0x9BC394;
by offsets 0x598 and 0x40

It's 4 byte variable but game only uses a byte at offset 0x42 so i don't change other bytes 0x40, 0x41 and 0x43 as i don't know what game does with it, it doesn't change those when speed is changed. We could also change all four and use the offset 0x40 as in romeo multihack but it's not needed as it's tested and working only changing this byte.

So the value that is stored there is a single BYTE which goes from 70 (for nominal speed 50) to 106 (for speed of 59 - increased 18%). We can change it more but we'll get pullbacks.

So we use memoryreadbyte and memorywritebyte command to read the INT value from memory on the offset 0x42 - 1 byte.
We get value 70 before hack is used. Afterwards we will have value 106.
A minus and a plus don't matter - is it signed or unsigned so don't worryy if you get -70 for ex. It's the absolute that counts.
I think that pattern for increasing the speed values is here (the key i found is seeable in HEX)
42,46,4A,4E,52,56,5A,5E,62,66,6A,6E
See the pattern?
49,50,51,52,53,54,55,56,57,58,59,60
x2,x6,xA,xE,y2,y6,yA,yE,z2,z6,zA,zE
so i figgure after 6E it goes like: 72,76,7A,7E,82,86,8A,8E. That would be speed from 61-68.
The values we write and read from memory are INT instead of HEX we are seeing in table (the only reason we are using hex in tables is we can find a pattern by it) and can be converted through sci calc in windows.
I said that 46 HEX = 70 INT = speed 50 NORMAL
Also........ 6A HEX = 106 INT = speed 59 +18% (hacked)
We will write in memory on offset 0x42 NOT 0x40 -> value 106 to make our player run faster.
For ex. 82 HEX is 130 INT (that would give us a speed of 65) but will pull us back a lot if used constantly.
I hope this helps.