As everyone mentioned, they can easily bypass your little protection by hooking your dll or hooking before you do, and bypassing your encryption altogether.
Printable View
As everyone mentioned, they can easily bypass your little protection by hooking your dll or hooking before you do, and bypassing your encryption altogether.
Here is a very basic example of a userland trampoline hook. It hooks the MessageBox function of any injected app.
If you're only dealing with a bunch of script kiddies, this will work fine. The MyMessageBox function will become your send function.
So, you'll have to modify that function accordingly which will include any encryption algorithms.
Code://File dllmain2.cpp
// Compile cl.exe /LD dllmain2.cpp
#pragma comment(lib, "user32.lib")
#include <windows.h>
#include <stdio.h>
bool HOOKED = false;
#pragma optimize("", off)
int _declspec(naked) _stdcall MsgBoxTramp (HWND hWnd,LPCSTR lpText,LPCSTR lpCaption,UINT uType)
{
__asm{
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
_emit 0xAA
_emit 0xAA
_emit 0xAA
_emit 0xAA
_emit 0xAA
ret
}
}
#pragma optimize("", on)
#pragma optimize("", off) //Turn optimisation off. Unreferenced code is removed by compiler optimization.
int _stdcall MyMessageBox(HWND hWnd,LPCSTR lpText,LPCSTR lpCaption,UINT uType)
{
int retval;
char* NewText = (char*)malloc(256); // Just to indicate that malloc can be called. Not really relevant
strcpy(NewText, "You have been hooked!!!");
retval = MsgBoxTramp(hWnd, NewText, lpCaption, uType);
free (NewText);
return retval;
}
void HookMsgBox(void)
{
//Initialise our vars, get pointers as chars to BOTH our trampoline function _and_ the hook function
unsigned char NewData[5], OldData[5], TrampJump[5]; //This is a 5 byte hook, it could be more but I use Windows XP SP2..
unsigned char* MessageBoxPtr = (unsigned char*)&MessageBoxA;
unsigned char* HookTramp = (unsigned char*)&MsgBoxTramp;
DWORD OldProtect;
int i;
//First off, we fill our replacement code arrays with data:
//NewData will contain the bytes for the jmp to be installed.
//Make the first byte an E9, meaning jmp.
NewData[0] = 0xE9;
//Set the remaining 4 bytes to the address offset. An ‘E9 jmp’ tells the processor to increment or decrement its EIP, it doesn’t tell the processor what the EIP should be.
*(PDWORD)&NewData[1] = (DWORD)( (DWORD)MyMessageBox - ((DWORD)MessageBoxA + 5)); //Note the +5. The last byte of your jmp will be located at MessageBoxA+5, and this is where the address offset needs to be calculated from. (Change in address = New minus Old. Complex maths formula ain't it? ;> )
//TrampJump will contain the bytes where you that hardcode the jump back to MessageBox. It is technically fine for TrampJump to just have a “jmp [MessageBoxA+5]” tagged at the end of it, as the compiler can do that. But I don’t trust compilers.
TrampJump[0] = 0x68; //Push
*(PDWORD)&TrampJump[1] = (DWORD)MessageBoxA + 5; //Push Address, as I explained already. :>
VirtualProtectEx(GetCurrentProcess(), MessageBoxA, 10, PAGE_EXECUTE_WRITECOPY, &OldProtect); //Unprotect the target memory. 10 bytes for good measure.
for (i = 0; i < 5; i++){
OldData[i] = MessageBoxPtr[i]; //Grab the overwritten bytes
MessageBoxPtr[i] = NewData[i]; //Insert the new bytes. *MAKE SURE YOU DON’T CUT OFF PART OF AN INSTRUCTION!*
}
VirtualProtectEx(GetCurrentProcess(), MessageBoxA, 10, OldProtect, NULL); //Reprotect the memory.
VirtualProtectEx(GetCurrentProcess(), MsgBoxTramp, 25, PAGE_EXECUTE_WRITECOPY, &OldProtect);
for (i = 0; i < 5; i++){
HookTramp[i] = OldData[i]; //Make the first 5 bytes of the trampoline equal the bytes removed.
}
for (i = 0; i < 50; i++){
//Search for the last 5 bytes that you put aside for this push operation.
if (HookTramp[i] == 0xAA &&
HookTramp[i+1] == 0xAA &&
HookTramp[i+2] == 0xAA &&
HookTramp[i+3] == 0xAA &&
HookTramp[i+4] == 0xAA)
{
//Overwrite the bytes when found
HookTramp[i] = TrampJump[0];
HookTramp[i+1] = TrampJump[1];
HookTramp[i+2] = TrampJump[2];
HookTramp[i+3] = TrampJump[3];
HookTramp[i+4] = TrampJump[4];
break;
}
}
VirtualProtectEx(GetCurrentProcess(), MsgBoxTramp, 25, OldProtect, NULL);
}
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason,
LPVOID lpvReserved )
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
if(!HOOKED)
{
HookMsgBox();
HOOKED = true;
}
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
BobS0327,
Thank you, already managed how to hook the function, now a little help with encryptation
I want to use RSA to Encrypt/decrypt packets, it'll be secure?
I'm really not sure that RSA is that secure. It'll probably be fine if you're *ONLY* dealing with script kiddies. It's my understanding that freeware utilities exist which can compromise RSA up to 256 bits.
I'm a strong proponent of AES since I'm somewhat associated with the security industry which caters to U.S. public sector organizations. Which BTW, uses AES quite extensively. Also, I have an application that communicates with internet connected security\automation controllers which uses AES 128 bit Electronic Code Book (ECB) to encrypt/decrypt packet payload data and I'd be willing to share code, ideas etc. with you.
As far as I know, the RSA algorithm has not yet been broken in the public literature, but 256 bit RSA keys for a real world application is laughable. A typical minimum is 1024 bit keys.Quote:
I'm really not sure that RSA is that secure. It'll probably be fine if you're *ONLY* dealing with script kiddies. It's my understanding that freeware utilities exist which can compromise RSA up to 256 bits.
That's surprising, since you apparently are not aware that RSA is a public key cryptosystem while AES (Rijndael) is a symmetric key cryptosystem, so comparing AES and RSA is comparing apples to oranges (or rambutans, if you prefer). 256 bit AES keys are industry standard, 256 bit RSA keys are not.Quote:
I'm a strong proponent of AES since I'm somewhat associated with the security industry which caters to U.S. public sector organizations.
That said, I think that AES is more suitable in this case, but not being an expert I would rather not make any specific recommendations.
> I want to use RSA to Encrypt/decrypt packets, it'll be secure?
That's a "quality of implementation" issue.
http://www.schneier.com/blog/archive...ghouse_le.html
Blah Blah AES Blah Blah - but implemented by morons.
Or in other words, "Nice castle, shame about the foundations being quick-sand".
This contract was finally let on March 3rd, 2008. So, now if you walk into any SSA office in the nation and ask how your personally identifiable information is encrypted/decrypted, the clerk will tell you that AES is used. Over 90% of the proposals were AES offerings. I honestly can't remember any RSA offerings for this type of endeavor on either the State or Federal level.
It's my understanding that RSA is primarily used in eCommerce, such as credit card transactions etc. I don't get involved in eCommerce. My area is in the systems networking infrastructure. So, based upon my experience on how AES is extensively used for file/data encryption/decryption and the fact that AES is popular for packet encyption/decryption in the commercial security controller industry which the OP wants to do, I suggested AES.
That is because RSA, or pretty much any public key cryptosystem, would be unsuitable for such encryption since they tend to be slower and one only needs a secret key. This is different from saying that RSA is snake oil.Quote:
I honestly can't remember any RSA offerings for this type of endeavor on either the State or Federal level.
I agree with your suggestion, but then I lack the professional qualifications (at the moment :p) for my agreement to mean much.Quote:
So, based upon my experience on how AES is extensively used for file/data encryption/decryption and the fact that AES is popular for packet encyption/decryption in the commercial security controller industry which the OP wants to do, I suggested AES.