[Guide] Memory Editing - The Basics

[flo8464]

still don't get why you're not just injecting a dll because you're using C++.. but hey.

Because I am currently coding for Rappelz, a Gameguard protected game.
As I don't really know how to bypass Gameguard, I wrote a small kernel driver offering the same functionality like ReadProcessMemory/WriteProcessMemory.
Even if I would manage to inject my DLL and run it, I have no clue how to protect it. I tried to reverse Gameguard and gave up. Gameguard can be nasty.

[Krillere]

Any chance anyone could help me with this error? :

Not all privileges or groups referenced are assigned to the caller

when I attempt to use BlackMagic for anything else than WoW.

[nitrogrlie]

Are you attempting to use it on a 64-bit process? or perhaps a non-userspace launch process? or perhaps a userspace process with a higher privilege?

No idea what BlackMagic is but above are decent conjectures...

[snigelmannen]

Got that too, start Visual Studio with admin rights, and always check debug to x86

[Krillere]

I wanted to try it out with Windows 7 Spider Solitaire, a simple read / write point "hack", and i got this error. Even with

BlackMagic^ SS = gcnew BlackMagic();
SS->SetDebugPrivilegies();

[lanman92]

Wtf? C++/CLI? Who the hell does that?

[flo8464]

Wtf? C++/CLI? Who the hell does that?

Someone who needs to use .NET libraries.

[Krillere]

Ok. I made this work:

 BlackMagic^ SS = gcnew BlackMagic();
 SS->OpenProcessAndThread( SProcess::GetProcessFromWindowTitle( "Spider Solitaire" ) );
 SS->SetDebugPrivileges;
 SS->WriteByte( 0x0054E708, 501 );
 SS->WriteByte( 0x00558420, 501 );

I ran Visual Studio as Administrator as someone mentioned earlier, that might have done the trick.

[amadmonk]

I know Cypher will disagree, but C++/CLI is actually pretty spiffy.

The only real problems I have with it is that it's not always totally clear when you're "managed" and when you're "not" (there are some things you can do in unmanaged code, like some VEH stuff that, FWIK, are simply off limits in managed code). Whenever I tweak my C++/CLI codebase I get bit by that and have to unwind it.

C++/CLI is a very good way to "hoist" a .Net runtime into an existing process. It saves you a number of steps you have to perform in a pure C++ injection.

[Cypher]

I know Cypher will disagree, but C++/CLI is actually pretty spiffy.

The only real problems I have with it is that it's not always totally clear when you're "managed" and when you're "not" (there are some things you can do in unmanaged code, like some VEH stuff that, FWIK, are simply off limits in managed code). Whenever I tweak my C++/CLI codebase I get bit by that and have to unwind it.

C++/CLI is a very good way to "hoist" a .Net runtime into an existing process. It saves you a number of steps you have to perform in a pure C++ injection.

C++/CLI imo is simply a disgusting language. When I use it it just feels like they've taken the worst aspects C++ and .NET and mixed them together.

I can see the appeal of it in some very limited circumstances, however it's not all that hard to load the CLR manually in native C++. I have not had a single game (including both IA32 and AMD64 ones) where my native C++ CLR loading code has failed.

[amadmonk]

It's been a while since I did it in unmanaged C++ but IIRC, you can't really interact with your loaded code if you hoist the CLR in fully unmanaged code. You just sort of start the runtime and... let it go.

With C++/CLI you can actually call specific methods in your assembly when native events happen.

Might just be my ignorance of the hosting API's, but when I tried to actually *interact* with the embedded runtime in pure C++, it failed utterly.

[darrensmith0125]

Not all privileges or groups referenced are assigned to the caller .

If you are using windows 7 You could try:

Control Panel->System security->Change user account control settings. Set to Never notify.

[Cypher]

It's been a while since I did it in unmanaged C++ but IIRC, you can't really interact with your loaded code if you hoist the CLR in fully unmanaged code. You just sort of start the runtime and... let it go.

With C++/CLI you can actually call specific methods in your assembly when native events happen.

Might just be my ignorance of the hosting API's, but when I tried to actually *interact* with the embedded runtime in pure C++, it failed utterly.

I load the CLR using a domain manager written in C# (Thanks Grey!). This domain manager is exposed to the C++ layer, and the C++ layer exposes APIs and callbacks to the domain manager.

pCLRControl->SetAppDomainManagerType(DomainMgr.c_str(), DomainMgrType.c_str());

[Kryso]

It's been a while since I did it in unmanaged C++ but IIRC, you can't really interact with your loaded code if you hoist the CLR in fully unmanaged code. You just sort of start the runtime and... let it go.

With C++/CLI you can actually call specific methods in your assembly when native events happen.

Might just be my ignorance of the hosting API's, but when I tried to actually *interact* with the embedded runtime in pure C++, it failed utterly.

You can use interfaces.. it isn't comfortable if you need to interact with a lot of things, but it works

        ESCS( pAppDomain->CreateInstance( _bstr_t( "EzMode" ), _bstr_t( "EzMode.Interop.ComObject" ), &pObjectHandle ) );

        CComVariant variant;
        ESCS( pObjectHandle->Unwrap( &variant ) );

        if ( variant.vt != VT_DISPATCH ) throw std::string( "Variant isn't VT_DISPATCH" );

        CComPtr<IDispatch> pDispatch;
        pDispatch = variant.pdispVal;

        ESCS( pDispatch->QueryInterface( &pComObject ) );
        pDispatch.Release();

        ESCS( pComObject->Initialize() );

[amadmonk]

AIEEE! Dispinterfaces? I hate COM with a passion bordering on insanity... I'll take the semantic ugliness of C++/CLI over IUnknown and AddRef/Release any day...

Still it's interesting to see that you can do it. Right now I just have two native->managed callbacks (endframe and an VEH/DR on event callback); it might be possible to trim down a little bit of code if I could bite the bullet.