BluralMemory - Memory Manipulating

[MBex]

Hello

This library provides a C++ class which helps you to manipulate another applications memory.

I decided to write this lib because there is no other library for manipulating memory using c++ similar to this one. This library should be an alternative for the BlackMagic lib.

The exported class provides methods for reading and writing of all common data types like int, uint and long. Additionally there are methods for reading and writing ascii and utf8 strings.

Another feature is to send key events to the process.

The latest online documentation could be found here

The subdirectory Examples contains a WoW-Example which shows how to use the lib.

Current Version: 0.3

Download

If you have questions or suggestions, you can post it here or just mailing me to [email protected].

Changelog 0.3

-Added 64bit, 32bit, 16bit specific data types.
-Changed enum namespace from BMTypes to BM
-Made BluralMemory destructor virtual
-Some methods got an std::string as parameter, i changed it to const std::string &
-Added the method readUnicodeString()
-Changed the return value of suspendThread() from uLong to bool
-Added methods readUInt64() and readInt64()
-The method writeUInt64() and writeInt64() now takes a real 64bit data type
-Changed the return value of keyPress() from void to bool
-Modified documentation


Have fun ;-)

[Cypher]

Certainly a strange and interesting design...

One thing I immediately noticed is that you're using BluralMemory as a base class (which is VERY strange design-wise, but okay...), however it has a non-virtual destructor. If you create a derived object on the heap and then delete it using a pointer-to-base the derived destructor(s) will never be called. You might wanna fix that, as it's fairly critical.

A better alternative though imo would simply be to not use BluralMemory as a base class, because it simply doesn't look like it should be one. The API doesn't seem suited to it, for example you have a static function returning a container full of BluralMemory instances, this is totally inappropriate as far as your current design goes though, as even if you change it so that you can use a factory function or something to generate a container of your derived class, they'll just be sliced anyway, you should be using pointers (preferably smart pointers) so the objects can retain their polymorphic status.

As stated here, prefer composition to inheritance (read: BluralMemory should be a member of your 'WoW' class, and your WoW class should just operate on it normally, rather than doing it via inheritance):
C++ Coding Standards

There's some other obvious stuff like a lack of a namespace.

Or this:
BluralMemory(std::string aWindowTitle); // Usually wrong unless you're attempting to elide copies. This is a special case however.
BluralMemory(std::string const& WindowTitle); // Usually correct.

Or this:
bool writeUInt64(void *aAddress, unsigned long aValue); // There is no guarantee 'unsigned long' is a 64-bit datatype (and on most common platforms it isn't)

Or this:
std::wstring readUnicodeString(void *aAddress, ULong aLength); // You provide read versions for somethings but not write? And vice-versa (e.g. WriteUInt64 but no ReadUint64)

etc etc

Another obvious thing is that you often haven't documented what happens when a function fails. Does it throw an exception? Does the program terminate? Does it fail silently? etc

You're on the right track and it's great that the beginners finally have a base to work with in C++, there's just a lot of 'strange' decisions you've made as far as both interface and implementation go.

[flo8464]

I don't get the point why everyone uses functions like write_uint etc
Templates aren't that hard to use. Here a snippet from my library:

template <typename R>
R readMemory(DWORD_PTR address) const
{
	DWORD	bytesRead;
	R       returnedBytes;

	int ec = ReadProcessMemory(	this->processHandle_,
								reinterpret_cast<LPVOID>(address),
								reinterpret_cast<LPVOID>(&returnedBytes),
								sizeof(R),
								&bytesRead
							  );

	if(!ec || bytesRead != sizeof(R))
		throw WinException("ReadProcessMemory()", "readMemory()", GetLastError());

	return returnedBytes;
}

template <typename W>
DWORD writeMemory(DWORD_PTR address, W value) const
{
	DWORD bytesWritten;

	int ec = WriteProcessMemory(	this->processHandle_,
									reinterpret_cast<LPVOID>(address),
									reinterpret_cast<LPVOID>(&value),
									sizeof(W),
									&bytesWritten
								);

	if(!ec || bytesWritten != sizeof(W))
		throw WinException("WriteProcessMemory()", "writeMemory()", GetLastError());

	return bytesWritten;
}

Maybe you wanna use that

[Cypher]

I don't get the point why everyone uses functions like write_uint etc
Templates aren't that hard to use. Here a snippet from my library:

