Return of the crapshield!

Whatever you want here. Just make sure it's off topic. Which...I guess if the topic is being off topic, then it means you should be on topic. Understand?
Post Reply
Message
Author
User avatar
MiesterMan
Posts: 543
Joined: Tue Jul 06, 2010 9:15 pm
Location: Between the Second and Third Circles of Hell

Return of the crapshield!

#1 Post by MiesterMan » Sun Mar 11, 2012 7:29 am

So, I figured I'd poke around and see what else I've got to play. "Oh, I've got 4story, lets' look at that archaic pos and see we can do." Nope, it's got a crapshield and I dunno how to get around those. Well, may as well take a look at Gate of Anderon now (US version of 4Story), well hell it's got another crapshield. I already can't touch Argo cause it has a crapshield. Right now we're suffering from the crapshield on Eligium....

Crapshield list:
Argo - Hack Shield
Eligium - Game Protect Kit
4Story - Game Guard
Gates of Anderon - Hack Shield
Forsaken World - Who the hell knows?

Its as if these wicked minded corporate thugs don't want us to have control of our own computers anymoar! I even ran into a FPS that required Punk Buster, I hadn't even heard that name in years... There are countless other games with crapshields on them now and it looks like the virus is just going to keep spreading. Though, like most devastating viruses that kill things, we have no real cure. All we can do is treat the symptoms and hope it won't relapse in a week (which it almost always does).

I have one good tutorial about getting around gameguard but it doesn't give me a great deal of information outside the step by step of it. If anyone knows of a good resource, one that won't give my computer aids, herpes, or other TTDs (tcp/ip transferable diseases), please PM me or get admins permission to post the link here.

It was hard enough trying to make these games tolerable before "they" went the extra mile to make them intolerable. We can't let coporate beuracracies rule over our freedoms anymore!

BTW, I'm really asking for some help here. I just can't help but want to rant though, kinda frustrating to finally get some times to work on this and be completely blocked by ... yea.

User avatar
Administrator
Site Admin
Posts: 5306
Joined: Sat Jan 05, 2008 4:21 pm

Re: Return of the crapshield!

#2 Post by Administrator » Sun Mar 11, 2012 2:45 pm

Step 1, you need to figure out if the executable is packed and encrypted or not. Open it up in Olly and copy the first ~20 lines and post them here.

User avatar
MiesterMan
Posts: 543
Joined: Tue Jul 06, 2010 9:15 pm
Location: Between the Second and Third Circles of Hell

Re: Return of the crapshield!

#3 Post by MiesterMan » Sun Mar 11, 2012 7:55 pm

Administrator wrote:Step 1, you need to figure out if the executable is packed and encrypted or not. Open it up in Olly and copy the first ~20 lines and post them here.
I believe it's packed based on the error message I see in game. When an image file that would be used in game isn't there the console is spammed with a directory and filename that doesn't exist (whereas there are "data" files in one of the directories).

As for the first.. After running the executable which is 24kb it stops here in between these two funcs where I marked it:

Code: Select all

