Explanation of Gameguard/Maplestory CRC Bypasses and UCEs

On domingo, 5 de septiembre de 2010 0 comentarios

So, I figured that I'd give back to the community what I've learned about the theory behind CRCs and UCEs.

So I was asked the other day, "If I’ve got a UCE, do I need CRC bypasses?” Well, here is the short answer: yes. Here is the long answer…


First, you need to understand what is being bypassed in the first place.

Cyclic Redundancy Check (CRC):
A CRC is defined by Wikipedia
as: “a type of function that takes as input a data stream of any length and produces as output a value of a certain fixed size.” In English, this means that there is a special computer
algorithm (CRC) that takes a part of memory and doing its CRC magic comes up with a value. For example, lets assume that this is a part of maplestory's memory:

00 80 3C 37 90 89

Now lets assume that a highly oversimplified CRC check takes the first number of each pair of numbers and adds them together to get the value. That means that it adds 0+8+3+3+9+8 together to get 31. Now lets assume that a Tool that gives god mode (this is just an example that won't work) needs to change the 37 to a 52. So now the memory would look like this:

00 80 3C 52 90 89

So when the CRC comes around and checks that area of memory, it does its magic, 0+8+3+5+9+8 to get 33. Uh oh, it just did a check and found the CRC value of 31 had been changed to 33. This tells the CRC that the program's memory has been changed. In this case, you'd be caught. We don't want that to happen, now do we? No. So the solution to avoid being caught by the CRC is to have a CRC bypass.

Ok, so now that we know what a CRC is, we can learn how a CRC bypass works. Every case will be different, so I'll explain the theory behind a CRC bypass. A CRC bypass is a function, program, etc. that somehow or another manages to completely avoid the CRC being called. The bypass could either do that or trick the CRC into thinking it is checking the running process, when it is really checking a backup of the running process (possibly stored on the hard drive in a file). Again, this is an extremely general explanation, there are MANY, MANY ways a CRC bypass can be implemented.


Gameguard:
Gameguard does two things. 1) It checks all the running processes on the computer for anything that has been flagged "tool" by the gameguard people. 2) It performs a CRC on maplestory's memory.
To combat these two things, Toolers have implemented two things. 1) UCE and 2) GGCRC bypass.

For those of you who don't even know what a UCE is, it is an undetected cheat engine. Typically, this is compiled using DarkByte's Cheat Engine source code. Basically, people find out what is detected by gameguard, and they either remove/change it from the original Cheat Engine code. Then, it becomes undetected, hence a UCE.

So, with a UCE, the first thing gameguard does is defeated. The second thing, checking maplestory's memory with a CRC, is defeated with a CRC bypass as described above. This is usually pretty difficult, which is why it takes a couple days for one to come out. Note: because gameguard is using its own CRC on the maplestory.exe process, the bypass is called a gameguard cyclic redundancy check (GGCRC).


Maplestory:
This one's pretty easy to explain in light of what has been discussed already. Basically, maplestory checks its own memory with a CRC. So to bypass maplestory's CRC, we use what is called a maplestory cyclic redundancy check (MSCRC).


Ok, so back to the original question. You need an undetected cheat engine AND a maplestory CRC bypass AND a gameguard CRC bypass. Simply put, you can run the UCE while maplestory is up, without a GGCRC bypass nor MSCRC bypass running, and not be caught. But you can't USE the UCE without being caught. That's pretty useless to have a cheat engine that you can't use. So, that's the reason we need a GGCRC bypass and a MSCRC bypass.

Woah! That was a lot of stuff thrown at you all at once. I know. It took a while to really understand it all. If you don't get it the first time, then you are a normal human being. It took me a LONG time to really get this stuff, but I figured I'd make it as simple for you guys as i could. If you don't get it, then read over this stuff again, browse forums for people asking questions you might have, and if you have searched everywhere, then ask a question. Hit the thanks button if you found anything in this useful.
Read more ...»

Module-Hider

On 0 comentarios

Code snip

//=====================================================================================
// Project : HelioS-Module-Hider
// Version : 1.0
// Coder : [ELF]HelioS
// Site : http://www.ArtificialAiming.tk
//=====================================================================================

