Where to start learning

[thebillkidy]

But really.... 3D is is being transferred by a stupid Orientation and using the 3 axises..... i know how OpenGL works, i know how the vector works i did a stupid distance calculation why the **** would i care about 3D to 2D if i ask on how to READ MEMORY? -.- Come on i asked about the memory and i get about 3D that is just basis... i made a ****ing triangulation calculation to find the shortest path, i made path findings, collision algorithms i don't give a damn **** on that i just want to know how i read memory on a special offset.

[BitHacker]

thebillkidy,

i just want to know how i read memory on a special offset.

tempOlit:

template<typename _ret_t> _ret_t ReadMemory(char Caption[], int long Address)
{
    DWORD PROC_ID;
    HANDLE PROC_HANDLE;
    _ret_t ret;
    GetWindowThreadProcessId(FindWindow(NULL, (LPCTSTR)Caption), &PROC_ID);
    PROC_HANDLE = OpenProcess(PROCESS_ALL_ACCESS, false, PROC_ID);
    ReadProcessMemory(PROC_HANDLE, (void*)Address, &ret, sizeof(_ret_t), NULL);
    CloseHandle(PROC_HANDLE);
    return Value;
}

usage:

std::cout << "Byte at 0x403000: 0x" << std::hex << (int)ReadMemory<unsigned char>("test", 0x403000) << std::endl;

return:

Byte at 0x403000: 0x58

You should be ale to come up with your own WRITEPROCESSMEMORY TEMPLATE NOW.... :P

If you can't figure out how to read multiple bytes with this template go read a c++ book. I'm tired of helping people that don't listen...

You need to go learn math first.

-Bit_Hacker

[TKG]

I actually got the same problem as HellFall :P i don't know how you guys can find out the value that is bound to a offset, does anybody got some code preview or anything?

You can try CE pointer scan, which sometimes gives you acceptable results. Otherwise :
- read this forum and understand ACD / Actor / Attributes and their dependencies
- or find the HP with CE and reverse the code which accesses this memory, mostly the offsets from static addresses are easy to find inside 1-2 levels

And above all: dont feed the Trolls ...

[RamirezX]

I'm tired of helping people that don't listen...

You need to go learn math first.

-Bit_Hacker

Heh, who told you have to help people?
And wtf how depends memory reading on math?

If you're so tired, stfup and go to learn hack ..

[BitHacker]

RamirezX,

LMAO @ go learn to hack....


You need to learn to code.. Lets see your code? Thats right... YOU DON'T HAVE ANY....

-Bit_Hacker

[who knows]

Thanks for the info BitHacker, I've been coding for a couple years now but I haven't done anything like what you're talking about, nor do I know calculus (even Calc 1!) I suppose I better crack open some math books.

But I personally learned a few languages without requiring anything really math-intensive (aside from I suppose basic Algebra equations for iterations) but I don't consider myself very knowledgeable either. (First couple of years of CS - I'm sure its baby steps in the grand perspective)

But at least from what I've seen coding and math go hand in hand, but I haven't hit a brick wall of my coding skills vs. my math knowledge quite yet.

[Cypher]

thebillkidy,



tempOlit:

template<typename _ret_t> _ret_t ReadMemory(char Caption[], int long Address)
{
    DWORD PROC_ID;
    HANDLE PROC_HANDLE;
    _ret_t ret;
    GetWindowThreadProcessId(FindWindow(NULL, (LPCTSTR)Caption), &PROC_ID);
    PROC_HANDLE = OpenProcess(PROCESS_ALL_ACCESS, false, PROC_ID);
    ReadProcessMemory(PROC_HANDLE, (void*)Address, &ret, sizeof(_ret_t), NULL);
    CloseHandle(PROC_HANDLE);
    return Value;
}

If you can't figure out how to read multiple bytes with this template go read a c++ book. I'm tired of helping people that don't listen...

You need to go learn math first.

-Bit_Hacker

Come on mate, haven't we talked about this?

You're a little harsh for someone writing such awful code.

Bug 1:
I cite section 17.4.3.2.1 of the C++ (03) Standard:

Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.165

Bug 2:
You're casting a char* to a TCHAR* then calling a wchar_t* API. Good luck getting that to work with Unicode. Even trying to use that code on a target as common as Battlefield 3 will fail because the window for BF3 contains a Unicode character afaik (U+2122 I believe).

