wildcard *~ not working as I would expect

Discussion in 'Ghost Security Suite (GSS)' started by gottadoit, Apr 11, 2005.

Thread Status:
Not open for further replies.
  1. gottadoit

    gottadoit Security Expert

    Joined:
    Jul 12, 2004
    Posts:
    601
    Location:
    Australia
    Jason,
    A quick question on the wildcard if I may

    I was adding some rules to protect the "\shell\open\command" sequences in HKCR (for exe ,com, cmd, bat etc..) and I thought I'd try your wildcard and see how it went

    The copy and paste worked very nicely so I could take my part of my existing definition and copy it into a new one, then I tried to get help up to see your wildcard definition and found that the dialog box was blocking access to the main window and it didn't have a help button on it ....
    Exited out of the "Add Rule" dialog and read the help... and back again

    It seems that your definition of *~ means anything up to but not including a backslash, but from the example given it wasn't clear if *~ had to be the terminating part of the pattern

    Given that you very usefully mentioned that you stop evaluation early once you find a match it was easy to test given that the wildcard pattern sorted itself to the top of the list

    I then had three rules
    #1 hkey_classes_root\*~\shell\open\command
    #2 hkey_classes_root\comfile\shell\open\command
    #3 hkey_classes_root\exefile\shell\open\command

    #1 was set to trigger on modifying reg keys & values
    #2 and #3 were set to trigger on reading+writing keys & values

    Seeing as I have teatimer running and the wildcard pattern didn't work it was a matter of seconds before I got to see your new alert box....

    Did I try and do something unexpected with *~ or is it an unintended feature ?

    NB: It would be nice if the copy to clipboard feature picked up on the action settings as well as the key/value/wildcards information

    Edit:
    Seeing as this example has 3 characters exe/com/bat I tried to use ?
    hkey_classes_root\o_Ofile\shell\open\command
    but that didn't work either
     
    Last edited: Apr 11, 2005
  2. Jason_R0

    Jason_R0 Developer

    Joined:
    Feb 16, 2005
    Posts:
    1,038
    Location:
    Australia
    ~ doesn't need to be the terminating character. The RegDefend wildcard parser basically ignores it, but sets a flag stating "if you find one more \ then there is no match". So regardless of your wildcard string, adding ~ means if there is even one \ after it, there will be no match.

    So you could do this if you want :-

    hklm\software\~*
    it's the same as
    hklm\software\*~

    Hope that makes it clear. So you can't do what you tried, it should be
    hkey_classes_root\*\shell\open\command

    BTW The new version 1.200 doesn't list the actual REG ITEMS in the way they are stored and sent to the driver, rather it shows them alphabetically to help view them. So you can't determine the order that the actual REGISTRY RULES in a group are looked at in order, this information isn't necessarily though. All you need to know is one of the rules in a group matched a registry item.
     
  3. gottadoit

    gottadoit Security Expert

    Joined:
    Jul 12, 2004
    Posts:
    601
    Location:
    Australia
    Jason,
    Thanks for the quick reply
    Why doesn't the "o_Ofile" wildcard construct work ?
     
  4. Jason_R0

    Jason_R0 Developer

    Joined:
    Feb 16, 2005
    Posts:
    1,038
    Location:
    Australia
    It will and should, why? :)

    I added one of these to the AUTOSTARTS group if you want to check it out, controlseto_O
     
  5. gottadoit

    gottadoit Security Expert

    Joined:
    Jul 12, 2004
    Posts:
    601
    Location:
    Australia
    Time for some sleep I think

    It looks like more than one rule will trigger if an earlier triggered rule didn't have an action

    ie: group window currently looks like :

    #1 hkey_classes_root\*~\shell\open\command mod key+mod value Ask
    #2 hkey_classes_root\*file\shell\open\command mod key+mod value Ask
    #3 hkey_classes_root\o_Ofile\shell\open\command mod key+mod value Ask
    #4 hkey_classes_root\comfile\shell\open\command mod key+mod value Ask
    #5 hkey_classes_root\exefile\shell\open\command mod key+mod value Ask

    If I change any one of 2, 3 or 4 to trigger on read value then I get an alert box
    I might have expected from the earlier description that one of those 3 rules might have been "first" and stopped further evaluation

    NB: Obviously #1 is a no-op, I just haven't deleted it yet

    edit: corrected rule 2 to have *file - I was a little cut'n'paste happy

    edit2: in response to the earlier "you don't need to know the order" .... maybe not but I'd like to know the order and exactly how it all works - its just my inquisitive nature I guess
     
    Last edited: Apr 11, 2005
  6. Bowserman

    Bowserman Infrequent Poster

    Joined:
    Apr 15, 2003
    Posts:
    510
    Location:
    South Australia

    Hi gottadoit.

    Just add these 2 entries instead of your three:

    #1 hkey_classes_root\*\shell\open\command

    Tick "Contains wildcard characters" and tick both Modifies and set to Ask User


    #2 hkey_classes_root\? ? ?file\shell\open\command without the spaces between the ? marks.

    Tick "Contains wildcard characters"and tick both Reads and set to Ask User


    Regards,
    Jade.
     
  7. gottadoit

    gottadoit Security Expert

    Joined:
    Jul 12, 2004
    Posts:
    601
    Location:
    Australia
    Jade,
    Thanks for the reply but I am only using the read (and the multiple entries) to trigger the alert so that I can test to see what is going on under the hood

    I do understand that * will work, but seeing as I have been working with regular expressions and wildcards for many years I always like to specify a pattern that exactly matches what I intend
    Using * could potentially match more....

    At least wildcard discussion has come up fairly soon after the release so that people will have something to read about in addition to what is in the help file...

    Regards
     
Thread Status:
Not open for further replies.