// What:
// Hide a Dynamic Link Library from the module list on NT systems

// References:
// Tetsuo (http://www.game-deception.com)
// NTinternals (http://undocumented.ntinternals.net)
// Phrack Inc. (http://www.phrack.org)


#include "ModuleHider.h"


void HideModuleEx (HINSTANCE hModule, ELIST eList)
{
PPEB Peb = (PPEB)0x7ffdf000; // Static pointer to the Process Environment Block
char szPath[MAX_PATH];

GetModuleFileNameA(hModule, szPath, MAX_PATH);

if (Peb && Peb->LoaderData && Peb->LoaderData->Initialized)
{
PLIST_ENTRY pListHead = NULL, pListPtr = NULL;
DWORD dOffset = 0;

switch (eList) // There are 3 module lists with different offsets
{
case LIST_LoadOrder:
pListHead = pListPtr = &(Peb->LoaderData->InLoadOrderModuleList);
dOffset = 0x24;
break;

case LIST_MemoryOrder:
pListHead = pListPtr = &(Peb->LoaderData->InMemoryOrderModuleList);
dOffset = 0x1C;
break;

case LIST_InitOrder:
pListHead = pListPtr = &(Peb->LoaderData->InInitializationOrderModuleList);
dOffset = 0x14;
break;
}

if (pListHead && pListPtr)
{
// LIST_ENTRY is a double linked list, so we need to loop thru 2 lists

do // Loop thru Flink
{
char name[MAX_PATH];
wsprintfA(name, "%S", ((PUNICODE_STRING)((PCHAR)pListPtr->Flink + dOffset))->Buffer);

if (!stricmp(name, szPath)) // We found our module, so lets hide it
{
pListPtr->Flink = pListPtr->Flink->Flink;
}

pListPtr = pListPtr->Flink;

} while (pListPtr->Flink != pListHead->Flink);

do // Loop thru Blink
{
char name[MAX_PATH];
wsprintfA(name, "%S", ((PUNICODE_STRING)((PCHAR)pListPtr->Blink + dOffset))->Buffer);

if (!stricmp(name, szPath)) // We found our module, so lets hide it
{
pListPtr->Blink = pListPtr->Blink->Blink;
}

pListPtr = pListPtr->Blink;

} while (pListPtr->Blink != pListHead->Blink);
}
}
}


void HideModule (HINSTANCE hModule)
{
HideModuleEx(hModule, LIST_LoadOrder);
HideModuleEx(hModule, LIST_MemoryOrder);
HideModuleEx(hModule, LIST_InitOrder);
}


BOOL WINAPI DllMain (HINSTANCE hModule, DWORD dwReason, LPVOID lpvReserved)
{
if (dwReason == DLL_PROCESS_ATTACH)
{
HideModule(hModule);
}

return TRUE;
}
Read more ...»

how to remove your module from the PEB linked list

On 0 comentarios

This method can be used to remove your module from the module list of a process. The biggest use is to prevent VAC from performing a a checksum scan of your module (though it does not prevent string scanning). I think it can also be useful for PB but I haven't used PB so I don't know

You may need the Windows 2000/XP/Server 2003 DDK installed to compile. Otherwise you will have to just pad the structures out to the right size whenever there is an undefined type, or get someone with the DDK to send you the relevent header files and get the structures yourself. Particularly the CONTAINING_RECORD and other list managedment macros are in the DDK only and not the SDK I believe, although you can also find them in the Wine project source.

You can use the header I already made with the information from http://undocumented.ntinternals.net/. Download it here if you want: http://www.tabris.game-deception.com/VAC/NTundoc.h

All 3 linked lists are essentially the same, but you have to remove your module from all 3 in order to be hidden well. I have only commented the first one.

// IF YOU USE THIS CODE, PLEASE CREDIT WWW.GAME-DECEPTION.COM
// YOU MAY FREELY RELEASE BINARIES CONTAINING THIS CODE AS LONG AS SUCH A CREDIT APPEARS IN THE DOCUMENTATION