Bug 3:
You're casting a 'long' to a 'void*'. A 'long' is 32-bits even under x64 on Windows. Stop using integer types to hold pointers, unless they're explicitly memsize types (e.g. ULONG_PTR). <-- Maybe you should learn math? sizeof(void*) != sizeof(long) (It may be on some platforms but that's not something you can rely on. We have memsize types for a reason).

Bug 4:
Make sure that your template is being called with arguments that make sense (i.e. a POD type). Consider what happens if someone calls your function with a type like:
std::vector<int>. Surely that's a mistake (and one that can be trivially detected at compile time through TMP or static_assert).

Bug 5:
I'm assuming now that you haven't actually tried to compile this code, as you're returning a non-existent variable 'Value'.

Defensive Programming 1:
Check your damn API return values. You currently check none of them.
Btw, your call to CloseHandle could raise an exception in debug mode because you don't check whether the handle returned from OpenProcess is valid, so even if the other functions will fail semi-gracefully, CloseHandle will not.

Defensive Programming 2:
You don't need PROCESS_ALL_ACCESS just to read memory. Request only what you need. This not only helps you obtain a handle to processes where you might be limited in access (and requesting unnecessary privileges will result in a denial), but it also improves the safety of your code in the event of a vulnerability by limiting the attack surface area (not really relevant in this particular case, but it's a good habit to get into).

Style 1:
WHY_ARE_YOU_NAMING_VARIABLES_LIKE_THIS? Pretty much all C++ coding style 'guidelines' (for all the major libraries, companies, etc) reserve such identifiers for macros (and often also enumerations).

Style 2:
Stop declaring your variables at the top of the function. You don't even have to do that in C any more.
Don't do this:
int i;
i = foo();
Do this:
int i = foo();
Also limit the scope of your variables to where they actually need to be visible, this is especially important when dealing with more complex types which hold resources or have other non-trivial operations in their destructor.

Misc 1:
Not sure whether this should be considered a 'bug' or a 'style' issue or something else..
Anyway, if you're working under Windows you should be working with wide strings at API boundaries. If you wish to maintain a narrow string interface for your APIs that's fine, but they should be UTF-8 encoded to avoid data-loss, and you should convert to UTF-16 at points where you call into the Windows API.
Furthermore, why are you taking a char[]? First off, if you're taking a char[] that you do not wish to mutate, you should be taking it as char const[], but I digress... I think you mean: 'char const* const' (the last 'const' is optional, but again, good habit). As I've already said though, that's wrong, and you want to use a wchar_t.
Personally I'd use the C++ string types (std::string/std::wstring), then if you're super-worried about efficiency then implement the code in terms of your ptr-to-char and provide a C++ string overload that forwards to it. Makes your API less cumbersome to use, while retaining the efficiency.