template <typename R>
R readMemory(DWORD_PTR address) const
{
	DWORD	bytesRead;
	R       returnedBytes;

	int ec = ReadProcessMemory(	this->processHandle_,
								reinterpret_cast<LPVOID>(address),
								reinterpret_cast<LPVOID>(&returnedBytes),
								sizeof(R),
								&bytesRead
							  );

	if(!ec || bytesRead != sizeof(R))
		throw WinException("ReadProcessMemory()", "readMemory()", GetLastError());

	return returnedBytes;
}

template <typename W>
DWORD writeMemory(DWORD_PTR address, W value) const
{
	DWORD bytesWritten;

	int ec = WriteProcessMemory(	this->processHandle_,
									reinterpret_cast<LPVOID>(address),
									reinterpret_cast<LPVOID>(&value),
									sizeof(W),
									&bytesWritten
								);

	if(!ec || bytesWritten != sizeof(W))
		throw WinException("WriteProcessMemory()", "writeMemory()", GetLastError());

	return bytesWritten;
}

Maybe you wanna use that

That too would be my approach (well, similar, but a bit different in implementation), however sometimes a non-templated approach is appropriate too (as it stops abuse by retarded users trying to use it with non-POD types and wondering why its not working as expected).

EDIT:

To clarify, I'd probably use TMP and 'type traits' to determine whether a type is POD and enforce it that way, however that's probably a bit 'over the top' for what is designed to be a library for beginners. As soon as you start introducing TMP newbies generally get confused.

An is_pod implementation is provided by boost if you're interested:
http://www.boost.org/doc/libs/1_41_0...ce/is_pod.html

[Cypher]

Here's a quick snippet I whipped together to show my point. When passed a POD type it will compile, when passed a non-POD type it will give you a compiler error.

  template <typename T>
  T Memory::Read(PVOID Address) const 
  {
    return ReadInternal<T>(Address, std::is_pod<T>());
  }

  template <typename T, bool B>
  T Memory::ReadInternal(PVOID Address, std::integral_constant<bool, B> const&) const 
  {
    static_assert(false, "Attempt to use Memory::Read on a non-POD type.");
  }

  template <typename T>
  T Memory::ReadInternal(PVOID Address, std::true_type const&) const 
  {
    T Out = T();
    SIZE_T BytesRead = 0;
    if (!ReadProcessMemory(m_Process.GetHandle(), Address, &Out, sizeof(T), 
      &BytesRead) || BytesRead != sizeof(T))
    {
      DWORD LastError = GetLastError();
      BOOST_THROW_EXCEPTION(MemoryError() << 
        ErrorFunction("Memory:Read") << 
        ErrorString("Could not read process memory.") << 
        ErrorCodeWin(LastError));
    }

    return Out;
  }

Usage:

  try
  {
    CypherMem::Memory MyMemory(L"wow.exe");

    PVOID TestAddr = reinterpret_cast<PVOID>(0x00400000);

    unsigned long TempULong = MyMemory.Read<unsigned long>(TestAddr);
    std::wcout << "TempULong: " << TempULong << std::endl;

    MyPodType TempPodType = MyMemory.Read<MyPodType>(TestAddr);
    std::wcout << "TempPodType.Foo: " << TempPodType.Foo << std::endl;

    // Current Behaviour: Compiler error. Attempt to call Memory::Read on a 
    // non-POD type.
    // Correct Behaviour: Yes.
    std::wstring TempWString = MyMemory.Read<std::wstring>(TestAddr);
    std::wcout << "TempWString: " << TempWString << std::endl;
  }
  catch (boost::exception const& e)
  {
    std::cout << boost::diagnostic_information(e);
  }
  catch (std::exception const& e)
  {
    std::wcout << "Error! " << e.what() << std::endl;
  }

Obviously it won't compile on its own because it's ripped from my codebase and is missing my exception types, the class def, etc etc. But I'm sure you can fix it up.

The code is tested and working on MSVC10. If you need support for MSVC9 then just use Boost's type traits library and it's static assert macro until you upgrade to a C++0x compiler.

If you're using a compiler other than MSVC then meh, I have no idea if they have support for the necessary type trait.

By the way Flo, if your Win32Exception type takes strings as its parameter types then your GetLastError call may be wrong. You should preserve the value as soon as possible (i.e. make it the first thing you do when the function fails) so it can't be overwritten accidentally by constructor calls or w/e.

[amadmonk]

I have to say that I still heart C# way more than C++.

BUT, C++'s templates simply kick the arse of C#'s... This weekend I had some code that was just CRYING out for partial template specialization...

