Hidden Registry Key

[Infohawk]

I'm having trouble installing daeon tools. That leads me to using rootkitrevealer where I find this:

HKLM\SYSTEM\ControlSet001\Services\a347scsi\Config\jdgg40 6/30/2005 1:03 AM 0 bytes Hidden from Windows API.

I can't delete this jerk. It doesn't show up in regedit or respond to command-line deletion. Can't delete the parent (get an error) and I imagine it's that this key is there. Searched google which only confirmed there can be hidden keys but not how to get rid of them.

Using windows xp pro.

 

[Jeff7]

Make sure you've got permission to do anything to it. Set permissions to full access for Everyone. I also will use Registrar Lite to do registry editing where unpleasant spyware is concerned. Some spyware, like CoolWebSearch, will render its keys invisible to the Windows registry editor.

 

[corkyg]

This will at least get you a bump.

Hidden

 

[Infohawk]

Originally posted by: Jeff7
Make sure you've got permission to do anything to it. Set permissions to full access for Everyone. I also will use Registrar Lite to do registry editing where unpleasant spyware is concerned. Some spyware, like CoolWebSearch, will render its keys invisible to the Windows registry editor.

Did that. Didn't work. Not to mention, it's hard to change permissions on something you can't see. But I had nevertheless tried to modify the parents and delete them to no avail.

Does reglite do anything regedit can't do? From what I understand the keys aren't even visible to the windows API.

 

[Infohawk]

Originally posted by: corkyg
This will at least get you a bump.

Hidden

Yeah, i saw that. They have the proof of concept. I wonder how they deleted it at the end though...

 

[bsobel]

Easiest thing is to boot from something like BartsPE and use the registry editor from there...

 

[Infohawk]

Originally posted by: bsobel
Easiest thing is to boot from something like BartsPE and use the registry editor from there...

Wouldn't the key still be hidden?

 

[bsobel]

Originally posted by: Infohawk

Originally posted by: bsobel
Easiest thing is to boot from something like BartsPE and use the registry editor from there...

Wouldn't the key still be hidden?

Im pretty sure one of the BartsPE registry editor uses the native api's cause people use them to circumvent other 'hidden' settings...

 

[Nocturnal]

Weird. TTT for an answer, I thought registry keys weren't able to become "hidden."

 

[Infohawk]

Originally posted by: Nocturnal
Weird. TTT for an answer, I thought registry keys weren't able to become "hidden."

Sucks huh? The link from corkyg explains it well. Seems like there's a way for programs to remove it (since the proof-of-concept in that article does it) but I don't know how to program.

 

[thegorx]

what part is hidden ?
a trick would be if you can see the a347scsi subkey
create a blank hive file and import it while highlighting the a347scsi subkey
make sure you have the correct subkey highlighted because it's gonna wipe it
make sure you back up your registry

you can create a blank hive by exporting a subkey that doesn't have much
then load it and remove the rest
actually you more than likely could just use it as is because you're gonna delete it after anyway.

also make sure you confident you can restore a registry in the case windows doesn't load like if you happen to wipe the whole services subkey.
so a barts disk would be handy

anyway that an idea that should work if you follow


It's more than likely corrupt and you might have other corruption too
XP needs a decent registry checker and maintenance utility

It might be good practice to restore the registry every once in a while
since I'm pretty sure the hives creation dates never change unless you use system restore or another means of restoring the registry
not that it would help

databases need maintenance ?

 

[Infohawk]

Problem Solved by following daemon-tools procedure for manual removal. Rootkitrevealer doesn't list it as a problem anymore. Not really sure what solved the problem. Maybe rootkitrevealer was wrong that it was hidden? Or maybe doing the deamontools steps allowed it to be unlocked and therefore for me to delete it...

 

[gwarbot]

Can you us a linux liveboot cd then access the file and purge it?

 

[Jeff7]

Originally posted by: Infohawk

Originally posted by: Jeff7
Make sure you've got permission to do anything to it. Set permissions to full access for Everyone. I also will use Registrar Lite to do registry editing where unpleasant spyware is concerned. Some spyware, like CoolWebSearch, will render its keys invisible to the Windows registry editor.

Did that. Didn't work. Not to mention, it's hard to change permissions on something you can't see. But I had nevertheless tried to modify the parents and delete them to no avail.

