Stop RKUnhooker incompatibility to gmer

These crazy russians try to make RKU incompatible to GMer:

here is the antidote: Kill explorer.exe then kill there unimportant exe.

And if you are reading this guys from russia: Spybro.exe can determine the inline hooks that your tool is not able for.

 

@system junkie
out of interest why does spyware browser (spybro exe)get bad press in the HJT forums
Looks like a very legit tool with useful library.

That other thread at sysinternals has been closed.

 

RkU also wants me to uninstall SSM. LOL.
Made my comment but posting was deletetd and thread closed.

 

Sometimes Gmer works even with latest Rku, it´s silly to make it incompatible to Gmer, looks like kiddies are playing their games.

rku is still very green in my opinion, e.g. the hidden file detector lacks a lot,
Vista installed on E: and rku´s file detection hangs up.

The most sisyphus of rku is if you cancel hidden file detection all results are canceled too... very very beta either alpha state.....

Spybro goes very deep into system with lawenforcer.dll, might be a reason and it makes automatically autostart entry without asking the user, maybe a second reason, apart from that, it´s a quite cool tool.

Anothet tip to rku creators: Your tool is incapable of removing Inline hooks of 0x000001 kind, just a little tip. So much work to do for you guys.

 

Out of interest RkU has removed the "disable gmer" code with the current release.

 

Yes many problems I found with RKU3, not just silly gmer incompatibility

 

Yeah? And what are these hooks? Like in GMER Function+81EF address?
If you do not know that means "jmp" somewhere inside function, LOL

 

Nope, still gmer been erased, but now it is little clever, no more false positives

 

Never tried to read warning about system compatibility? The same is with file systems. NTFS was a little updated for Vista, so that issues is understandable.

Where you get this?

0x0000001 means that Rootkit Unhooker was unable to determine address of hook, but the fact of hooking was detected. So it is unhookable, friend. I tried and everything working. Another tip to you - before making some interesting statements, please try to check them in real life, no offense, just tips

 

@Z0mbie : I did one mistake, PG blocked 0x000001 from removing it.
So it is removable, my fault.

If I start Hidden File Detector, then cancel, all results will automatically canceled too, not very useful. But you said already its because of new ntfs.

I prefer to see words and filenames instead of machine language.

Rku3 exe hides in taskmanager and then it blocks gmer from loading, just for info, you will need a good Anti-Rootkit Taskmanager to unload Rku3.exe then kill explorer and start gmer.

 

Sometimes peoples makes mistakes, it is normal

Hmm, strange, I can cancel scan and results still in the list.

RkU shows everything about hooks in normal language.

Nope, it is visible in Windows Task Manager, Process Explorer. But not accessible. To unload RkU you need only to press button "Exit"

 

We are no more crazy than you. We not trying - we made it.

About everything else:
All hooks are detectable. I do not saw any other tool that can detect all hooks. 0x00000001 well described by Z0mBie. All hooks are removable. It is not disputable. GMER hooks detection is kiddish. He think that everything with "jmp" instruction is hook. Well, sometimes it is simple jump inside normal function. Most funny detected hook with GMER was somewhere in ntoskrnl function deeper than five kilobytes. It is pure M$ code, Gmer, not a hook. What about all other false positives on Gmer detection, author making decision to show everything that was modified as hooked Well it is his choice.

Future and probably last public version will solve problems with GMER detection/removal:

It will not works with GMER, RKU will simple exit when GMER will be detected.

About "alpha, beta" and others statements about unstable work. Did you ever tried DarkSpy or GMER for example? Very stable tools. Very stable to making BSOD's in runtime.

You forgot to say here, what was in your post. Well, my answers to you also was moderated. Thread was closed by my request.

 

@EP_XOFF
good to see you posting.
Keep visiting, bring your friends.

 

Hi, Longboard.

Good to see you too
Nice place.

 

Greet EP_XOFF over here too. Fine effort with RK

Although GMER does not BSOD my units it severely imposes stress to the point that it is unworkable, meaning useless in current form WIN-XP-PRO_SP1

DarkSpy at-once with BOTH versions BSOD my units so also even more useless. At least can see GMER Gui but nothing more so interesting.

RKUnhooker performs EXCELLENT!!! (And i do much research and usage with these programs and test m*lware/kits)

 

I better won't repeat this here. Thread closed there and matter closed 'here' for me also.
I only hope your behaviour here will be better as over there (choice of language), then - from my part - you are more than welcome here

