Interesting HIPS test:restore SSDT hooks

Theres no sense arguing the point so i'll pass the benefit of the doubt in your favor.

All i'm saying from experience of testing this file by letting it run uninhibited as yankinandcrankin confirms is that it is by design nothing more then a BSOD generator on face value.

The purpose (again) of fatal exception is to alert the user an mismatch of sorts is been attempted where it doesn't line up with normal operating patterns and my PC is set to reboot on these occurances, and i might add with no ill affects.

I throw caution to the wind with POC's because of my extra drives so nothing ventured is nothing learned, but theres nothing gained either in this POC to unhook HIPS from the table.

I can verify nothing ill occured including file system because i'm using the same PC i run this on last evening and everything is as it was before.

Heck, i've deliberately BSOD's my unit several times before with various test files with no lingering evidence of corruption or other strange affects.

 

AFAIK, a BSOD only occurs when some kernel code causes a crash. So, if you see a BSOD, it means that some code executing at ring0 caused a system crash.

 

I totally agree, it was a kernel mode entry attempt but it was repelled nonetheless.

Not sure but it's been said userland can force kernel disruption too.

 

Or it crashed the EQS drivers.

 

Let's assume that was the case, at any rate they were reinstalled on reboot and set right back in place again as is the case of HIPS that program their positions in the SSDT Instructional Table.

Fact still remains, the POC or whatever junk it was did nothing at all to disrupt normal operations except to simply reboot the machine right back to previous working order again, including the HIPS.

I could have done that myself by rebooting with the reset button.

 

Ok. Let me guess. You are Comodo user ? If yes, then yes, there is no sense in arguing.

One of Comodo users told me one brilliant wizdom: "the tests Comodo fails are not proper tests". Now I see that malware Comodo fails is just not proper malware. You are a winner, at this point I quit

 

Sorry, theres no winner here at all.

This test is really no HIPS test at all for HIPS because it was obviously rushed together without much thought or testing different platforms as well as service packs, so with that in mind, it was a pretty effective publicity stunt IMO.

 

xx.exe : Not detected by Sandbox (Signature: NO_VIRUS)


[ DetectionInfo ]
* Sandbox name: NO_MALWARE
* Signature name: NO_VIRUS
* Compressed: NO
* TLS hooks: NO
* Executable type: Application
* Executable file structure: OK

[ General information ]
* Application uses MFC.DLL.
* File length: 24576 bytes.
* MD5 hash: e18c84112c05db73f00a767946b75310.



(C) 2004-2006 Norman ASA. All Rights Reserved.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Jotti's malware scan 2.99-TRANSITION_TO_3.00-R1

File to upload & scan:
Service
Service load: 0% 100%

File: xx.exe
Status: OK
MD5: e18c84112c05db73f00a767946b75310
Packers detected: -
Bit9 reports: File not found

Scanner results
Scan taken on 13 Apr 2008 23:16:17 (GMT)
A-Squared Found nothing
AntiVir Found nothing
ArcaVir Found nothing
Avast Found nothing
AVG Antivirus Found nothing
BitDefender Found nothing
ClamAV Found nothing
CPsecure Found nothing
Dr.Web Found nothing
F-Prot Antivirus Found nothing
F-Secure Anti-Virus Found nothing
Fortinet Found nothing
Ikarus Found nothing
Kaspersky Anti-Virus Found nothing
NOD32 Found nothing
Norman Virus Control Found nothing
Panda Antivirus Found nothing
Rising Antivirus Found nothing
Sophos Antivirus Found nothing
VirusBuster Found nothing
VBA32 Found nothing

 

Oh, dear. This list is very impressive, of course. But the whole joke was not about this list, it was rather about approach. As for the lists. Be sure, the thing that causes BSOD will be in those lists very fast. Much less dangerous tests are there. Another option this test causes BSOD only with Comodo, then it will not be in the lists, of course.

 

At some point these tests have to come with a storyline to convince us how it would execute.

Nice....

 

I guess MJ is a woman but I have only seen her posting at Sysinternals in the past and some Chinese sites.

Easter this woman is posting a lot of crappy code lately for some reason.
But I guess the stuff posted over at Sysinternals was debunked in a hurry by EP using as everybody says an outdated RKU.
Then again if it wasn't EP debunking MJ who Will it be, since he wants nothing to do anymore with her challenges.

 

just checked the original thread in chinese, the MJ0011 list some notice:

1: this tool may casue the BSOD in the 2-cores CPU.
2: the GDT address which got by sgdt in Vmware is incorrect, may casue BSOD. please test it in the real os.

http://www.debugman.com/read.php?tid=1144

 

Pffft, better check that, i only run single core and it choked up, also no VM here either.

It would go much better for her to just scrap that silly MFC project permanently to avoid any further embarrasment and comedy.

It was good enough for a chuckle though

 

This test tampers csrss.exe before BSOD. If your HIPS prevents it from tampering system process, no BSOD occures. This is plain simple.

 

I said execution, this test is an executable right...

 

xx.exe is an unauthorized executable and will be killed by Anti-Executable in nanoseconds. Case closed.
Why writing a malware, that has already an anti-dote ? What a waste of time.

 

To say the truth I didn't dig deep enough to second or disclaim this

But the fact it causes BSOD shows that even in case it was not designed specially to BSOD, implementation is not correct enough to avoid it in all the cases.

 

it can, in case HIPS is poorly implemented or absent. There are undocumented hacks to get in kernel address-space from usermode. HIPS for one should prevent it.

 

My first post here
CFP 3.0.21.329 on XPSP2
xx.exe did not crashed if it is blocked by CFP (see screenshots), however if CFP is closed it "create" BSOD (crashed system)

 

Great. We have finally got a correct person here, who can w/o extra words just post correct info

 

If u deny first popup, no BSOD.

 

I am not sure. I understand from this test that if there is no BSOD, test is pass. If I am correct then:

CFP- Passed
GesWall- Passed

 

It is best to just look at the thread on Sysinternals on this program.
Mj posts there.
program ment for non patched OS too

Claims people posting here are all idiots. Isn't that funny because some of here were going to the root kit dot come when she was still in diapers

So what if we don't know chinese and go to the GREAT Chinese forums where all the worlds greatest programmer are. Most are like a family here. those that have been around along time that is.

 

Yes an interesting read over at the Sysinternals forums.
Seems members at Wilders are well liked over there.
Most of what they post is over my head, but I got the jest of it.

 

I'm not really sure that all the world-greatest programmers are there