Re: Weird behavior in 'grep'ing for string in /proc/registry...

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2020-09-07 01:53, Thomas Wolff wrote:
> Am 07.09.2020 um 09:05 schrieb Brian Inglis:
>> On 2020-09-06 23:34, L A Walsh wrote:
>>> In directory
>>> /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog
>>> I wanted to list all the ".dll"s that handled various types of
>>> events.
>>>
>>> I tried
>>> /bin/grep -Pr '\.dll'
>>>
>>> but got a load of bogus error messages:
>>>
>>> /bin/grep: Group: Is a directory
>>> /bin/grep: ImagePath: Is a directory
>>> /bin/grep: Description: Is a directory
>>> /bin/grep: ObjectName: Is a directory
>>> ....
>>>
>>> ---
>>> looking at ImagePath:
>>>> ll ImagePath
>>> -r--r----- 1 65 Sep  6 22:06 ImagePath
>>>> read -r x <ImagePath
>>>> echo $x
>>> C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted
>>>
>>> ---
>>> Doesn't look like a directory.
>>> So, bug in 'grep'?
>>>
>>> I'm hoping this isn't limited to my machine...
>> You remember that the /proc/registry.../ entries are only the keys, subkeys, and
>> values names, not the data contained in them.
>>
>> You are doing the equivalent of:
>>
>> $ fgrep -r .dll
>> /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog/Application/
>>
>> 2> /dev/null
>>
>> producing nothing but error messages.

> I reproduced Lindas observation (although not in the folder she mentioned which
> does not exist here) and in fact there is an inconsistency between `grep -r`
> reporting "Is a directory" for entries that are not marked as directory by `ls`:
> .pwd
> /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Appinfo/Parameters
> 
> .ls -l
> insgesamt 0
> -r--r----- 1 SYSTEM SYSTEM 34 27. Nov 2019  ServiceDll
> -r--r----- 1 SYSTEM SYSTEM  4 27. Nov 2019  ServiceDllUnloadOnStop
> .grep -r .
> grep: ServiceDll: Is a directory
> grep: ServiceDllUnloadOnStop: Is a directory
> 
> I checked whether `opendir` marks the d_type fields wrong in the /proc
> filesystem but that's not it.

I believe we are seeing that the registry fs virtualization is insufficient for
grep and some other utilities to differentiate, so they are complaining, not
descending and searching.

So you can do what you want using:

$ find
/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog/Application/
-type f -print0 | xargs -0 fgrep -a .dll

but you need the -a as the file contents appear as binary strings with NUL char
terminators (and these appear in the output), not text files with \n terminators.

My alternatives convert the values and data to text on lines which you can
search with clean results.

You could strace your problematic searches and post along with cygcheck.out and
hope someone has time to dig in and debug the issue.

>> What you probably want to do is check for the keys, subkeys, and values data
>> containing .dll names, which is best performed with find and regtool:
>>
>> $ find
>> /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog/Application/
>>
>> -type d -print0 | xargs -0 -l1 regtool list -v | fgrep .dll
>> DisplayNameFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\wevtapi.dll"
>> EventMessageFile (REG_SZ) = "C:\Windows\System32\mscoree.dll"
>> EventMessageFile (REG_SZ) = "C:\Windows\System32\mscoree.dll"
>> CategoryMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\wevtapi.dll"
>> CategoryMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wer.dll"
>> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wer.dll"
>> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wersvc.dll"
>> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\ieframe.dll"
>> CategoryMessageFile (REG_EXPAND_SZ) =
>> "%SystemRoot%\System32\drivers\ati2erec.dll"
>> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\drivers\ati2erec.dll"
>> ...[90]...
>> EventMessageFile (REG_SZ) = "C:\Windows\SysWOW64\msvbvm60.dll"
>> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wersvc.dll"
>> EventMessageFile (REG_EXPAND_SZ) = "%systemroot%\system32\sdengin2.dll"
>> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wer.dll"
>> CategoryMessageFile (REG_EXPAND_SZ) = "%systemroot%\system32\tquery.dll"
>> EventMessageFile (REG_EXPAND_SZ) = "%systemroot%\system32\tquery.dll"
>> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\wsepno.dll"
>> EventMessageFile (REG_SZ) =
>> "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\EventLogMessages.dll"
>> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\ntvdm64.dll"
>> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wshext.dll"
>>
>> or you could use the Windows reg command directly for more verbose results:
>>
>> $ reg query
>> HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\eventlog\\Application
>> /s /d /f "*.dll"
>>
>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application
>>      DisplayNameFile    REG_EXPAND_SZ    %SystemRoot%\system32\wevtapi.dll
>>
>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\.NET
>> Runtime
>>      EventMessageFile    REG_SZ    C:\Windows\System32\mscoree.dll
>>
>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\.NET
>> Runtime Optimization Service
>>      EventMessageFile    REG_SZ    C:\Windows\System32\mscoree.dll
>>
>> ...[104]...
>>
>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\WMI.NET
>> Provider
>> Extension
>>      EventMessageFile    REG_SZ
>> C:\Windows\Microsoft.NET\Framework64\v4.0.30319\EventLogMessages.dll
>>
>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\Wow64
>> Emulation Layer
>>      EventMessageFile    REG_EXPAND_SZ    %SystemRoot%\System32\ntvdm64.dll
>>
>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\WSH
>>      EventMessageFile    REG_EXPAND_SZ    %SystemRoot%\System32\wshext.dll
>>
>> End of search: 110 match(es) found.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]