A Problem with Hidden Keys

This is related to kareldjag's earlier test on "hidden keys". I did some further testing with SysInternal's Reghide, and think I've isolated a problem. After explaining the rules, I'll describe/interpret the results. If you're in a hurry, scan ABBREVIATIONS, then read THE TEST, steps 1 & 2.

ABBREVIATIONS:
.. KEY-Software = HKLM\SOFTWARE\
.. KEY-SysInternal = HKLM\SOFTWARE\System Internals\
.. KEY-Untouchable = HKLM\SOFTWARE\System Internals\Can't touch me!\
.. VAL-HiddenValue = HKLM\SOFTWARE\System Internals\Can't touch me!\\hidden value

RULES:
....1) To make RD alert on every action taken by Reghide, I had to first run Reghide so it would create the keys upon which to base RD's test rules. With Reghide displaying "Try and open the key...", those keys now exist.
..2) My new rule group contains three rules, each of which "Ask User" on "modification" of either a Key or a Value.
....2A) On Reg-Keys ---- for -- KEY-Software
....2B) On Reg-Keys ---- for -- KEY-SysInternal
....2C) On Reg-Values -- for -- KEY-Untouchable
..3) After creating the rules and exiting Reghide, I deleted KEY-SysInternal which was an artifact of Reghide.

NOTE: RD displays KEY-Untouchable and allows me to select it when creating rule 2C. There may, however, still be a subtle difference between RD's representation of this key's name and the key's actual name.

THE TEST:
..1) After starting Reghide and clicking on "OK", RD's first alert is triggered by the insertion of KEY-SysInternal which is correct (rule 2A). This is the alert shown in kareldjag's original test, but Reghide hasn't done anything tricky yet.
..2) After clicking Allow, RD alerts again on insertion of VAL-HiddenValue which is a proper alert (rule 2C). However, this happens after Reghide inserted KEY-Untouchable which should have triggered an alert but did not (rule 2B).
..3) After clicking Allow, RegHide invites me to investigate its handiwork. When I tell Reghide I'm done looking it deletes KEY-Untouchable. RD alerts this deletion correctly (rule 2B). It's a bit odd, though, because when KEY-Untouchable was inserted, I got no alert. [[NOTE: If I manually insert a new subkey (with a normal name) under KEY-SysInternal, RD does alert it correctly, so the rule does work for both insert and delete.]]
..4) After Reghide finished I manually deleted KEY-SysInternal (again). RD correctly alerted the deletion (rule 2A).

Exactly what causes the missing alert in step 2 (assuming I'm correct) is a question for Jason. In either case, I'm also hoping that any use of "trick names" (ie. what you see is not what you get) will be considered "potentially suspicious enough" to merit a global option for alerts regardless of where in the registry the activity takes place.

 

This is a continuation of post #1. The following diagram shows my actions and RegDefend's alerts.

<<-- MY ACTION -->> Start Reghide.exe and click "OK" at the greeting.
_______________________________________________________________________________________
| reghide.exe tried to modify the following registry KEY
| __KEY: HKLM\software
| VALUE:
|_____________________________________________________________________________________|
_______________________________________________________________________________________
| reghide.exe tried to modify the following registry VALUE
| __KEY: HKLM\software\system internals\can't touch me!
| VALUE: hidden value
|_____________________________________________________________________________________|

<<-- MY ACTION -->> Received Reghide's prompt, "Try and open the key...". I clicked "OK" and waited for alerts from RegDefend in response to Reghide's clean up procedure.
_______________________________________________________________________________________
| reghide.exe tried to modify the following registry KEY
| __KEY: HKLM\software\system internals
| VALUE:
|_____________________________________________________________________________________|

<<-- MY ACTION -->> Reghide is now done. From my registry editor (rl.exe) I delete the key "HKLM\SOFTWARE\System Internals".
_______________________________________________________________________________________
| rl.exe tried to modify the following registry KEY
| __KEY: HKLM\software
| VALUE:
|_____________________________________________________________________________________|


As a final addendum, if I hadn't had Reghide's source code, RD's alerts would have left me somewhat clueless. For instance, Key modification means (I think) that a subkey of the "rule-key" is inserted, deleted or renamed. RD doesn't specify which of those actions is pending. Also, it gives the name of the parent key (on which the rule is based), but not the name of the subkey that will be effected. Value modification can mean that a new value-name is being inserted (with new data), an existing value-name is being deleted (with its old data) or an existing value-name is trading its old data for new. The name of the value and its location are both identified correctly by RD, but it doesn't specify which action is pending. Also, it seems important to display the old and/or new data. I realize that's a non-trivial redesign of RD's alert popup, but it could mean the difference between avoiding trouble and experiencing it.

 

earth1,
If that doesn't qualify you to be one of Jason's beta testers I don't know what will.... good effort there

At least you highlighted the problem prior to v1.2 so hopefully the strcmp() equivalents will be fixed before its release ;-)

 