Maybe you should read a C++ book too. (Or maybe you can just calm down a bit until you're in a position to actually give constructive advice.)

P.S. Some of the above can be excused given it's obviously just for exposition, but the really nasty bugs can not. Come on, it's all obvious just from looking at. Heck, I probably even missed one (or more), but I'm over it.

Trolololol.

[swooshy]

Cypher you are missing something. It is not his code it is 1:1 copy & pasted from Reading memory in C++ - C++ Forum ....


edit: here the link to the exact post of his code: http://www.cplusplus.com/forum/general/42132/#msg227701

[Cypher]

Cypher you are missing something. It is not his code it is 1:1 copy & pasted from Reading memory in C++ - C++ Forum ....

Interesting, there was no mention of that anywhere that I can see... (Am I missing something? It is 4AM...)

Leaving the post up though because my snide remarks in response to his snide remarks still stand. (Anyone familiar with C++ would know not to use such a cluster**** as an example of how to actually do anything in C++.)

[BitHacker]

Cypher,

Nice information very informative. I already know by your libraries and code you are will over my years ... I always appreciate nice references like this:

I cite section 17.4.3.2.1 of the C++ (03) Standard:
Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.165

Can you supply me a link?

-Bit_Hacker

[vegasmoney]

BitHacker, you really know how to derail this guy's thread. If he wanted to make a bot with a nav system, then ya you'd be giving good advice. But really, read his initial post again and you will see how everyone else is viewing your posts.

[who knows]

Interesting, there was no mention of that anywhere that I can see... (Am I missing something? It is 4AM...)

Leaving the post up though because my snide remarks in response to his snide remarks still stand. (Anyone familiar with C++ would know not to use such a cluster**** as an example of how to actually do anything in C++.)

Your breakdown of his post was interesting. I only went through half a C++ book in my experience, so I'm very novice to it. But this:

Style 2:
Stop declaring your variables at the top of the function. You don't even have to do that in C any more.
Don't do this:
int i;
i = foo();
Do this:
int i = foo();
Also limit the scope of your variables to where they actually need to be visible, this is especially important when dealing with more complex types which hold resources or have other non-trivial operations in their destructor.

I had asked my C++ professor at the time (Just a year or so ago) about declaring variables inside of functions and he had told me that its better to declare them at the top of a function (below the name & parameters) for clarity and readability and that putting it inside at different points within a function is against readability, and that at compile time the memory was reserved for those variables anyway; regardless of what particular line they were written on. He could have been wrong, and I'm not personally knowledgeable enough to know the true answer, but your statement proves contrary and I'd just like to know more about this particular thing. Thanks Though you say thats not the case with C anymore, and the guy was older...

Also why is it bad style to have Declarations then assignments, I've always found it easier personally, is it a standard practice or just your personal preference, or does it take more resources to declare then assign as opposed to declaration and assignment at the same time?

[Beaving]

Just a quote from Google's C++ style guide:

"
If you are editing code, take a few minutes to look at the code around you and determine its style. If they use spaces around their if clauses, you should, too. If their comments have little boxes of stars around them, make your comments have little boxes of stars around them too.

The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you are saying, rather than on how you are saying it. We present global style rules here so people know the vocabulary. But local style is also important. If code you add to a file looks drastically different from the existing code around it, the discontinuity throws readers out of their rhythm when they go to read it. Try to avoid this.
"

http://google-styleguide.googlecode....k/cppguide.xml

[RamirezX]

RamirezX,

LMAO @ go learn to hack....


You need to learn to code.. Lets see your code? Thats right... YOU DON'T HAVE ANY....

-Bit_Hacker

OK .. but show _YOUR_ code first ;-) Means YOUR, YOU create it .. not copy&paste from tutorials on another forum like Endscene hooking ... lmao, as you like to say ...

[_Mike]

I had asked my C++ professor at the time (Just a year or so ago) about declaring variables inside of functions and he had told me that its better to declare them at the top of a function (below the name & parameters) for clarity and readability and that putting it inside at different points within a function is against readability, and that at compile time the memory was reserved for those variables anyway; regardless of what particular line they were written on. He could have been wrong, and I'm not personally knowledgeable enough to know the true answer, but your statement proves contrary and I'd just like to know more about this particular thing. Thanks Though you say thats not the case with C anymore, and the guy was older...

Also why is it bad style to have Declarations then assignments, I've always found it easier personally, is it a standard practice or just your personal preference, or does it take more resources to declare then assign as opposed to declaration and assignment at the same time?

For me, declaring variables as close to their point of use increases clarity, not decreases it. But that's a quality of life issue really. What's more important how it affects the software.
For PoD types it's fine to do the declare/assign in separate statements (although I still agree with limiting the scope of them), but think about what happens with classes and structs.

std::string str;
str = "string";
...
std::string str("string");

Those two code snippets are equal right? Actually they aren't. The end result is the same, but how you get there is different(*). The first one first constructs an empty string by calling the default constructor and then calls the assignment operator for char*. A totally unnecessary operation compared to the 2nd one which directly calls the char* constructor.
The extra overhead might be trivial in the case of an std::string object, but for more complex ones it could be quite large.

*) An optimizing compiler might be able to "fix" the first one, but it's not something you should depend on.


Edit/Update:

Bug 3:
You're casting a 'long' to a 'void*'. A 'long' is 32-bits even under x64 on Windows. Stop using integer types to hold pointers, unless they're explicitly memsize types (e.g. ULONG_PTR). <-- Maybe you should learn math? sizeof(void*) != sizeof(long) (It may be on some platforms but that's not something you can rely on. We have memsize types for a reason).

And to add to this, the conversion would be sign extended..