void RemoveModuleFromPEB(void)
{
PTEB pTEB;
PPEB_LDR_DATA pLDR;
PLIST_ENTRY pMark, pEntry;
PLDR_MODULE pLM;
char *pSig = "anything can go here this string does not matter in fact you could use a pointer to one of the existing variables I just wanted to make it obvious what was going on ok stop bugging me";

pTEB = GetCurrentTeb(); // get the current Thread Environment Block

pLDR = pTEB->Peb->LoaderData; // get a pointer to the loader data structure within the PEB (process environment block) within the TEB

pMark = &(pLDR->InMemoryOrderModuleList); // the list is circular-linked, so we have to mark the point at which we start traversing it so we know when we've made a full traversal

for(pEntry = pMark->Flink; pEntry != pMark; pEntry = pEntry->Flink)
{
pLM = CONTAINING_RECORD(pEntry, LDR_MODULE, InMemoryOrderModuleList); // CONTAINING_RECORD is in the DDK, it basically just gets a pointer to the actual structure from the linked list element
if((DWORD)pSig > (DWORD)pLM->BaseAddress && (DWORD)pSig < ((DWORD)pLM->BaseAddress + (DWORD)pLM->SizeOfImage)) // check if the "signature" variable is inside this module, if so it is our module
{
pEntry->Blink->Flink = pEntry->Flink; // change the previous element to point to the next element, so that traversing the list in a forward direction no longer yields our module
pEntry->Flink->Blink = pEntry->Blink; // change the next element to point to the previous element, so that traversing the list in a reverse direction no longer yields our module
}
}

pMark = &(pLDR->InLoadOrderModuleList);

for(pEntry = pMark->Flink; pEntry != pMark; pEntry = pEntry->Flink)
{
pLM = CONTAINING_RECORD(pEntry, LDR_MODULE, InLoadOrderModuleList);
if((DWORD)pSig > (DWORD)pLM->BaseAddress && (DWORD)pSig < ((DWORD)pLM->BaseAddress + (DWORD)pLM->SizeOfImage))
{
pEntry->Blink->Flink = pEntry->Flink;
pEntry->Flink->Blink = pEntry->Blink;
}
}

pMark = &(pLDR->InInitializationOrderModuleList);

for(pEntry = pMark->Flink; pEntry != pMark; pEntry = pEntry->Flink)
{
pLM = CONTAINING_RECORD(pEntry, LDR_MODULE, InInitializationOrderModuleList);
if((DWORD)pSig > (DWORD)pLM->BaseAddress && (DWORD)pSig < ((DWORD)pLM->BaseAddress + (DWORD)pLM->SizeOfImage))
{
pEntry->Blink->Flink = pEntry->Flink;
pEntry->Flink->Blink = pEntry->Blink;
}
}
}


If you have done it right, you should be able to load LordPE, OllyDbg, or something similar and list the modules in the process without your module showing in the list at all. It totally prevents the Toolhelp32 functions (Module32First and Module32Next) from seeing your module.

If you are really obsessive about hiding your module, you may be able to blank out the LoaderModule structure after finding and unlinking it, though I have not checked if this works without causing any odd behaviour

Thanks to the good people at undocumented.ntinternals.net for their excellent documentation and to RetarT for giving me the idea

If anyone asks "where do I put this" I will delete their post.
Read more ...»

Module Hiding

On 0 comentarios

Since VAC scans all files in running memory, we need to some how fake it.
This is used by showing VAC that our dll was NEVER injected into process!!!
The deception is possible in ring 3 since the kernel maintains a list of
each loaded DLL for a given process inside its memory space, in userland.
Therefore a process may affect himself and overwrite parts of its memory
in order to hide one of its module. These data structures are of course
undocumented but can be recovered by using the Process Environment Block
(PEB), located at FS:0x30 inside each process. The function below returns
the address of the PEB for the current process.

DWORD GetPEB()
{
DWORD* dwPebBase = NULL;
/* Return PEB address for current process
address is located at FS:0x30 */
__asm
{
push eax
mov eax, FS:[0x30]
mov [dwPebBase], eax
pop eax
}
return (DWORD)dwPebBase;
}


