Small HackShield Signatures ByPass :)

[MRx86™]

P.S Warning if you read this topic, you can detect A BIG BULLSHIT FROM RAZ9R

HackShield Small Signatures ByPass

What does it do ?
we intercept hackshield api call, through themida api Virtualization and we place our own hook!

any problem of detection with 10501?
no thanks, no more!

Code contain nothing of special but a safe place for hook!
And yea hard to say but hackshield still scanning with this retarded method!

MEMORY_BASIC_INFORMATION MBInfo;   // Global Define

SIZE_T  ( WINAPI  * oVirtualQuery ) ( LPCVOID lpAddress,PMEMORY_BASIC_INFORMATION lpBuffer,SIZE_T dwLength  );

__declspec(noinline)
SIZE_T WINAPI nVirtualQuery ( LPCVOID lpAddress,PMEMORY_BASIC_INFORMATION lpBuffer,SIZE_T dwLength )
{
	 _asm pushad

	  SIZE_T hRet = oVirtualQuery(lpAddress,lpBuffer,dwLength);

	  if ( lpAddress > (PVOID*)MBInfo.BaseAddress && lpAddress < (PVOID*)MBInfo.BaseAddress + MBInfo.RegionSize )  // Our Dll Range :) 
	  {
		// Telling HackShield they scanning bad regions and that regions does not contain something :)
		lpBuffer->AllocationProtect    = PAGE_NOACCESS;
		lpBuffer->RegionSize           = 0x1000;
		lpBuffer->State                = MEM_FREE;
		lpBuffer->Protect              = 0;
		lpBuffer->Type                 = MEM_PRIVATE;             
	  } 

	 _asm popad

     return hRet;
}


DWORD WINAPI  Init ( LPVOID lpArg )
{
       while(!GetModuleHandle("EhSvc.dll"))
             Sleep(300);

          BYTE dwPTRVirtualQuery [] = { 0xFF,0x15,0x00,0x00,0x00,0x00,0x85,0xC0,0x0F,0x84,0x00,0x00,0x00,0x00,0x33,0xDB };
       DWORD dwHSVirtualQuery = tool->FindPattern((DWORD)GetModuleHandle("EhSvc.dll"),0x15A000,dwPTRVirtualQuery,"xx????xxxx????xx",2,true);
  
        if ( dwHSVirtualQuery )
        {                    
            // Hooking Function
            // we don't need VirtualProtect because hackshield didn't protect that memory range's where i place hook :)

            *(DWORD*)(&oVirtualQuery) = *(DWORD*)(dwHSVirtualQuery +0x4C);
            *(DWORD*)(dwHSVirtualQuery+0x4C) = (DWORD)(&nVirtualQuery);
             return 0;
        }
        return 1;
}

BOOL WINAPI DllMain ( HMODULE hDll, DWORD dwReason, LPVOID lpReserved )
{
     if( dwReason == DLL_PROCESS_ATTACH )
     {    
          VirtualQuery((void*)(hDll),&MBInfo,sizeof(MBInfo));
          if ( !MBInfo.BaseAddress || !MBInfo.RegionSize )
              return FALSE;

          
                  CreateThread(NULL,NULL,Init,NULL,NULL,NULL);

         }
     return TRUE;
}

All Creditz for it going TheBoss ( Skype : GHTheBoss )
Some thanks going to disav0w for some idea about signatures functionaly

Have a nice day guys!

[Raz9r]

First of all, there is a sticky thread for stuff like this.
Second, there are multiple issues with this:
– Hackshield is still going to detect this after a while through another method. Any cheat using this will get its users banned.
– Modifying any function related to virtual memory (page) management will both be detected by AntiVirus Systems and cause major lag.
– Your code has a memory leak.

[MRx86™]

Originally Posted by Raz9r

First of all, there is a sticky thread for stuff like this.
Second, there are multiple issues with this:
– Hackshield is still going to detect this after a while through another method. Any cheat using this will get its users banned.
– Modifying any function related to virtual memory (page) management will both be detected by AntiVirus Systems and cause major lag.
– Your code has a memory leak.

What other method is hackshield using for scan throught memory? Let me teach you something about hackshield!