CPU Disasm
Address   Hex dump          Command                                  Comments
004019C2  /.  66:813D 00004 CMP WORD PTR DS:[Eligium.<STRUCT IMAGE_D
004019CB  |.  74 04         JE SHORT Eligium.004019D1
004019CD  |>  33C0          XOR EAX, EAX
004019CF  |.  EB 51         JMP SHORT Eligium.00401A22
004019D1  |>  A1 3C004000   MOV EAX, DWORD PTR DS:[Eligium.40003C]
004019D6  |.  81B8 00004000 CMP DWORD PTR DS:[EAX+Eligium.<STRUCT IM
004019E0  |.^ 75 EB         JNE SHORT Eligium.004019CD
004019E2  |.  0FB788 180040 MOVZX ECX, WORD PTR DS:[EAX+Eligium.4000
004019E9  |.  81F9 0B010000 CMP ECX, 10B
004019EF  |.  74 1B         JE SHORT Eligium.00401A0C
004019F1  |.  81F9 0B020000 CMP ECX, 20B
004019F7  |.^ 75 D4         JNE SHORT Eligium.004019CD
004019F9  |.  83B8 84004000 CMP DWORD PTR DS:[EAX+Eligium.400084], 0
00401A00  |.^ 76 CB         JBE SHORT Eligium.004019CD
00401A02  |.  33C9          XOR ECX, ECX
00401A04  |.  3988 F8004000 CMP DWORD PTR DS:[EAX+Eligium.4000F8], E
00401A0A  |.  EB 11         JMP SHORT Eligium.00401A1D
00401A0C  |>  83B8 74004000 CMP DWORD PTR DS:[EAX+Eligium.400074], 0 ; ASCII ".\r\r\n$"
00401A13  |.^ 76 B8         JBE SHORT Eligium.004019CD
00401A15  |.  33C9          XOR ECX, ECX
00401A17  |.  3988 E8004000 CMP DWORD PTR DS:[EAX+Eligium.4000E8], E
00401A1D  |>  0F95C1        SETNE CL
00401A20  |.  8BC1          MOV EAX, ECX
00401A22  |>  6A 02         PUSH 2
00401A24  |.  A3 9C504000   MOV DWORD PTR DS:[Eligium.40509C], EAX
00401A29  |.  FF15 88304000 CALL NEAR DWORD PTR DS:[<&MSVCR80.__set_
00401A2F  |.  6A FF         PUSH -1
00401A31  |.  FF15 8C304000 CALL NEAR DWORD PTR DS:[<&MSVCR80._encod
00401A37  |.  59            POP ECX
00401A38  |.  59            POP ECX
00401A39  |.  A3 00544000   MOV DWORD PTR DS:[Eligium.405400], EAX
00401A3E  |.  A3 04544000   MOV DWORD PTR DS:[Eligium.405404], EAX
00401A43  |.  FF15 90304000 CALL NEAR DWORD PTR DS:[<&MSVCR80.__p__f
00401A49  |.  8B0D E4534000 MOV ECX, DWORD PTR DS:[Eligium.4053E4]
00401A4F  |.  8908          MOV DWORD PTR DS:[EAX], ECX
00401A51  |.  FF15 94304000 CALL NEAR DWORD PTR DS:[<&MSVCR80.__p__c
00401A57  |.  8B0D E0534000 MOV ECX, DWORD PTR DS:[Eligium.4053E0]
00401A5D  |.  8908          MOV DWORD PTR DS:[EAX], ECX
00401A5F  |.  A1 98304000   MOV EAX, DWORD PTR DS:[<&MSVCR80._adjust
00401A64  |.  8B00          MOV EAX, DWORD PTR DS:[EAX]
00401A66  |.  A3 F4534000   MOV DWORD PTR DS:[Eligium.4053F4], EAX
00401A6B  |.  E8 CD020000   CALL Eligium.00401D3D                    ; [Eligium.00401D3D
00401A70  |.  E8 8C040000   CALL Eligium.00401F01                    ; [Eligium.00401F01
00401A75  |.  833D 2C504000 CMP DWORD PTR DS:[Eligium.40502C], 0
00401A7C  |.  75 0C         JNE SHORT Eligium.00401A8A
00401A7E  |.  68 011F4000   PUSH Eligium.00401F01                    ; Entry point of procedure
00401A83  |.  FF15 9C304000 CALL NEAR DWORD PTR DS:[<&MSVCR80.__setu
00401A89  |.  59            POP ECX
00401A8A  |>  E8 49040000   CALL Eligium.00401ED8
00401A8F  |.  833D 28504000 CMP DWORD PTR DS:[Eligium.405028], -1
00401A96  |.  75 09         JNE SHORT Eligium.00401AA1
00401A98  |.  6A FF         PUSH -1
00401A9A  |.  FF15 A0304000 CALL NEAR DWORD PTR DS:[<&MSVCR80._confi
00401AA0  |.  59            POP ECX
00401AA1  |>  33C0          XOR EAX, EAX
00401AA3  \.  C3            RETN

00401AA4  /.  E8 5B040000   CALL Eligium.00401F04         <---------- This is where it pauses after execution
00401AA9  \.^ E9 35FDFFFF   JMP Eligium.004017E3

00401AAE  />  55            PUSH EBP
00401AAF  |.  8BEC          MOV EBP, ESP
00401AB1  |.  81EC 28030000 SUB ESP, 328
00401AB7  |.  A3 B8514000   MOV DWORD PTR DS:[Eligium.4051B8], EAX
00401ABC  |.  890D B4514000 MOV DWORD PTR DS:[Eligium.4051B4], ECX
00401AC2  |.  8915 B0514000 MOV DWORD PTR DS:[Eligium.4051B0], EDX
00401AC8  |.  891D AC514000 MOV DWORD PTR DS:[Eligium.4051AC], EBX
00401ACE  |.  8935 A8514000 MOV DWORD PTR DS:[Eligium.4051A8], ESI
00401AD4  |.  893D A4514000 MOV DWORD PTR DS:[Eligium.4051A4], EDI
00401ADA  |.  66:8C15 D0514 MOV WORD PTR DS:[Eligium.4051D0], SS     ; Superfluous operand size prefix
00401AE1  |.  66:8C0D C4514 MOV WORD PTR DS:[Eligium.4051C4], CS     ; Superfluous operand size prefix
00401AE8  |.  66:8C1D A0514 MOV WORD PTR DS:[Eligium.4051A0], DS     ; Superfluous operand size prefix
00401AEF  |.  66:8C05 9C514 MOV WORD PTR DS:[Eligium.40519C], ES     ; Superfluous operand size prefix
00401AF6  |.  66:8C25 98514 MOV WORD PTR DS:[Eligium.405198], FS     ; Superfluous operand size prefix
00401AFD  |.  66:8C2D 94514 MOV WORD PTR DS:[Eligium.405194], GS     ; Superfluous operand size prefix
00401B04  |.  9C            PUSHFD
00401B05  |.  8F05 C8514000 POP DWORD PTR DS:[Eligium.4051C8]
00401B0B  |.  8B45 00       MOV EAX, DWORD PTR SS:[LOCAL.0]
00401B0E  |.  A3 BC514000   MOV DWORD PTR DS:[Eligium.4051BC], EAX
00401B13  |.  8B45 04       MOV EAX, DWORD PTR SS:[ARG.RETADDR]
00401B16  |.  A3 C0514000   MOV DWORD PTR DS:[Eligium.4051C0], EAX
00401B1B  |.  8D45 08       LEA EAX, [ARG.1]
00401B1E  |.  A3 CC514000   MOV DWORD PTR DS:[Eligium.4051CC], EAX
00401B23  |.  8B85 E0FCFFFF MOV EAX, DWORD PTR SS:[LOCAL.200]
00401B29  |.  C705 08514000 MOV DWORD PTR DS:[Eligium.405108], 10001
00401B33  |.  A1 C0514000   MOV EAX, DWORD PTR DS:[Eligium.4051C0]
00401B38  |.  A3 BC504000   MOV DWORD PTR DS:[Eligium.4050BC], EAX
00401B3D  |.  C705 B0504000 MOV DWORD PTR DS:[Eligium.4050B0], C0000
00401B47  |.  C705 B4504000 MOV DWORD PTR DS:[Eligium.4050B4], 1
00401B51  |.  A1 18504000   MOV EAX, DWORD PTR DS:[Eligium.405018]
00401B56  |.  8985 D8FCFFFF MOV DWORD PTR SS:[LOCAL.202], EAX
00401B5C  |.  A1 1C504000   MOV EAX, DWORD PTR DS:[Eligium.40501C]
00401B61  |.  8985 DCFCFFFF MOV DWORD PTR SS:[LOCAL.201], EAX
00401B67  |.  FF15 34304000 CALL NEAR DWORD PTR DS:[<&KERNEL32.IsDeb
00401B6D  |.  A3 00514000   MOV DWORD PTR DS:[Eligium.405100], EAX
00401B72  |.  6A 01         PUSH 1
00401B74  |.  E8 1F040000   CALL <JMP.&MSVCR80._crt_debugger_hook>
00401B79  |.  59            POP ECX
00401B7A  |.  6A 00         PUSH 0
00401B7C  |.  FF15 38304000 CALL NEAR DWORD PTR DS:[<&KERNEL32.SetUn
00401B82  |.  68 E4314000   PUSH OFFSET Eligium.004031E4
00401B87  |.  FF15 3C304000 CALL NEAR DWORD PTR DS:[<&KERNEL32.Unhan
00401B8D  |.  833D 00514000 CMP DWORD PTR DS:[Eligium.405100], 0
00401B94  |.  75 08         JNE SHORT Eligium.00401B9E
00401B96  |.  6A 01         PUSH 1
00401B98  |.  E8 FB030000   CALL <JMP.&MSVCR80._crt_debugger_hook>
00401B9D  |.  59            POP ECX
00401B9E  |>  68 090400C0   PUSH C0000409
00401BA3  |.  FF15 10304000 CALL NEAR DWORD PTR DS:[<&KERNEL32.GetCu
00401BA9  |.  50            PUSH EAX
00401BAA  |.  FF15 40304000 CALL NEAR DWORD PTR DS:[<&KERNEL32.Termi
00401BB0  |.  C9            LEAVE
00401BB1  \.  C3            RETN
00401BB2   $- FF25 CC304000 JMP NEAR DWORD PTR DS:[<&MSVCR80.?termin
The first 20 lines of the executable when viewed:

Code: Select all

File C:\Games\Eligium\mw2_bin\Eligium.exe
Address   Hex dump          Command                                  Comments
00000000    4D              DEC EBP
00000001    5A              POP EDX
00000002    90              NOP
00000003    0003            ADD BYTE PTR DS:[EBX], AL
00000005    0000            ADD BYTE PTR DS:[EAX], AL
00000007    000400          ADD BYTE PTR DS:[EAX+EAX], AL
0000000A    0000            ADD BYTE PTR DS:[EAX], AL
0000000C    FF              DB FF                                    ; Unknown command
0000000D    FF00            INC DWORD PTR DS:[EAX]
0000000F    00B8 00000000   ADD BYTE PTR DS:[EAX], BH
00000015    0000            ADD BYTE PTR DS:[EAX], AL
00000017    0040 00         ADD BYTE PTR DS:[EAX], AL
0000001A    0000            ADD BYTE PTR DS:[EAX], AL
The first 20 lines past 400000:

Code: Select all

CPU Disasm
Address   Hex dump          Command                                  Comments
00400000  /.  4D5A          DW 5A4D                                  ; DOS_Signature[2] = "MZ"
00400002  |.  9000          DW 90                                    ; DOS_PartPag = 144.
00400004  |.  0300          DW 3                                     ; DOS_PageCnt = 3
00400006  |.  0000          DW 0                                     ; DOS_ReloCnt = 0
00400008  |.  0400          DW 4                                     ; DOS_HdrSize = 4
0040000A  |.  0000          DW 0                                     ; DOS_MinMem = 0
0040000C  |.  FFFF          DW 0FFFF                                 ; DOS_MaxMem = 65535.
0040000E  |.  0000          DW 0                                     ; DOS_RelSS = 0
00400010  |.  B800          DW 0B8                                   ; DOS_ExeSP = 0B8
00400012  |.  0000          DW 0                                     ; DOS_ChkSum = 0
00400014  |.  0000          DW 0                                     ; DOS_ExeIP = 0
00400016  |.  0000          DW 0                                     ; DOS_RelCS = 0
00400018  |.  4000          DW 40                                    ; DOS_RelocOffset = 40
0040001A  |.  0000          DW 0                                     ; DOS_Overlay = 0
0040001C  |.  0000          DW 0                                     ; DOS_Reserved1[4] = 00000000
0040001E  |.  0000          DW 0
00400020  |.  0000          DW 0
00400022  |.  0000          DW 0
00400024  |.  0000          DW 0                                     ; DOS_OEM_ID = 0
00400026  |.  0000          DW 0                                     ; DOS_OEM_Info = 0
00400028  |.  0000          DW 0                                     ; DOS_Reserved2[10.] = 00000000
0040002A  |.  0000          DW 0
0040002C  |.  0000          DW 0
0040002E  |.  0000          DW 0
00400030  |.  0000          DW 0
00400032  |.  0000          DW 0
00400034  |.  0000          DW 0
00400036  |.  0000          DW 0
00400038  |.  0000          DW 0
0040003A  |.  0000          DW 0
0040003C  \.  00010000      DD 00000100                              ; DOS_PEOffset = 100

User avatar
Administrator
Site Admin
Posts: 5306
Joined: Sat Jan 05, 2008 4:21 pm

Re: Return of the crapshield!

#4 Post by Administrator » Sun Mar 11, 2012 9:21 pm

If you see any 'unknown command' lines in the executable, chances are it is packed. Unfortunately, unpacking and decrypting things isn't my strong point, so there is little information I can provide.

User avatar
MiesterMan
Posts: 543
Joined: Tue Jul 06, 2010 9:15 pm
Location: Between the Second and Third Circles of Hell

Re: Return of the crapshield!

#5 Post by MiesterMan » Mon Mar 12, 2012 5:17 am

I was using 2.00 for this, for some reason things look diferent in 1.1 so I'll pull that up for you in a bit.

User avatar
MiesterMan
Posts: 543
Joined: Tue Jul 06, 2010 9:15 pm
Location: Between the Second and Third Circles of Hell

Re: Return of the crapshield!

#6 Post by MiesterMan » Thu Mar 22, 2012 9:50 am

I wanted to know what DLL I needed to write the fix for as I'd only ever heard of ntdll that has the debug functions but I wasn't able to see any names after I loaded the executable for Eligium. Now here's the funny part, I loaded the executable and while loading I could see the memory in the disassembler. It had stopped at an entry point but I could see everything there, no window was open though.

When I click continue it continues to load and while the crapshield is loading I can still see the memory in the disassembler but as soon as crapshield is done, it said "closing thread" then something able unable to aquire "handle". The game is running but I can't see the memory.

Now I'm convinced, it's not so complicated as encrypted memory (which would be silly as that's a performance hit and game devs wouldn't accept that) but instead virtual shade being pulled over the memory we want to view. The memory is there but we can't see it. Freaking annoying but I think it should be something that can be worked around.

If you have any ideas plz let me know, I'll update if I find anything new.

User avatar
Administrator
Site Admin
Posts: 5306
Joined: Sat Jan 05, 2008 4:21 pm

Re: Return of the crapshield!

#7 Post by Administrator » Thu Mar 22, 2012 11:08 am

No, it isn't encrypting the memory. That would be horribly inefficient and useless. Instead, the "crapshield", as you have so taken to calling it, is subverting the Windows kernel and hooking the functions required to read and write process memory. In these trampolines, they check if the handle is to the process that is to be protected, and, if so, return NULL, otherwise call the original function. What you would need to do is unpack the executable, patch some of the assembly (NOP the crapshield loading process, NOP/JMP the checks), then dump the resulting binary and run that.

You could, potentially, write your own DLL that would be emulate the original and be loaded instead. This is quite difficult to do and is easy to protect against (all they would have to do is change the encryption or move around event IDs). I wouldn't recommend it.

User avatar
MiesterMan
Posts: 543
Joined: Tue Jul 06, 2010 9:15 pm
Location: Between the Second and Third Circles of Hell

Re: Return of the crapshield!

#8 Post by MiesterMan » Thu Mar 22, 2012 11:29 am

Oh, all I was thinking to do was remove the hooks that blocked viewing memory. There is no macro system in the game so everything I'd want to do is strictly reading memory so I figured that would be enough (But I don't even know how to do that yet so it's still just in my head).

User avatar
3cmSailorfuku
Posts: 354
Joined: Mon Jan 21, 2008 6:25 pm

Re: Return of the crapshield!

#9 Post by 3cmSailorfuku » Fri Mar 23, 2012 8:33 pm

MiesterMan wrote:Oh, all I was thinking to do was remove the hooks that blocked viewing memory. There is no macro system in the game so everything I'd want to do is strictly reading memory so I figured that would be enough (But I don't even know how to do that yet so it's still just in my head).
You can try writing your own kernel driver that hooks the reading memory functions ( probably quits hs, but getpixel and other functions can be freed like this ) and protects them from being hooked by hackshield's driver ( if you want an easy solution ), but I honestly doubt this will still work with all games since it's dependant on how hackshield was integrated.
Forsaken World - Who the hell knows?
From what I remember it was packed with Armadillo, making it kinda iffy finding pointers, debugging and reading the memory consistenly. Probably added Xtrap now?

User avatar
BlubBlab
Posts: 948
Joined: Fri Nov 30, 2012 11:33 pm
Location: My little Pony cafe

Re: Return of the crapshield!

#10 Post by BlubBlab » Wed Dec 24, 2014 5:40 am

Okay I did some research before I posted here

I talked with admin about the same topic before in regrade to AA with very similar results. The way I see it code was injected into the kernel functions which redirect the calls or more likely put it simple

Code: Select all

if(myprocess_pid == handel.pid) 
return NULL;
Like admin I think mean since it is a lot more code in asm thinks aren't easy on top of that HS could try to test if it changes are still working in this case we don't delete the code we need to to expand it:

Code: Select all

if(process_pid == HS_pid && pid != my_pid ) 
return NULL;
The other way I thought is breaking through the chain of trust when you start HS it can't be running so you got your handel but admin meant that HS will check it parent process. So the only way would be injection a lot of code into the luncher first open from the luncher your own process, prepare a interprocess memory space on both sides, than you have to start the HS/Game process from the inside of the luncher and make a copy from the handle with target destination of your own process, than move the new handle to the prepared interprocess memory space than delete the injected code so that the hash values are fine again.

The problem with solution 2 is beside a lot of code you inject in it is that it has a very high race condition to work and it is still possible that HS still blocks the write and read operation regardless of having a valid handel.(besides can the hash be made return normal?)

I'm not an expert in all this so I thought my ways a little bit around it.
First it is possible that some MMO drooped using such shields because the licenses cost money and when the player base drops it is likely they will stop using it to spare money like DP did.

MMO with no Shields: all PWI MMOs I played, ROM, DP, PoE, DSO I think HDO has also no shield, Heartstone and LOL.

The other think is that with VM didn't work I heard but one day I would think what about this:
https://www.reactos.org/ This is a open source OS based on Windows currently on alpha but with this you could fully customize your OS 'windows' yourself e.g I could made a copy of the system calls in the kernal under other names to go around such nasty things.

The reason why this project exist is which each new version of Windows some program don't work any more and this cost companies money, the other thing is the companies must by the new version because MS stopped to support the old windows with update.

EDIT: wow I just fund out how too hock the kernel.....
Jack-of-all-trades, but master-of-only of a few :D

My Reps:
https://github.com/BlubBlab/Micromacro-with-OpenCV (My version of MM2 with OpenCV and for MS Visual Studio)
https://github.com/BlubBlab/rom-bot (rombot with no stop WP and advanced human emulation mode and some other extensions)
https://github.com/BlubBlab/Micromacro-2-Bot-Framework ( A work in progress )
My Tools : viewtopic.php?f=10&t=6226

User avatar
BlubBlab
Posts: 948
Joined: Fri Nov 30, 2012 11:33 pm
Location: My little Pony cafe

Re: Return of the crapshield!

#11 Post by BlubBlab » Tue Jan 06, 2015 8:09 am

Since I'm not playing Arche Age I won't looking much deeper on it but perhaps someone wants to pick up where I ended.

The reason why a kernel driver is needed is to go into the protection level and memory of the kernel.
The kernel32.dll and those function in it like OpenProcess(..) are on the user level.

The real kernel functions are to be found in the ntdll.dll unlike the other function you won't find a official API for it so you need to use http://www.dependencywalker.com/ and google or similar things.

To start to write a kernel driver http://msdn.microsoft.com/en-us/library ... 85%29.aspx


How Hooking works:http://en.wikipedia.org/wiki/Hooking when I understood it right you a function can be only hook once by changing the VMT(vtable). There are when things start to be complicated in theory you can undo this hooking by changing those to there normal values but you can also check if those hooks still there. So HS or whatever could check if its hooks still in place.

This is not unsolvable at least in theory you could simple prepare a 'false' function head and than jump into the real function behind the vmt call this way you would simple by-pass the hook and simple pipe the memory functions as driver functions to the outside. I'm not 100% sure this is possible but at least in theory this works. You will properly also need some asm knowledge and using inline asm to get this work..

I think at this point a lot of try and error will happen to get things work.

It is maybe a good idea to stealth your own driver: http://www.codeproject.com/Articles/327 ... -and-Files
Last edited by BlubBlab on Tue Aug 04, 2015 3:57 pm, edited 1 time in total.
Jack-of-all-trades, but master-of-only of a few :D

My Reps:
https://github.com/BlubBlab/Micromacro-with-OpenCV (My version of MM2 with OpenCV and for MS Visual Studio)
https://github.com/BlubBlab/rom-bot (rombot with no stop WP and advanced human emulation mode and some other extensions)
https://github.com/BlubBlab/Micromacro-2-Bot-Framework ( A work in progress )
My Tools : viewtopic.php?f=10&t=6226

User avatar
BlubBlab
Posts: 948
Joined: Fri Nov 30, 2012 11:33 pm
Location: My little Pony cafe

Re: Return of the crapshield!

#12 Post by BlubBlab » Tue Aug 04, 2015 12:15 am

I took a look inside this the last days but first I must say I have no time for it maybe admin can find it someday.

First I went back to MS examples first the old examples weren't there anymore only for VS 2015 so that they can push their new driver model for win 10, the same goes for the tools necessary for driver development for my VS 2012 professional edition but I found them one some download farm.(MS kit 8.0)

There are new examples but they aren't set free until now, some are about key interrupt generation, I went to this because of Skyforge just to take a look if there is a simple but also more general solution. Unfortunately with this less information there were no way but I ended up accidentally on CE's Homepage to find out that they also use their own kernel driver :shock: . This version has also a VM inside for I think to control the code execution since the source code is public we would only need take a look how they did it and make it more simplistic :ugeek: and added keyboards &mouse interrupts later + invisibility.

But I still not 100% sure even when someone find time should we do it because CE do it too?
When I think back the main reason why I was not 100% convinced was that I didn't want to see a catfight inside the kernel itself.

EDIT:Okay didn't get my car so I found gold I mean it http://www.codereversing.com/blog/archives/128
This should be how you access memory of a process from inside the kernel mode.....

EDIT2: Hm I getting closer : http://www.osronline.com/showthread.cfm?link=139268 and https://github.com/uri247/wdk80/tree/ma ... lution/exe
This is about simulation key presses inside Kernel mode , what is still missing is how can I talk to the driver.

Edit3 Okay last part found : https://msdn.microsoft.com/en-us/librar ... 85%29.aspx
http://www.codeproject.com/Articles/202 ... d-Device-D http://www.osronline.com/showThread.CFM?link=103638
This is about communication between usermode aps and a kernel mode driver, this is necessary it is impossible to compile MM as driver because you can't include dlls in your driver even not other system dlls

More about writing a keyboard driver http://www.brokenthorn.com/Resources/OSDev19.html the other links was more about filer and were really old so they will only work with a ps/2 keyboard.

Here is how we can install a driver temporary or longer : http://stackoverflow.com/questions/4993 ... in-windows
Last edited by BlubBlab on Tue Aug 04, 2015 3:45 pm, edited 1 time in total.
Jack-of-all-trades, but master-of-only of a few :D

My Reps:
https://github.com/BlubBlab/Micromacro-with-OpenCV (My version of MM2 with OpenCV and for MS Visual Studio)
https://github.com/BlubBlab/rom-bot (rombot with no stop WP and advanced human emulation mode and some other extensions)
https://github.com/BlubBlab/Micromacro-2-Bot-Framework ( A work in progress )
My Tools : viewtopic.php?f=10&t=6226

User avatar
Administrator
Site Admin
Posts: 5306
Joined: Sat Jan 05, 2008 4:21 pm

Re: Return of the crapshield!

#13 Post by Administrator » Tue Aug 04, 2015 12:26 pm

I have been meaning to look into writing kernel mode drivers eventually. It is something I have zero experience with though.

If we do make use of a kernel-mode driver, we also have to look into code polymorphism to prevent detection by Hackshield and similar malware.

User avatar
BlubBlab
Posts: 948
Joined: Fri Nov 30, 2012 11:33 pm
Location: My little Pony cafe

Re: Return of the crapshield!

#14 Post by BlubBlab » Tue Aug 04, 2015 7:19 pm

Administrator wrote:I have been meaning to look into writing kernel mode drivers eventually. It is something I have zero experience with though.
Neither have I but this is what I would do :

If we do make use of a kernel-mode driver, we also have to look into code polymorphism to prevent detection by Hackshield and similar malware.
Polymorphism won't be easy what you can do is playing with function pointers and using inline asm but I wouldn't start there.

First setup a test environment you need 2x PC for this with VS 2015 and driver kit with out this you can compile but not debugging .. than the hello world example.
- Next step would be running & testing the process memory access snippet I found.
- add code for communication between userspace and driver out of the other example or better said take a look because we need a bidirectional communication.
- than I would add code to scan & unhook functions by comparing them with and without hackshield if there is a watchdog routine for the hooks thinks will go complicated but there are solutions.(casting function pointer to void pointer -> simply reading & writing the bytes)
- next would be making the driver invisible the code link is also in the thread here. I think what it does is taking the driver name out of the internal register
- simulate or change keyboard & mouse input is relatively complex so far I saw because every type needs a different approach-> ps/2, USB, or like laptops some other interface.
- add polymorphism
Jack-of-all-trades, but master-of-only of a few :D

My Reps:
https://github.com/BlubBlab/Micromacro-with-OpenCV (My version of MM2 with OpenCV and for MS Visual Studio)
https://github.com/BlubBlab/rom-bot (rombot with no stop WP and advanced human emulation mode and some other extensions)
https://github.com/BlubBlab/Micromacro-2-Bot-Framework ( A work in progress )
My Tools : viewtopic.php?f=10&t=6226

User avatar
BlubBlab
Posts: 948
Joined: Fri Nov 30, 2012 11:33 pm
Location: My little Pony cafe

Re: Return of the crapshield!

#15 Post by BlubBlab » Tue Aug 18, 2015 4:45 pm

Okay I dug deeper into the topic.
First I can't get the new debugger from VS 2015 get working without having at least a win 8.1 PC on the other side because some stupid tool requirements and local I haven't get working until now.

The other thing is I have found some other infos hogging kernel function since win 8 isn't possible anymore at least not with another security break. The functions are protected from something called PageGuard which protect the kernel by checking the hash value.

The way anti-virus software does protect themselves is this : http://www.evilsocket.net/2014/02/05/te ... n-windows/
basically a function which will be called when a handel will be created.

I think Archebot goes around this by mapping the whole physical memory to virtual on foot by reading the page table of the os.
Jack-of-all-trades, but master-of-only of a few :D

My Reps:
https://github.com/BlubBlab/Micromacro-with-OpenCV (My version of MM2 with OpenCV and for MS Visual Studio)
https://github.com/BlubBlab/rom-bot (rombot with no stop WP and advanced human emulation mode and some other extensions)
https://github.com/BlubBlab/Micromacro-2-Bot-Framework ( A work in progress )
My Tools : viewtopic.php?f=10&t=6226

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests