Printable View
Hello, how i can encrypt packets sends of a program...
I'm attaching the dll to program, but i dont know how to encrypt all packets before the program send it.
i know that i need to attach a function to a windows function, but i dont know how do it...
if anyone can just post a snippet (the attaching of the function, and a simple encrypt method)
Thank you.
You mean like the same way the secure sockets layer works?
Hello,
I dont know what you mean, but i'll try to explain it more...
A program, any... to send anything to internet via TCP, use a function of windows that i dont remember the name, ...
so, i need that my dll, when attach to a process, encrypt all packets before the program send it, understand?
PROGRAM -> WINDOWS API (SOCKETS) -> SEND
after hooked
PROGRAM -> WINDOWS API (SOCKETS) -> MY DLL FUNC TO ENCRYPT IT -> SEND
or
PROGRAM -> MY DLL FUNC TO ENCRYPT IT -> WINDOWS API (SOCKETS) -> SEND
Thank you.
Sorry, but i cant use it, i need a code to hook send/recv functions ...
My problem is people using WPE PRO (Packet Editor) to cheat on my program, this program (WPE) load and hook a dll on my program, so a alternative method is detecting when a DLL is loaded in memory, and unload it if isn't allowed, anyone have a piece of code to detect and unhook a DLL?
Remember, i dont have the sources, so it need to be using windows API functions.
That's easy. Unfortunately, such methods are only temporary until someone cracks them.
I think the safest method is dynamic loading. By using dynamic loading, you can find and store function pointers to all your necessary functions and use those instead. Now, since you have stored the address to the functions already, the app won't be affected if some other program overwrites the export table in the dll (the most common way of hooking).
The only way they could break this is by overwriting your function pointers, which might be like finding a needle in a haystack.
There may be other safeguards such as VirtualProtect, but I don't know of any such methods currently and I don't think they'll be necessary. At least yet.
I'm confused: It's your program, but...Quote:
Originally Posted by splintter
... you don't have the sources. Usually, when it's your program, you have the sources or at least access to someone that does in some form or another, e.g. a service contract or some such to a third party supplier.Quote:
Remember, i dont have the sources, so it need to be using windows API functions.
Also, if you encrypt the data one end, you obviously will need to decrypt the other end - so you need access to both ends to make any headway here.
Edit: And, as Elysia hints, if you do use a hooking function, then what's preventing someone else from hooking your hook, and modifying the packet before it's encrypted?
--
Mats
Yes, the program is a third party software(i paid), the contract ended, and i loose the sources on a hardware failure...
This will be the last try before recontract anyone or rewrite it by myself....
The people that uses WPE on my program are only script kiddies, that dont know anything about reverse enginning or cracking... they just load WPE and Use it.
So, i think that hooking send/recv functions and encrypting/decripting it (sources from server i have from a backup :S), and do something like a thread to unhook WPE when it loads, will solve my problem..
Anyone?
I really need help on this, did not want the COMPLETE CODE, just the functions and a exemple :|
Here is a link to AES (Rijndael) algorithms used for encryption/decryption.Quote:
Originally Posted by splintter
I'm not sure writing a hook is such a good idea to defeat the packet editor. Anyone with basic rootkit experience can identify any installed hook. Search the "nefarious" sites and you'll find a lot of examples of how to identify any installed hook.
Also, I would assume that the packet editor is using the TCP/IP stack to capture the packets. Why not use raw sockets to defeat the packet editor?
Hello BobS0327,
I'll look at AES.
What you mean by RAW packets? can you show a exemple? sorry, but my english is bad, and i didn't understand what you mean...
Here is a link to a CodeProject article on raw sockets.
Anyway,
RAW Sockets will be blocked by some workstations firewalls and routers.
I need to hook and encrypt send/recv. Encryptation can be simple.
I was about 1 week asking for help, many says some arguments, but no one help-me with a snippet (Yes, i'm not a good programmer, my english is sucks, but i learn more by see a code and modify it).
I did not want the complete code, just a exemple and i'll try by myself.
Hooking send/receive for a particular application is FAR from trivial, and as I explained earlier, if there is sufficient interest to bypass your security, someone will find a way to hook before your hook, so it's a lot of effort for a potentially small benefit.
--
Mats
Yes, but who is using WPE is end user, people that dont know anything about programming, just open WPE, record the packet, and send it with a loop.
Hooking this, encrypting send and decrypting recv will stop it, and i can change the encrypt key every week by auto update, so if anyone REALLY try to bypass it, i change the method.
Using this, encrypting executable by using anything like PE Compressor, will stop MY problem.
i'm seeing that no one will help me, i'll give up...
Have see how people dont remember when yourself are a newbie (not noob) and need to do anything that is above your know, and no one want to help.
Sincerly,
Splinter.
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.Quote:
Originally Posted by splintter
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.Quote:
Originally Posted by splintter
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.