The role of the PEB is to gather frequently accessed information for a
process as follows. At address FS:0x30 (or 0x7FFDF000) stands the
following members of the [PEB].

/* located at 0x7FFDF000 */
typedef struct _PEB
{
BOOLEAN InheritedAddressSpace;
BOOLEAN ReadImageFileExecOptions;
BOOLEAN BeingDebugged;
BOOLEAN Spare;
HANDLE Mutant;
PVOID ImageBaseAddress;
PPEB_LDR_DATA LoaderData;
PRTL_USER_PROCESS_PARAMETERS ProcessParameters;
[...]
ULONG SessionId;
} PEB, *PPEB;



The interesting member in our case is PPEB_LDR_DATA LoaderData that
contains information filled by the loader at startup, and then when
happens a DLL load/unload.

typedef struct _PEB_LDR_DATA
{
ULONG Length;
BOOLEAN Initialized;
PVOID SsHandle;
LIST_ENTRY InLoadOrderModuleList;
LIST_ENTRY InMemoryOrderModuleList;
LIST_ENTRY InInitializationOrderModuleList;
} PEB_LDR_DATA, *PPEB_LDR_DATA;


The PEB_LDR_DATA structure contains three LIST_ENTRY that are part of doubly
linked lists gathering information on loaded DLL in the current process.
InLoadOrderModuleList sorts modules in load order, InMemoryOrderModuleList
in memory order, and InInitializationOrderModuleList keeps track of their
load order since process start.

These doubly linked list contains pointers to LDR_MODULE inside the parent
structure for next and previous module.

typedef struct _LDR_MODULE {

LIST_ENTRY InLoadOrderModuleList;
LIST_ENTRY InMemoryOrderModuleList;
LIST_ENTRY InInitializationOrderModuleList;
PVOID BaseAddress;
PVOID EntryPoint;
ULONG SizeOfImage;
UNICODE_STRING FullDllName;
UNICODE_STRING BaseDllName;
ULONG Flags;
SHORT LoadCount;
SHORT TlsIndex;
LIST_ENTRY HashTableEntry;
ULONG TimeDateStamp;

} LDR_MODULE, *PLDR_MODULE;


The following code demonstrates how to walk one of the lists and throw
a module away according to its name (szDllToStrip).

/* Walks one of the three modules double linked lists referenced by the
PEB (error check stripped)
ModuleListType is an internal flag to determine on which list to operate :
LOAD_ORDER_TYPE <---> InLoadOrderModuleList
MEM_ORDER_TYPE <---> InMemoryOrderModuleList
INIT_ORDER_TYPE <---> InInitializationOrderModuleList
*/
int WalkModuleList(char ModuleListType, char *szDllToStrip)
{
int i; /* internal counter */
DWORD PebBaseAddr, dwOffset=0;

/* Module list head and iterating pointer */
PLIST_ENTRY pUserModuleListHead, pUserModuleListPtr;

/* PEB->PEB_LDR_DATA*/
PPEB_LDR_DATA pLdrData;
/* Module(s) name in UNICODE/AINSI*/
PUNICODE_STRING pImageName;
char szImageName[BUFMAXLEN];

/* First, get Process Environment Block */
PebBaseAddr = GetPEB(0);

/* Compute PEB->PEB_LDR_DATA */
pLdrData=(PPEB_LDR_DATA)(DWORD *)(*(DWORD *)(PebBaseAddr +
PEB_LDR_DATA_OFFSET));

/* Init linked list head and offset in LDR_MODULE structure */
if(ModuleListType == LOAD_ORDER_TYPE)
{
/* InLoadOrderModuleList */
pUserModuleListHead = pUserModuleListPtr =
(PLIST_ENTRY)(&(pLdrData->ModuleListLoadOrder));
dwOffset = 0x0;
} else if(ModuleListType == MEM_ORDER_TYPE)
{
/* InMemoryOrderModuleList */
pUserModuleListHead = pUserModuleListPtr =
(PLIST_ENTRY)(&(pLdrData->ModuleListMemoryOrder));
dwOffset = 0x08;
} else if(ModuleListType == INIT_ORDER_TYPE)
{
/* InInitializationOrderModuleList */
pUserModuleListHead = pUserModuleListPtr =
(PLIST_ENTRY)(&(pLdrData->ModuleListInitOrder));
dwOffset = 0x10;
}

/* Now walk the selected list */
do
{
/* Jump to next LDR_MODULE structure */
pUserModuleListPtr = pUserModuleListPtr->Flink;
pImageName = (PUNICODE_STRING)(
((DWORD)(pUserModuleListPtr)) +
(LDR_DATA_PATHFILENAME_OFFSET-dwOffset));

/* Decode unicode string to lower case on the fly */
for(i=0; i < (pImageName->Length)/2 && iBuffer)+(i) ));
/* Null terminated string */
szImageName[i] = '\0';

/* Check if it's target DLL */
if( strstr((char*)szImageName, szDllToStrip) != 0 )
{
/* Hide this dll : throw this module away (out of
the double linked list)
(pUserModuleListPtr->Blink)->Flink =
(pUserModuleListPtr->Flink);
(pUserModuleListPtr->Flink)->Blink =
(pUserModuleListPtr->Blink);
/* Here we may also overwrite memory to prevent
recovering (paranoid only ;p) */
}
} while(pUserModuleListPtr->Flink != pUserModuleListHead);

return FUNC_SUCCESS;
}


To process the three linked lists, the cheat calls the HideDll function
below.

int HideDll(char *szDllName)
{
return ( WalkModuleList(LOAD_ORDER_TYPE, szDllName)
&& WalkModuleList(MEM_ORDER_TYPE, szDllName)
&& WalkModuleList(INIT_ORDER_TYPE, szDllName) );
}


http://forum.gamedeception.net/threads/5012-Module-Hiding
Read more ...»

Tutorial How to make a dll trainer

On viernes, 3 de septiembre de 2010 0 comentarios

Well since a lot of you guys asking me on how to make a trainer, I'll just post a tutorial on how to make a simple trainer like I've released. This was a total spoon feed so it will be copy and paste and edit. First, there are few things you need:

1. Microsoft Visual Studio 2010
2. A lil knowledge about Assembly.

Ok, let's start this. Run your Microsoft Visual Studio 2010. Click New Project->Win32 and Enter your Project name. Lets say Trainer. Click Ok and next, choose DLL and Empty project. Now you are in Trainer.cpp blank page. Ok, now go Solution Explorer(You could find it easily a View tab) and you'll see 4 things there:

1. External Dependencies
2. Header Files
3. Resource Files
4. Source Files



Now you need to add in a few files inside these folders to make it work. To add a file, simply right click->Add and choose your extension. For Header Files, choose .h extension. For Source Files, choose .cpp extension. I'm lazy so I posted a screenshot for you all to look at, add all the files inside the screenshot.


Ok, if you follow my simple tutorial, these would be your files to make your first dll trainer. We'll use the most simple example for this tutorial.Super tubi.

//Tubi(Updated by nerrazzuri msea v93)
[enable]
00488AA6: //75 ? 83 7C 24 ? ? 75 ? 8B ? ? ? ? ? FF 70 ? 83 C0 ? 50
DB 90 90
[disable]
00488AA6: //75 ? 83 7C 24 ? ? 75 ? 8B ? ? ? ? ? FF 70 ? 83 C0 ? 50
jne 00488ADE //byte 75 36

Now, Open up your Trainer.h and paste the codes below into it.

#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
#include
#include


//ADD Tool BELOW *THIS IS KINDA LIKE A LIST OF THE Tool YOU ARE ADDING*


void SuperTubi(__in BOOL bEnable);//To add in more Tool, simply copy this line and paste it at the bottom, and change the name SuperTubi to others for example NoKnockBack.

This is where you declare the header of your Tool.


After you have done, now we move to the part where everyone loves, GUI. Go back to the Solution Explorer->Right Click at the Resource Files. Add a Resource(not item) and choose Dialog(DO NOT CLICK THE +, click Dialog and click new and you'll bring to a Dialog Box which is like below:
 


Add in a checkbox at the Dialog Editor(You can found it easily at View->Toolbars) like mine below.


 
Read more ...»