Hello, I am trying to make small plugin for simba with visual studio 2015 c++ part.
When I build it in 32bit mode it loads normaly but in 64bit build it says, "plugin name" "32" not found. Why?
Hello, I am trying to make small plugin for simba with visual studio 2015 c++ part.
When I build it in 32bit mode it loads normaly but in 64bit build it says, "plugin name" "32" not found. Why?
You can't load a 64bit plugin in a 32bit Simba.
Thanks. But now I have new question.
Code is like this:
ReadProcessMemory returns error 299 and value is 0 :ICode:int value = NULL; if (HProc == NULL) { cout << ("Hardware handle zero!\n"); } else { ReadProcessMemory(HProc, (LPCVOID)0x2468870B3B0, &value, sizeof(value), 0); cout << "Value: " << value << "\n"; cout << GetLastError() << "\n"; Sleep(1000); } return NULL; }
I dont understand it should work! Trying to get 64bit addresses values.
PID is correct,from taskmanager. Handle should be also, its not zero at least.
Simba is 64 bit process and plugin is 64 bit compiled.
Thanks. It worked.
But now I have base address and 3 offsets! From cheat engine. How do I add those offsets?
What do you mean by offsets?
If you mean offsets as in offset to a memory location, you have to just add them to the base address and re-read the memory, not exactly sure why you're doing that unless value is a pointer and you wanna add the offset to the pointer you grabbed at 0x2468870B3B0?
Last edited by Kasi; 09-05-2016 at 03:58 AM.
Use offset_ptr OR take the base address as std::intptr_t and the offset as the same.. add them and then reinterpret_cast them back to void pointer. Can also cast the offset to char pointer and the base address to char pointer and add them.
Also beware.. if you made the memory read/write, don't forget to restore the original flags when you're finished with that sector.
Last edited by Brandon; 09-05-2016 at 01:25 PM.
I am Ggzz..
Hackintosher
Yes, so much if I understand it, it is baseaddress+offset=pointer? After searching around on internets I found this forum post:http://guidedhacking.com/showthread....-Level-Pointer
If get home ill try it(That FindDmaAddy code piece).
Thanks Brandon for your input, you know coding
test.png
I am so confused, how do I get to the top address.
Does it get right module ... thing? How do I add it to the base and offsets?
Code:intptr_t ptr = 0x22143252040; intptr_t hackOffset1 = 0x320; intptr_t hackOffset2 = 0x70; intptr_t hackOffset3 = 0x748; intptr_t client = 0; client = GetModuleBaseAddress(Pid, L"rs2client.exe"); cout << "client" << (void*)client << "/n"; intptr_t SummPointer = ptr + hackOffset1 + hackOffset2 + hackOffset3;Code:DWORD GetModuleBaseAddress(DWORD processId, TCHAR *szModuleName) { DWORD moduleBase = 0; HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE | TH32CS_SNAPMODULE32, processId); if (hSnapshot != INVALID_HANDLE_VALUE) { MODULEENTRY32 moduleEntry; moduleEntry.dwSize = sizeof(MODULEENTRY32); if (Module32First(hSnapshot, &moduleEntry)) { do { if (wcscmp(moduleEntry.szModule, szModuleName) == 0) { moduleBase = (DWORD)moduleEntry.modBaseAddr; break; } } while (Module32Next(hSnapshot, &moduleEntry)); } CloseHandle(hSnapshot); } return moduleBase; }
I don't get what you're confused about.. That picture is 100% wrong. You need to add the address + offsets bottom up to get the top address.. but it's addition so it won't matter the order.
C++ Code:#include <iostream>
#include <cstdint>
int main() {
std::intptr_t base = 0x22143252040;
int offset1 = 0x748;
int offset2 = 0x40;
int offset3 = 0x320;
std::intptr_t address = base + offset1 + offset2 + offset3;
std::cout<<std::hex<<address<<std::endl;
return 0;
}
No difference..
You can see here:
that if you do: 0x34880F0 + 0x118 = 0x3488208.
Likewise from your picture, it should be:
0x22143252040 + 0x748 = 0x22143252788.
Can even do it in Google. There is absolutely no way that your CheatEngine picture is correct.
Last edited by Brandon; 09-07-2016 at 01:07 AM.
I am Ggzz..
Hackintosher
That probably just means one address pointing to an address, which in turn points to another one and so forth, until eventually the address that is being pointed at in the trainwagon is the information you are looking for (be it an integer or string or whatever).
Feel free to ask me any questions, I will do my best to answer them!
Previously known as YouPee.
Odd after runescapes update pointers appoint to nothing. Yet they worked 100% every time 2 weeks ago.
Where does it pull that base address?
Attachment 27824
"rs2client.exe"+00886628 <-this. Where does it come from? Every run results different base address, yet somehow points to correct value. What mathematics are behind it? Black magic!?
because "rs2client.exe"+00886628 probably points to another address, which might point to the correct one.
Feel free to ask me any questions, I will do my best to answer them!
Previously known as YouPee.
Isn't using direct pointers generally a poor idea because the jvm has the ability to shuffle things around in memory?
Yes, although iirc the NXT client doesn't shuffle around stuff other than the base address, which in this case is "rs2client.exe". This makes it easy to bot stuff with memory reading on nxt client. I wrote a plugin for simba (more or less slacky did it through helping) which would allow botting with memory reading on nxt, pointer offsets would only have to be updated after next rs3 update. According to someone on IRC though this is only a temporary thing, as they are still developing the NXT client and have left it open for now
Feel free to ask me any questions, I will do my best to answer them!
Previously known as YouPee.
Ok after digging deeper. I found that thing is "Get Module Base External". I allready have it in GetModuleBaseAddress function. It even returns something.
7FF7774B0000 seem to be point where rs2client.exe starts, its kinda big number?
So from cheat engine:
I think base address should be 7FF7774B0000+855C18 ?
But this cant be right, cheat engine shows that it points to ->21f678da048. 7FF7774B0000 is much bigger number than this
'rs2client.exe' (base address) = 7FF7774B0000.
offset = 855C18.
Base address + offset points to 21f678da048.
I would assume 21f678da048 is another address, or that is the value you are looking for. Either of those or you have done something wrong.
Feel free to ask me any questions, I will do my best to answer them!
Previously known as YouPee.
Yea but hex value 7FF7774B0000 + another hex value 855C18 equals 7FF77D05C18 not 21f678da048
The address is 7FF77D05C18.
the value stored in the memory address 7FF77D05C18, is 21f678da048.
I'll try to make this simpler for you @alar82;
Say you have a file cabinet. Each drawer in the cabinet has its unique label. One drawer has the label "123". When you open drawer "123" in the file cabinet you find a little note that says "abc".
Now think of the labels as addresses. When you read the value stored in the memory address "123" you get the value "abc". Now abc could either be what you are looking for, or it could be a pointer to the next memory address. If it is a pointer to the next memory address you will have to open the drawer "abc", and you might find another little note, and maybe so forth.
This oversimplification obviously doesn't take into consideration offsets, but that's just the same thing with a bit of addition included.
So in your case you would open the drawer "7FF7774B0000 (+ 855C18)" in which you would find a note that says "21f678da048". As you said yourself, 21f678da048 is not the sum you get when adding 7FF7774B0000 with 855C18, it is infact the value stored in the memory address when adding 7FF7774B0000 with 855C18.
I hope this bastardization will help you grasp the concept a little better.
Last edited by Joopi; 09-30-2016 at 02:14 PM.
Feel free to ask me any questions, I will do my best to answer them!
Previously known as YouPee.
Can someone help me with blackbone library. Ill try to use its functions to read external memory, problem is it returns only some mess, wrong values.
Windows native ReadProcessMemory works. proc.core().handle(); for handle works fine. So it is right process.Code:DWORD VirtPRead2(DWORD64 address) { DWORD buffer; PVOID buf; proc.Attach(procIDs.front()); if (address == NULL) { cout << ("zero!\n"); } else { cout<< "true=?: " <<proc.core().isWow64(); proc.remote().memory().Read( address, sizeof(DWORD), buf); buffer = (DWORD)buf; return buffer; } return 0; }
isWow64 returns 0, I think that it should be 1?
Never used Blackbone.
If the application is 64 then it would be 1. If is is 32bit then it would be 0. Assuming you're working on RS; RS is 32bit. So 0 is correct.
Don't you have to allocate space for the buffer?
But rs nxt is 64bit and simba is 64bit and dll is 64bit, but maybe I am doing something wrong that causes this.
Buffer is that buf and then converted to dword but no data loss there.
Anyway today I found something bit funny. If you put into cheat engine text search Xbox, you will find in nxt: "In the New Client you can use an Xbox compatible controller"
There are currently 1 users browsing this thread. (0 members and 1 guests)