Does reglite do anything regedit can't do? From what I understand the keys aren't even visible to the windows API.

Ah, but you can change the permissions of the parent folder, and those changes should propagate to the subfolders and keys.

It can see some keys that aren't visible to regedit. I used it to remove CoolWebSearch once - CWS apparently will not let regedit.exe see certain entries, but they were visible in Registrar Lite. They were gone shortly thereafter.

 

[Infohawk]

Originally posted by: Jeff7
It can see some keys that aren't visible to regedit. I used it to remove CoolWebSearch once - CWS apparently will not let regedit.exe see certain entries, but they were visible in Registrar Lite. They were gone shortly thereafter.

Tried that too. I don't think it was a permissions issue. Anyway, problem solved as mentioned above.

 

[NogginBoink]

You had a rootkit installed.

Most rootkits intercept calls to RegEnumKey and RegEnumValue. They allow the OS to enumerate all keys/values, take the list, delete the keys/values they don't want you to see, and pass the remaining list back up to the calling program.

So the key/value is there, but no program that uses the standard Win32 API's can see it.

The solution is to either boot to another OS that doesn't have the rootkit installed, or to access the key/value with an absolute path, not using the RegEnum functions.

 

[dissidente]

Hi there.

I have the same "problem" when running Sysinternal's tool.

So I searched the net and found zilch (aside your topic here).

Sysinternal have another very usefull tool called RegMon, that monitors realtime access to the registry, using a low level engine that would almost for sure log any acesses to the "problematic" key.

So I thought that being the key in the a347scsi service branch it could pretty much be related with any scsi device or scsi emultation device. My computer doesn't have any scsi hardware, so chances were that it might be an emulation of some sort. Among the tons of software installed there were only two that might use this kind of emulation: a backup software called Acronis TrueImage, and a well known software called Achool 120%.

Now I was getting somewhere. Checked the device manager, and two things camethe eye: 1st, Acronis created a hardware emulation device called Acronis TrueImage Backup Archive Explorer, wich seemed very much to be able to be our "rootkit". So having RegMon monitoring my registry I disabled and re-enabled this device to check if it rang any bells. Nope. This wasn't it.

Another thing curious: I had indeed a so called A347SCSI SCSI Controller, not having phisically zilch. Well, the next logical step was obvious: disabling and re-enabling the so called SCSI controller. Now this rang many bells, as you might check below:

System:4 CreateKey HKLM\SYSTEM\ControlSet002\Services\a347scsi\Config\jdgg40 SUCCESS Access: 0xF003F
System:4 QueryValue HKLM\SYSTEM\ControlSet002\Services\a347scsi\Config\jdgg40\ujdew BUFFER OVERFLOW
System:4 QueryValue HKLM\SYSTEM\ControlSet002\Services\a347scsi\Config\jdgg40\ujdew SUCCESS 20 02 00 00 BA DB D5 73 ...
System:4 QueryValue HKLM\SYSTEM\ControlSet002\Services\a347scsi\Config\jdgg40\ujdew SUCCESS 20 02 00 00 BA DB D5 73 ...
System:4 DeleteValueKey HKLM\SYSTEM\ControlSet002\Services\a347scsi\Config\jdgg40\ujdew SUCCESS
System:4 QueryValue HKLM\SYSTEM\ControlSet002\Services\a347scsi\Config\jdgg40\ljej40 SUCCESS 1F 17 C9 6E 81 51 F9 00 ...
System:4 DeleteValueKey HKLM\SYSTEM\ControlSet002\Services\a347scsi\Config\jdgg40\ljej40 SUCCESS

Along with this operation, a virtual DVD drive called AXV CD/DVD-ROM SCSI CDROM Device disapeared and re-apeard, indicating that this was the emulation object wich was responsible by the "rootkit" key.

This is indeed a emulated scsi device that Alchool creates in order to "directely work" with the medium images to overcome some of OS's limitations.

So chances are that Infohawk will have this software or some other software of this type installed on his computer that was responsible for the key.

Well, mistery solved (at least in my case). =)

Just registered to tell you guys this, and to "register" my findings for other to see in the future (it had been usefull if I had find this information an hour ago =P )