[cornflake]

in console type nohooks, press enter (this will disable self-protection that maybe causing this bug)
after this type start, press enter

Thanks, here is some information.

1st run crashed:
I tried 'nohooks' but it didn't work. I tried 'rawmode0' (without specifying 'nohooks')and that worked. I saved the output of Code Hooks and Stealth Code. I then went to the report tab and ran the scan for everything. The file scan crashed after many hours (rku_error_log_1108232303).

2nd run successful:
I tried 'nohooks' again but it didn't work. So I again opened using 'rawmode0' and went to the report tab and ran the scan for everything except file scan.

3rd run BSOD:
After waking my computer from hibernate I tried again just running RkU normally and this time it worked. So I went to the report tab and ran the scan for everything. This caused a BSOD, but I'm not sure at what point in the scan process. I have a kernel dump and I ran windbg (WinDbg BlackBox - BSOD PAGE_FAULT_IN_NONPAGED_AREA).

4th run successful:
After reboot I again was able to start RkU normally and I ran the scan for everything except file scan.

I also ran a scan from a VM just for comparison. Notice in the VM report that network path isn't correct:

Code: Select all

\\\\\are-host\Shared Folders\Installs\R-Kit\vlc-1.1.7-win32.exe (UG North, RKULE, SR2 Overlord)
should be:
\\vmware-host\Shared Folders\Installs\R-Kit\vlc-1.1.7-win32.exe (UG North, RKULE, SR2 Overlord)

I have attached all log files. I have a few questions.

I have lots of SbieDll.dll entries and I was wondering if it would be possible to hide these in future versions (if it's the valid SbieDll.dll which is signed by Sandboxie).

In the 2nd run logfile there are lots of 'Ldr suspicious modification' entries related to vlc-1.1.7-win32.exe (what I renamed the RkU program as to mask it). Should the RkU program be detecting itself as 'Ldr suspicious modification'? I did not notice this in the 1st or 4th scan.

In the 4th run I see in Code Hooks some stuff related to sandboxie's driver although it says unknown code page. I also see some stuff I can't explain, here:

Code: Select all

Device object-->ParseProcedure, Type: Kernel Object [unknown_code_page]
File object-->ParseProcedure, Type: Kernel Object [unknown_code_page]
Key object-->ParseProcedure, Type: Kernel Object [unknown_code_page]
LpcPort object-->OpenProcedure, Type: Kernel Object [unknown_code_page]
Section object-->OpenProcedure, Type: Kernel Object [unknown_code_page]

Generally I see a lot of unknown_code_page stuff and I am wondering how to trace it. Like in the 2nd run I see a lot of this related to a valid svchost process:

Code: Select all

[1160]svchost.exe-->wininet.dll-->advapi32.dll-->AllocateAndInitializeSid, Type: IAT modification 0x70411230-->00000000 [unknown_code_page]
[1160]svchost.exe-->wininet.dll-->advapi32.dll-->CheckTokenMembership, Type: IAT modification 0x70411234-->00000000 [unknown_code_page]

Thanks

[EP_X0FF]

Hello and thanks for tests.

I tried 'nohooks' but it didn't work.

which version of rku you used? Previously posted in this thread?

I have lots of SbieDll.dll entries and I was wondering if it would be possible to hide these in future versions (if it's the valid SbieDll.dll which is signed by Sandboxie).

No because it's rootkit behavior even if this is security application. Usual applications does not use hacks.

Device object-->ParseProcedure, Type: Kernel Object [unknown_code_page]
File object-->ParseProcedure, Type: Kernel Object [unknown_code_page]
Key object-->ParseProcedure, Type: Kernel Object [unknown_code_page]
LpcPort object-->OpenProcedure, Type: Kernel Object [unknown_code_page]
Section object-->OpenProcedure, Type: Kernel Object [unknown_code_page]

This is DKOH installed by Sandboxie driver. It allocates special callgate in memory outside any visible module and places redirects to sandboxie driver inside.

ntkrnlpa.exe-->NtAlpcSendWaitReceivePort, Type: Inline - RelativeJump 0x8283F96D-->A650DDE0 [unknown_code_page]
ntkrnlpa.exe-->NtRequestPort, Type: Inline - RelativeJump 0x8280E238-->A650DCA0 [unknown_code_page]
ntkrnlpa.exe-->NtRequestWaitReplyPort, Type: Inline - RelativeJump 0x82845F42-->A650DD40 [unknown_code_page]
ntkrnlpa.exe-->NtTraceEvent, Type: Inline - RelativeJump 0x8262D326-->A650DC00 [unknown_code_page]
[unknown_code_page]

The same, belongs to Sandboxie.

\\\\\are-host\Shared Folders\Installs\R-Kit\vlc-1.1.7-win32.exe (UG North, RKULE, SR2 Overlord)

Reproduced here, will look what I can do to fix this.

Should the RkU program be detecting itself as 'Ldr suspicious modification'?

That's because of invalid path you mentioned.

modification 0x70411230-->00000000 [unknown_code_page]

and others with -->00000000 as target of hook on report page.
This is my bug. Will be fixed asap.

[EP_X0FF]

Here is updated version.

It should eradicate several bugs you listed before (0x00000000 as target of hook, broken path for processes started from vmware shared folders or any other network place and blue screen).

SHA-1 for exe
fd63a0a230886f0019e473f090ac7e8999eba4eb

[DSR!]

Code: Select all

Firma con problemas:
  Nombre del evento de problema:	BlueScreen
  Versión del sistema operativo:	6.1.7600.2.1.0.256.1
  Id. de configuración regional:	3082

Información adicional del problema:
  BCCode:	50
  BCP1:	8567CEEC
  BCP2:	00000000
  BCP3:	8289E8CC
  BCP4:	00000002
  OS Version:	6_1_7600
  Service Pack:	1_0
  Product:	256_1

Archivos que ayudan a describir el problema:
  C:\Windows\Minidump\042211-16458-01.dmp
  C:\Users\DSR!\AppData\Local\Temp\WER-24804-0.sysdata.xml

dump
http://www.megaupload.com/?d=MT9YG5J0

[EP_X0FF]

Ah yes, thanks. Caused by win32k.sys

Likely further updates for rku will take a lot of time to arrive. I'm cancel SR3 because currently I switched to other projects, all of them are x64, eating most of my time. So since rku was developed last few years "just for fun" in mostly free time I don't have it anymore and supporting 4 years old code base is annoying (alongside with developing different version for private usage). In my opinion it's time to drop x86 legacy and antirootkits as it part. This software must die together with 32 bits. As soon as it only possible. According to x86 past were made a lot of errors, resulting in rise of rootkits in 2004-2009. From the point of view of system programming, antirootkits software is complete nightmare and incredible risky. That's one of the main reasons why MS didn't released anything labeled "Antirootkit". The only one good antirootkit is that which works as a copy of Windows core, including copy of file system, copy of memory management etc. And all these should be synchronized with real OS components. Co-existing such system inside another system, without impact on real system is too much for this kind of software. I'm not telling that it will require versions support for all NT cores (including major variety of service packs) and a lot of debug (who needs blue screen generator). Antirootkits and antirootkit engines were required in the initial/middle period of rootkits rising. IMO ironically all this applies and for kernel mode rootkits. Main task currently is not let them work on x64 at all.

I will close this thread for a while (until any next updates).