C++ Base64 String "Z2V0UGFzc3dvcmQ=" as function name - c++

some quick info about me
I'm a MalwareResearcher since 2008 and C++/MASM Developer since 2013. Atm I improve and test my skills with malware samples and CrackMe's.
I found a really nice one and got stucked at the coding part :(
Code Snippet from crackme:
MOV EAX,004260AC ; ASCII "TUFMQ0hPLkRMTA=="
CALL 00407B10
JMP SHORT 004049FB
XOR EAX,EAX
MOV DWORD PTR SS:[LOCAL.1],-1
TEST EAX,EAX
JZ 00404AC3
MOV EAX,DWORD PTR DS:[EAX]
PUSH EAX ; /FileName
CALL DWORD PTR DS:[<&kernel32.LoadLibraryA>] ; \KERNEL32.LoadLibraryA
TEST EAX,EAX
JZ 00404AC3
PUSH 004260C0 ; /Procname = "Z2V0UGFzc3dvcmQ="
PUSH EAX ; |hModule
CALL DWORD PTR DS:[<&kernel32.GetProcAddress>] ; \KERNEL32.GetProcAddress
The crackme tries to load a dll called MALCHO.dll with LoadLibraryA and then tries to execute one its functions named Z2V0UGFzc3dvcmQ=.
After that it decrypts one of its resources with the password gathered from the dll's function Z2V0UGFzc3dvcmQ=.
As a part of the crackme it seems that I have to make this dll.
I was able to get the password which is needed for decryption by analysing another part of this specimen.
So "only" dll coding is needed to reach the end of the crackme :)
While decrypting TUFMQ0hPLkRMTA== to MALCHO.dll it seems that its function name Z2V0UGFzc3dvcmQ= is not decrypted to getPassword.
I don't now how to use a base64 encoded string as a function name in c++.
I get a syntax error in cause of the = in Z2V0UGFzc3dvcmQ= :(
My MALCHO.dll source:
MALCHO.h:
#ifdef MALCHODLL_EXPORTS
#define MALCHOFUNCSDLL_API __declspec(dllexport)
#else
#define MALCHOFUNCSDLL_API __declspec(dllimport)
#endif
namespace MALCHO
{
//This class is exported from the MalchoFuncsDll.dll
class MalchoFuncs
{
public:
// Returns password
static MALCHOFUNCSDLL_API char* Z2V0UGFzc3dvcmQ=(char* p);
};
}
MALCHO.cpp
#include "stdafx.h"
#include "MALCHO.h"
namespace MALCHO
{
char* MalchoFuncs::Z2V0UGFzc3dvcmQ=(char* p)
{
char* pw = "Yes I did it!";
return pw;
}
}
thanks in advance
MasDie

You can't use = as part of a name in C++, but GetProcAddress is an OS function which doesn't care about the language that you used. It just does string matching, and not very fancy either. It really cares only about \0 because that terminates the string. So, if you pass Z2V0UGFzc3dvcmQ=\0 it will look for an export named Z2V0UGFzc3dvcmQ=\0.
The syntax of a linker definition file for LINK.EXE won't allow you to add such a name, but again GetProcAddress doesn't care who put the name in the export table. The easiest solution is probably to add Z2V0UGFzc3dvcmQ_\0 and then overwrite the _

Related

Passing integer to x86 ASM in C++

I am trying to do some script hooking in C++, and have setup a simple test function for this case.
void __declspec(naked) testFunct()
{
int myInt;
myInt = 2000;
__asm{
mov eax, myInt
jmp [jmp_back_address]
}
}
when using this to pass in the integer, the function fails when it is called and the project crashes. However, when using this instead, without an integer value, it successfully passes through.
void __declspec(naked) testFunct()
{
__asm{
mov eax, 2000
jmp [jmp_back_address]
}
}
How can I successfully pass the integer?
The correct solution for my situation was to simply do everything within the ourFunct() through ASM instead, as mixing both C++ and ASM for passing variables was creating buggy assembly code. Example with a function call that works:
int CalculateTotalScore()
{
return (int)*Game::current_speed_score;
}
DWORD jmpBackAddress;
void __declspec(naked) ourFunct()
{
__asm{
call CalculateTotalScore
jmp [jmpBackAddress]
}
}
The assembler doesn't know what "myInt" means. Most compilers support inline assembly with the possibility to pass values. For instance, with GCC, you may try to define a macro like
#define MY_ASM_MACRO(myInt) ({ asm volatile("mov eax,%0\n\t \
jmp [jmp_back_address]" : : "r"(myInt) : ); })
And use it like
void __declspec(naked) testFunct()
{
int myInt;
myInt = 2000;
MY_ASM_MACRO(myInt)
}

c++ function addresses coming out different in attached profiler library than in the subject code base

I have written an instrument-er in C++ to log entry and exit functions by hooking on enter and exit calls. It is working as supposed to with a legacy code base. However on hooking with a project that I downloaded from git, function addresses that I save in an extern variable in the subject code, they are coming out different in the profiler library. That is messing up the function pointer comparison between hooked and saved functions.
Function address in subject code main file, breakpoint is inside the _penter hook function in the profiler code currently
The same entry is showing a different address with a "_" preceding the function name, in the profiler code
I have no idea how it is changing the addresses and want to know if I am doing something wrong.
The way I am doing it is, I have an extern array of function pointers( and their names) that is initialized with subject code functions' references in the subject main file(where all functions are available). In hook function (_penter) of the library, I get the address of the function just entered. So I compare it with the addresses in the extern array, and if it is a match, I log the entered function.
SNIPPET FROM PROFILE.H (profiler)
extern Signature FuncTable[3000];
SNIPPET FROM PROFILE.CPP (profiler)
void _stdcall EnterFunc0(unsigned * pStack)
{
void * pCaller;
pCaller = (void *)(pStack[0] - 5); // the instruction for calling _penter is 5 bytes long
Signature * funct = FuncTable; //the table that has references to functions and their names
funct = FuncTable;
while (funct->function)
{
//const BYTE * func = (const BYTE *)funct->function;
if ((void *)(pStack[0] - 5) == (void *)(funct->function))
{
int a = 0;
linesBuffer = linesBuffer + "Entering " + funct->signature + ";";
linesBuffer = linesBuffer + "\n";
WriteToFile(false); //function buffers 100kb before writing
break;
}
funct++;
}
}
extern "C" __declspec(naked) void __cdecl _penter()
{
_asm
{
pushad // save all general purpose registers
mov eax, esp // current stack pointer
add eax, 32 // stack pointer before pushad
push eax // push pointer to return address as parameter to EnterFunc0
call EnterFunc0
popad // restore general purpose registers
ret // start executing original function
}
}
SNIPPET FROM main.c (subject code main file)
#include "../Profile/Profile.h"
Signature FuncTable[] = {
{ (int)TetrisView_ProcessPauseMenu, "TetrisView_ProcessPauseMenu" },
{ NULL }
};
I think it is because of Incremental Linking. When it is turned on, you'll get an Incremental Linking Table (ILT). ILT contains a jump table. When a function is called, it is called via this ILT.
In FuncTable, you'll get an address which is in ILT, it won't be the address of the actual function. But in _penter, its return address will be the actual function (this is what is put in pCaller).
Turn off incremental linking, and you'll be fine.

Contextual differences in inline assembly code

Along the lines with the first answer here I tried to encapsulate some assembly code in a C++ function.
When I put this code in a function (inline or not) and pass the shellcode as an argument to the function it gives me an access violation 0xC0000005 at the call instruction, with or without DEP enabled. However, when I define the shellcode inside the function just before VirtualProtect, it works fine.
Current function code:
inline void ExecuteShellcode(char shellcode[])
{
/*char shellcode[] = \
"shellcode"; // If I use this local variable instead of the argument it works tho
*/
DWORD tempstore;
if (VirtualProtect(shellcode, sizeof(shellcode), PAGE_EXECUTE_READWRITE, &tempstore))
{
__asm lea eax, shellcode;
__asm call eax; Access violation 0xC0000005
}
}
Why does __asm call not work with non-local variables in this instance?

Inconsistent member offset computation in MFC class

In our VS2013 MFC Project, the CWinApp application class has a CWordArray member.
Looking at the dissassembly we can tell that the offset of this member is 21Eh.
This is the call to SetSize assembly code called from within the CwinApp:
m_arrayDefInd.SetSize(64, 1);
00F36D0F push 1
00F36D11 push 40h
00F36D13 mov ecx,dword ptr [this]
00F36D16 add ecx,21Eh <<<<<< NOTE OFFSET
00F36D1C call CWordArray::SetSize (0FC25E0h)
However, in a CView class, we retrieve the CwinApp pointer and reference this same member. When we look at the dissassembly code in the CView class, the compiler has set the offset at 230h.
CMyApp *pApp = (CMyApp *)AfxGetApp();
int size = pApp->m_arrayDefInd.GetSize();
00F2DA42 mov ecx,dword ptr [ebp-20h]
00F2DA45 add ecx,230h <<<<<< NOTE OFFSET
00F2DA4B call CWordArray::GetSize (0FC225Ch)
00F2DA50 mov dword ptr [ebp-24h],eax
We have done the obvious – clean, rebuild all. We have ensured both compilation units are using the same application header file.
The above was ported from a VS6 application that handles this correctly.
We're at a loss to explain the above. Can anyone help?

Arbitrary pointer to unknown class function - invalid type conversion

I have a hack program; it injects some functions into a target process to control it. The program is written in C++ with inline assembly.
class GameProcMain {
// this just a class
};
GameProcMain* mainproc; // there is no problem I can do =(GameProcMain*)0xC1EA90
Now I want to define a class function (which set ecx to class pointer) instead of writing assembly.
PPLYDATA GetNearblyMob(__Vector3* cordinate) {
__asm {
mov ecx, 0xC1EA90
enter code here
push cordinate
mov edi, 0x4A8010
call edi
}
}
I want to define it and call it like.
PPLYDATA (DLPL::*GetNearblyMob)(__Vector3* cordinate);
mainproc->GetNearblyMob(ADDR_CHRB->kordinat)
When I try GetNearblyMob=(PPLYDATA (DLPL::*)(__Vector3*)) 0x4A8010;
It says something like error: invalid type conversion: "int" to "PPLYDATA (DLPL::*)(int, int)"
but I can do this to set the pointer:
void initializeHack() {
__asm {
LEA edi, GetNearblyMob
MOV eax, 0x4A8010
MOV [edi], eax
}
}
Now I want to learn "how I can set GetNearblyMob without using assembly and legitimately in C++".
The problem is that member functions automatically get an extra parameter for the this pointer. Sometimes you can cast between member and non-member functions, but I don't see the need to cast anything.
Typically it's easier to reverse-engineer into C functions than into C++. C typically has a more straightforward ABI, so you can keep the data structures straight as you work them out.
So, I would recommend
PPLYDATA (*GetNearblyMob)(DLPL *main_obj, __Vector3* cordinate) = 0x12345UL;
and then define your own function
class DLPL {
GetNearblyMob( __Vector3* cordinate ) {
return ::GetNearblyMob( this, cordinate );
}
// ... other program functions
};
I am a bit surprised that it won't you cast like that.
You can try to do something like
GetNearblyMob=reinterpret_cast<PPLYDATA (DLPL::*)(__Vector3*)> (0x4A8010);
If that still does not work, try
*(int*)(&GetNearblyMob) = 0x4A8010;