[Cypher]

I have to say that I still heart C# way more than C++.

BUT, C++'s templates simply kick the arse of C#'s... This weekend I had some code that was just CRYING out for partial template specialization...

Yeah, Apoc and I just had the same discussion. Hehe.

Templates ftw. Some extra runtime type information in C++ would be nice though.

[amadmonk]

From what I remember (and, I'm getting old and my memory is foggy), the RTTI stuff in VC++ was just a horrific ugly hack to look at the source code.

[MBex]

@Cypher

Thank you very much for your response to my library.
I now fixed a lot of things you have mentioned.

Regarding the inheritance i wasn't sure that this is so strange^^.
Now i understood your hint and updated the example so that the class is used as a member.

@flo8464

Thank you too for the hint about templates.
I thought about this but don't implemented it in the first release, maybe i will implement it another day.

[Cypher]

@Cypher

Thank you very much for your response to my library.
I now fixed a lot of things you have mentioned.

Regarding the inheritance i wasn't sure that this is so strange^^.
Now i understood your hint and updated the example so that the class is used as a member.

@flo8464

Thank you too for the hint about templates.
I thought about this but don't implemented it in the first release, maybe i will implement it another day.

If you're going to use templates and don't mind limiting yourself to MSVC 9 and above (for now, until other compilers get the necessary intrinsics) use Boost.TypeTraits to implement them in the same style I have.

You'll save yourself from a lot of potential 'user error' and stupid questions.

Obviously though the implementation I've given is only a basic example, you'd probably also want to add template specializations for some special cases like strings, pointer types (depending on how you want to handle them), etc.

[flo8464]

By the way Flo, if your Win32Exception type takes strings as its parameter types then your GetLastError call may be wrong. You should preserve the value as soon as possible (i.e. make it the first thing you do when the function fails) so it can't be overwritten accidentally by constructor calls or w/e.

Thanks, I never throught that would matter. GetLastError()/SetLastError() use the TLS so they always should be threadsafe, am I right?

That too would be my approach (well, similar, but a bit different in implementation), however sometimes a non-templated approach is appropriate too (as it stops abuse by retarded users trying to use it with non-POD types and wondering why its not working as expected).

EDIT:

To clarify, I'd probably use TMP and 'type traits' to determine whether a type is POD and enforce it that way, however that's probably a bit 'over the top' for what is designed to be a library for beginners. As soon as you start introducing TMP newbies generally get confused.

Yeah, thats true, but I never thought about sharing it (well, I thought about it, but got tired of writing a reference for it :P ) and I know well how to use that template, so it never was my aim to make it noobfriendly, just easy to use. I mean, we are using a language which allows crashing the application in thousand ways so I guess I can expect that the user uses his brain.

But it's the best way to write that template for sure, maybe I ll implement it some day, I just don't see the point in out-of-process hacking anymore

[Cypher]

Thanks, I never throught that would matter. GetLastError()/SetLastError() use the TLS so they always should be threadsafe, am I right?

Correct, that's the whole point of TLS, each thread has their own error code so as long as YOU don't change it it's perfectly safe. Which is why you just pull it out as soon as the function fails an don't call any new methods (because otherwise you risk modifying it).

That too would be my approach (well, similar, but a bit different in implementation), however sometimes a non-templated approach is appropriate too (as it stops abuse by retarded users trying to use it with non-POD types and wondering why its not working as expected).

EDIT:

To clarify, I'd probably use TMP and 'type traits' to determine whether a type is POD and enforce it that way, however that's probably a bit 'over the top' for what is designed to be a library for beginners. As soon as you start introducing TMP newbies generally get confused.

Yeah, thats true, but I never thought about sharing it (well, I thought about it, but got tired of writing a reference for it :P ) and I know well how to use that template, so it never was my aim to make it noobfriendly, just easy to use. I mean, we are using a language which allows crashing the application in thousand ways so I guess I can expect that the user uses his brain.

But it's the best way to write that template for sure, maybe I ll implement it some day, I just don't see the point in out-of-process hacking anymore

Whilst it's true that C++ is a language that's easy to 'shoot yourself in the foot' with, that's no excuse not to make libraries safe and easy to use. In fact, on the contrary, it's a good motivator to make them safe, so it's less to worry about.

Also, RPM can be used in-process to. So you could still use the code simply to avoid having to manually set up the necessary SEH constructs and modifying the necessary page flags every time you want to read/write memory.