I've just discovered a bizarre new twist to the results in post #1. When I delete the key HKLM\SOFTWARE\System Internals\ (KEY-SysInternal) before running Reghide, the result is as originally described. However, if I don't delete the KEY-SysInternal that Reghide left behind, RegDefend's "problem" seems to disappear.

I don't have docs for the Native API, and don't know what NtCreateKey() does if a key already exists. I assume that no action is necessary and RD's hook function would never get called. If that's true, then rule-2A should not alert when KEY-SysInternal already exists, and indeed, it does not alert.

When rule 2A doesn't trigger an alert on the first insert attempt, rule 2B suddenly does trigger an alert on the second insert attempt (KEY-Untouchable). Therefore, when KEY-SysInternal already exists, RegDefend's alerts seem to be complete and correct. However, when KEY-SysInternal does not already exist, RD incorrectly misses the alert on insertion of KEY-Untouchable.

This variety of outcomes seems very strange, Jason. I'm assuming that this will be reproducible on your system, but I think the problem may be unrelated to "hidden keys". If anyone else tries this, I'd appreciate hearing what happens.

 

Hi,

***It's mainly a Windows "problem" more than a Regdefend's one.

Since Regdefend (and others registry tools) is based on documented APIs, then Regdefend will always only allow what the underlying Windows system allows.

***About Native Windows APIs:

http://www.sysinternals.com/ntw2k/info/ntdll.shtml

Also Thanks for your research earth.

Regards

 

Hi kareldjag,

The source code shows that Reghide uses the Natve API for 100% of its registry access, which seems to prove that RegDefend does intercept Native API calls. Otherwise, the alerts in both of our Reghide tests would not have been possible. Additionally, I verified three separate cases where RD successfully blocks Reghide if I ask it to. Reghide doesn't notice it's been blocked, but my registry editors confirm that it has. The only block I couldn't verify was the creation of "hidden value" because it's under the "Can't touch me!" key that obscures its contents from "normal" registry editors.

RD can block Reghide after an alert, but there still seems to be a quirk that can reproducibly (on my system) cause RD to miss an alert. In the follow up post (#4), my revised suspicion was that the "problem" (if it is such) has nothing to do with hidden keys (or Native API). Perhaps a combination of conditions can cause RD to let one call slip past unchallenged. I'm still uncertain, though, if anyone can reproduce this same quirk..

Jason, I know you're focused on changes for the next release, but without a little guidance from you, we're all just guessing at which things are important and what they might mean. When you have a chance, I'd like to know what you think

Best regards

 

Hi,


It's difficult for me to tell more about the subject.
It is already enough complicated.

There's a ruusian article about that but it's written on "cyrilic":
http://wasm.ru/article.php?article=dio

So i've send an e-mail to Daniel Wischnewski (who wrote an article about RegHide) for perhaps more explanations.

Regards

 

One of the things I have fixed in the latest build is an issue which sometimes lets some alerts through, which to the user would appear random, depending on where it occured in the registry. This is why RegDefend failed RegTest sometimes for some people, so I would suggest this is the behaviour you are experiencing occasionally.

 

Thank you for the input Jason. Hopefully what I saw is a symptom of the problem you've already fixed. Although I can repeat the sequence at will, its behavior is effected by such small variations that it certainly could appear random. I'll give the same test a try as soon as a new build is available.

Cheers