Idea: RoMbot + MultiHack (keypress collaboration)
Re: Idea: RoMbot + MultiHack (keypress collaboration)
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.
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
- Site Admin
- Posts: 5313
- Joined: Sat Jan 05, 2008 4:21 pm
Re: Idea: RoMbot + MultiHack (keypress collaboration)
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?
Re: Idea: RoMbot + MultiHack (keypress collaboration)
The latest revision 584 can move in 3 dimensions now so you should be able to use it with your fly hack.
Enjoy.
Enjoy.
- Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
- I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
- How to: copy and paste in micromacro
________________________
Quote:- “They say hard work never hurt anybody, but I figure, why take the chance.”
- Ronald Reagan
Re: Idea: RoMbot + MultiHack (keypress collaboration)
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:
my code for wallhack:
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
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
- Site Admin
- Posts: 5313
- Joined: Sat Jan 05, 2008 4:21 pm
Re: Idea: RoMbot + MultiHack (keypress collaboration)
I've changed the templates for memoryWrite* and memoryWrite*Ptr. Try using the attached executable.
- Attachments
-
- micromacro1.01.experimental.zip
- (253 KiB) Downloaded 323 times
Re: Idea: RoMbot + MultiHack (keypress collaboration)
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.
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.
- Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
- I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
- How to: copy and paste in micromacro
________________________
Quote:- “They say hard work never hurt anybody, but I figure, why take the chance.”
- Ronald Reagan
Re: Idea: RoMbot + MultiHack (keypress collaboration)
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.
I'll give it a try (experimental download), and write what happens. Thanks.
Re: Idea: RoMbot + MultiHack (keypress collaboration)
Application cannot start - missing alut.dll file?Administrator wrote:I've changed the templates for memoryWrite* and memoryWrite*Ptr. Try using the attached executable.
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
- Site Admin
- Posts: 5313
- Joined: Sat Jan 05, 2008 4:21 pm
Re: Idea: RoMbot + MultiHack (keypress collaboration)
Here's the missing files. This is an experimental version with added functionality, hence the addition of OpenAL DLLs.
- Attachments
-
- oal.dependencies.zip
- (61.88 KiB) Downloaded 322 times
Re: Idea: RoMbot + MultiHack (keypress collaboration)
Yes, works perfectly.
Thank you! Uploading working and tested wallhack...
Thank you! Uploading working and tested wallhack...
Re: Idea: RoMbot + MultiHack (keypress collaboration)
What's the added functionallity? Anything interesting?Administrator wrote:This is an experimental version with added functionality
- Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
- I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
- How to: copy and paste in micromacro
________________________
Quote:- “They say hard work never hurt anybody, but I figure, why take the chance.”
- Ronald Reagan
- Administrator
- Site Admin
- Posts: 5313
- Joined: Sat Jan 05, 2008 4:21 pm
Re: Idea: RoMbot + MultiHack (keypress collaboration)
Just stuff you already know about, such as the sound support and window flashing.rock5 wrote:What's the added functionallity? Anything interesting?Administrator wrote:This is an experimental version with added functionality
Re: Idea: RoMbot + MultiHack (keypress collaboration)
UPDATED Speedhack addon! 20.03.2011.
Please download newest file from 1st post in this topic.
Please download newest file from 1st post in this topic.
Re: Idea: RoMbot + MultiHack (keypress collaboration)
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.
Re: Idea: RoMbot + MultiHack (keypress collaboration)
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
---------
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
---------
Re: Idea: RoMbot + MultiHack (keypress collaboration)
I try to build a hex/value table. Thank you for your values.
Re: Idea: RoMbot + MultiHack (keypress collaboration)
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.
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.
Re: Idea: RoMbot + MultiHack (keypress collaboration)
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
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
Re: Idea: RoMbot + MultiHack (keypress collaboration)
I don't think it'll work that way.
Try this:
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.
Try this:
Code: Select all
local staticcharbase_address = 0x9BC394;
offsetsx = {0x598, 0x42};
local curspeed = memoryReadBytePtr(getProc(), staticcharbase_address, offsetsx);
printf("Speed: %d\n", curspeed);
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.
Re: Idea: RoMbot + MultiHack (keypress collaboration)
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.
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.
Who is online
Users browsing this forum: No registered users and 5 guests