Hi, all!

I guess this is nothing new to most of you, but...

Someone once posted a small sicedetecter that using ntquerysysteminformation got a basepointer to something that contained, among other things, the names of all (?) services and just scanned through them and found NTice, even though I had hidden it with Nicolatesla20s patch...

Also now Soldat told me that armadillo uses openservice to find out if we have NTice service running. (I have not done armadillo ever yet. Believe it or not.)

Someone once, when i was even more of a newbie, said you have to deal with these things on a case by case basis. While that is very true, many times for many reasons, I never liked that answer... So I thought about this simple idea, but only just now actually tried it.

Anyway, I just tested yesterday to rename the service, rename all important occurances in the registry and rename all affected textstrings in the 3 important sice-files... (Those usually patched. Not actually all three though... One didn't contain the strings... I think...)

It worked ofcourse. Now sice is superhidden!

Just remember that if you have patched it before, you ofcourse need to find ZTice aswell as NTice. Don't forget, search BOTH unicase and c-style textstrings!
(And use same length on names...)

/Manko

Yes, armadillo does use this technique - they use OpenServiceA with "ServicesActive".


It's quite easy to defeat on it own however



-nt20

Hi, NicolaTesla20!

Yup. I tried it out as soon as he told me. Pretty easy to beat.

But don't you agree that it's pretty good not having to bother?

/Manko

hmm..

I thought u had to register a driver to get it up as a service.
Or is that handled automagically by ntice each time it loads?

I was looking into that recently (I posted the get ntice base thingie on this board), but ran out of free time. I mean, I did try once to modify the registry strings; and I concluded it was probably not the best option (as I ended up with a messed up softice) to modify the service name.

That shields softice against another detection trick.. but you're still helpless against tricks like star-force use - they completely override the int1/int3 to its own exception handler (thus any bpx/bpm/single step results in their exception handler to be dispatched).
Anyone saw/defeated a similar trick?

Well,

Such a protection would be easy to defeat in my opinion, just stick the orginal SI entries into the IDT again....

I'm sure someone will write a driver that watches the IDT and restores it when it messed with. Perhaps using guard pages...


-nt20

yea.. i guess. unless the protection persistently patches it.



i suppose that would do it. I don't have enough experience on the topic to safely say much more..
thx for the reply.