P.S. As we discuss now like civilized and educated people and base our discussion here 'mostly' on facts, can you please explain me (us) why you can't run RkU with SSM installed or at least shutdowned?

 

Yes, guys nice to see you all here. Ok, Tommy your pleasure, no offensive words.

I already explained this on SysInternals forums.
Ok, I will try to throw some light on it here.

SSM using threads-injection in all processes. We detects this as "parasite" and it is true. But it is fully impossible to filter SSM thread from malware thread, so we always removing remote threads from our program.

As shows our tests in some cases - removing this thread from RkUnhooker leads to BSOD, this is related to SSM hooks in SSDT and our hooks in ntoskrnl, they are simple merging each other, so that is the reason of BSOD incompatibility. We can add some kind of compatibility with that tool - that is not a question. But it is really needed? If we add compatibility with SSM we will loose some part of protection of our own tool (for example under Windows 2000 - it will be killable in runtime by malware). That is the big question for us now. Probably next version will supports start with SSM, but I hate this program. I do not like SSM, because I think that it is _bad_ software (no offensive words, as I swear). Why I think so:
- malware behaviour of this tool (threads/driver tricks like in HxDoor)
- lies and other interesting statements located on their site
- my (and not only my) personal relations with one of the SSM developers

About GMER erasing - it will be removed from next version. GMER will peacefully work, we not.

p.s. Sorry for poor english

 

@EP_X0FF
Interesting statement, logical and well argumented as far as i understand the matter.

In your opinion what is a good alternative to SSM (you stated it is a _bad_ software), or are HIPS in your opinion useless and should be replaced with other kind of applications?

 

Everything about SSM and its behaviour I posted on SysInternals. This is SysInternals thread where discussed issue with FF killing while GMER ban bug. On second page located asterisks post about me/my friends and our work, our offensive answers are below, detailed answer about SSM with screenshots on page 3 http://forum.sysinternals.com/forum_posts.asp?TID=9102 I tried to not use obscene or indecent words, but some of them present in that post. Well, that it was my answer to Mr. Gennady aka asterisk, one of the SSM developers and my personal reason of hate to SSM. The SSM theme is out-of-date for me now. I do not want anymore discuss about this product, it's developers and they behaviour. We have wasted to much time in AntiRootkit wars and in SSM conflict. If GMER will stops its attempts then we will do the same.

About HIPS.
I think that such kind of security software are dead-end technology, that will die in near future. More realible and perspective - hardware virtualisation, but soon this technology also will be bypassed as said PE386. Probably in next upcoming Rustock_C. And I see no reasons not trust him, because his rootkits and his demo already proved for me high level of his technical skills.

 

EP_X0FF: True, true ;-)
I have to admit that.

True too.

Indeed after testing a lot, I also must admit that gmer finds many unnecessary stuff that set our state of minds in full paranoia, nevertheless it´s a funny tool to play with, but if you stop a process it will detect every little code as .text Rootkit.

Why that, could it be possible that Rku had some problems with detection of Odyssee Rootkit?
I have some fragments of thought in mind that several tools had problems in detection of Odyssee.

I totally agree with it.

I also don´t like ssm because it hooks every atom and makes system slow down the same with antihook3, you can see how easily it can be bypassed, that IceSword and PG works fine.
Greetz´ ya all.

 

Hi, SystemJunkie.

I reversed Oddysse rootkit and found nothing interesting in it. It was fully detectable by Rootkit Unhooker v3.0 beta 2.

As I remember somewhere in that thread I posted detailed analysis of Oddysee behaviour http://forum.sysinternals.com/forum_posts.asp?TID=8857

RkU detects it as:
Hooks in SSDT (also removable)
Hidden file (can be copied or wiped)

It is very simple rootkit, coded probably in one hour.

Oddysee do not hide it's driver, so it is visible in drivers list.

 

Oh, ok, but some antirootkits had problems with its simplicity.

 

Which one, for example?

 

Well, maybe. I do not know about Oddyssee test with other antirootkits, but I think that it have to be detectable by any of them.

 

Jeez Guys

As someone here hoping to learn about computer security software and I may add, a paid user of SSM, I find that link from EP_XOFF extremely disconcerting http://forum.sysinternals.com/forum_posts.asp?TID=9102

Goodness knows what to believe.

Seriously folks, stuff like this I find very disturbing.