Hackshield is quering all memory throught a loop(using virtualquery), checking for noaccess pages and scanning with their own findpattern!

Memory leak ? Where it is? And remember that i wrote this fast on the "notepad "


Are you firing with solar cannon?


Regards 22Jays22

Btw raz9r thanks for my new signatures

[Raz9r]

Originally Posted by 22jays22

What other method is hackshield using for scan throught memory? Let me teach you something about hackshield!

Hackshield actively checks against bypasses like yours and silently reports them.

Originally Posted by 22jays22

Hackshield is quering all memory throught a loop(using virtualquery), checking for noaccess pages and scanning with their own findpattern!

Yeah, it sure does. That's why your code works. But it's also silently failing, because Hackshield knows about such methods. Your try is not a first, King7, since people have been doing this for years now.

Originally Posted by 22jays22

Memory leak ? Where it is? And remember that i wrote this fast on the notepad "

Read up on both calling conventions and the LPTHREAD_START_ROUTINE function pointer typedef.

Originally Posted by 22jays22

Are you firing with solar cannon?

I'm utterly confused. Did your english not get better at all over all these years, King7?

[MRx86™]

Originally Posted by Raz9r

Hackshield actively checks against bypasses like yours and silently reports them.


Yeah, it sure does. That's why your code works. But it's also silently failing, because Hackshield knows about such methods. Your try is not a first, King7, since people have been doing this for years now.


Read up on both calling conventions and the LPTHREAD_START_ROUTINE function pointer typedef.



I'm utterly confused. Did your english not get better at all over all these years, King7?

Anyway to be honest i'm not even using this method.
Because i have enough dynamic byte to my dll to avoid any signature's, done to my cheats!
But wanted to give some tip to everyone!
may come handy for someone


anyway since you seems expert of memory leak can you explain me.
what's wrong in there? it's a calling conversion

[Raz9r]

Originally Posted by 22jays22

what's wrong in there? it's a calling conversion

Yeah, and you're casting

unsigned long (__stdcall *)(void*) to void (__cdecl *)(), which causes a memory leak upon the call.

[MRx86™]

Originally Posted by Raz9r

Yeah, and you're casting

unsigned long (__stdcall *)(void*) to void (__cdecl *)(), which causes a memory leak upon the call.

NO MATTER WHAT CONVERSION YOU PUT, THE CODE WILL STILL BE

.text:1001B3BB push 0
.text:1001B3BD push 0
.text:1001B3BF push 0
.text:1001B3C1 push offset sub_10018F30
.text:1001B3C6 push 0
.text:1001B3C8 push 0
.text:1001B3CA call ds:CreateThread

GO TO SLEEP

[supercannon1337]

Originally Posted by Raz9r

Yeah, and you're casting

unsigned long (__stdcall *)(void*) to void (__cdecl *)(), which causes a memory leak upon the call.

y are u the skrilled codenz #c style <reinterpret_cast> guy?
we are not in 64 bit context that conversion are unsafe and doing (LPTHREAD_START_ROUTINE) will just make the same call as any other thing(3rd param push StartAddress), so you better come back in vs 2013 and keep coding with your reinterpret_cast friend.

by the way, it's true ahnlab is improving hackshield and for do that they daily visit known coding forums & cheats

Originally Posted by raz9r

– Modifying any function related to virtual memory (page) management will both be detected by AntiVirus Systems and cause major lag.

i also missed that part .-.

[+Yazzn]

@suppercannon Raz9r's post has nothing to do with whether to use reinterpret_cast or c-style casts. Read again pls.

[supercannon1337]

Originally Posted by Peter File

@suppercannon Raz9r's post has nothing to do with whether to use reinterpret_cast or c-style casts. Read again pls.

when i wrote about reinterpret_cast i didnt mean anything in this topic but i saw some of his work around(hmm maybe i am confusing with another fanboy) and they were all full of reinterpret_cast

@Raz9r tell me what this conversion is allocating which later is not being deallocated(http://en.wikipedia.org/wiki/Memory_leak, read first 2 lines)

[MRx86™]

Originally Posted by Peter File

@suppercannon Raz9r's post has nothing to do with whether to use reinterpret_cast or c-style casts. Read again pls.

Yazzn
MEMORY LEAK HAS BEEN DETECT DUE TO BULLSHIT OF RAZ9R TUM TUM TUM TUM

Originally Posted by supercannon1337

when i wrote about reinterpret_cast i didnt mean anything in this topic but i saw some of his work around(hmm maybe i am confusing with another fanboy) and they were all full of reinterpret_cast

@Raz9r tell me what this conversion is allocating which later is not being deallocated(Memory leak - Wikipedia, the free encyclopedia, read first 2 lines)

man just wasting your time to reply to this kid, got already PwN on before!

[Raz9r]

It's quite simple where the memory leak comes from.
You wrote a function that expects no arguments and follows a calling convention expecting the caller to do the cleanup work.
You pass that function to another function which expects a function accepting one 4 byte argument with a calling convention expecting the callee to do the cleanup work.

This makes up for a classic memory leak, where 4 bytes get pushed to the stack and are expected to be cleaned up by the callee, which itself expects nothing (and even if it did, it would still expect the caller to do the cleanup work).

Calling convention refers to who is doing the cleanup of the stack; caller or callee. Better remember that, dude.

[supercannon1337]

Originally Posted by Raz9r

It's quite simple where the memory leak comes from.
You wrote a function that expects no arguments and follows a calling convention expecting the caller to do the cleanup work.
You pass that function to another function which expects a function accepting one 4 byte argument with a calling convention expecting the callee to do the cleanup work.

This makes up for a classic memory leak, where 4 bytes get pushed to the stack and are expected to be cleaned up by the callee, which itself expects nothing (and even if it did, it would still expect the caller to do the cleanup work).

Calling convention refers to who is doing the cleanup of the stack; caller or callee. Better remember that, dude.

i understood what you are sayng, its just that you are following a wrong theory cause this is not causing any memory leak, your "4 bytes pushed have to be cleaned" is wrong.
open up a disassembler, do this code:

DWORD  WINAPI raz9rreinterpretcastfanboy(LPVOID)
{

return 0;
}
CreateThread(0, 0, raz9rreinterpretcastfanboy, 0, 0, 0);

and this:

void raz9rreinterpretcastfanboy()
{

}
CreateThread(0, 0, (LPTHREAD_START_ROUTINE)raz9rreinterpretcastfanboy, 0, 0, 0);

disassemble your pe and compare codes within the 2 compiles... it is the same but in one there should be a fantastic memory leak and in the other no.. how comes??

i put this example because seems that with you we need the retarded ways for make you understand something

a tip for the future, instead of concentrating removing calling conventions, just concentrate on freeing heap and global allocated unmanaged memory(malloc/heapalloc for example), except if you are coding your executable in 64 bit architecture, than yes, you must care about calling convention and alot.

i wont ask you anymore your theory about AVs detecting modifies etc etc.. cause i already understood to who i am talking to

[Raz9r]

You're clearly missing the point that there can indeed be a memory leak on the stack. The callee increases the stack pointer, in a way such that the stack pointee is the pushed argument. The callee expects the caller to decrease the stack pointer afterwards. This will never happen, because you're using the wrong calling convention.

Managing the stack can be as important as managing the heap, which is a lesson to be learnt when playing around with a running process.

When running the code given by you and disassembling that, it can be seen quite clearly that, despite not having an immediate effect, the stack is bigger than in the first case.

Please back any future claims with a reference to the official standard and/or sources like compiler manuals and isocpp. Thank you.

[supercannon1337]

@Raz9r you are saying theory, i am tryng to show you whats going on in output at createthread @ lpthread_start_routine and without calling convention.
What you are sayng there, should be something you have read/studied THEORICALLY, but in facts, as you can see when compiling THIS code(createthread @ lpthread_start_routine and create thread without calling convention), the output will be the same. So if there WAS A MEMORY LEAK with the calling convention, there is even without(or maybe there isnt any memory leak??).
My codes given are providing SAME results(all same opcodes), no difference of stack like you are sayng.

but i guess for you, still, LPTHREAD_START_ROUTINE causes a memory leak.. ok man keep it up, just wanted to notice others that 3/3 of the points you listed in 1st reply are bullshits.


I am referencing @ visual studio 2013 btw