EEDK - Batch file querying Registry

[McSecurity]

I can't for the life of me get a batch file loaded into EEDK to query the registry and return a value. Backstory is I have a script to collect some data from both registry, and running processes to return version number and process running state.

The portion of my script is successful to return the state of running processes, however, anytime I try to call reg.exe I never get any data from it. This script works fine when run locally and also when run locally under SYSTEM context.

Example successful line for querying service running state:

for /f "tokens=4" %%F in ('sc query CMGShield ^| findstr STATE') do set cmgstatus=%%F

Example registry query that doesn't return any results when run from EPO via EEDK package:

FOR /F "skip=2 tokens=3,*" %%B IN ('reg.exe query "HKEY_LOCAL_MACHINE\SOFTWARE\Dell\Dell Data Protection\Encryption" /v "ProductVersion"') DO set "DDPE=%%B"

For what its worth i've referenced the large community thread on EEDK which suggests using 

%comspec% /c %systemroot%\System32\reg.exe

and also:

start /B /Wait reg.exe

I'm by no means an expert on batch scripting but I have made other successful EEDK scripts before to deploy third party software, etc. And I know this works locally so it must be something with how the script is loading via McAfee Agent where it can't kick off reg.exe successfully. Any help would be appreciated.

For reference here is the whole script:

:: Set environment to current product folder
pushd "%~dp0"
:: Get software package source directory and set as variable SRCDIR
SET SRCDIR=
for /f "delims=" %%a in ('cd') do @set SRCDIR=%%a

:: Gather product versions

FOR /F "skip=2 tokens=3,*" %%B IN ('%comspec% /c %systemroot%\System32\reg.exe query "HKEY_LOCAL_MACHINE\SOFTWARE\Dell\Dell Data Protection\Encryption" /v "ProductVersion"') DO set "DDPE=%%B"

FOR /F "skip=2 tokens=3,*" %%C in ('%comspec% /c %systemroot%\System32\reg.exe query "HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\WSS Agent" /v "Version"') do set "bluecoatversion=%%C"

FOR /F "skip=2 tokens=3,*" %%D in ('%comspec% /c %systemroot%\System32\reg.exe query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{099385D0-F0AD-45C9-A0A1-F18CD845F21C}" /v "DisplayVersion"') do set "symantecversion=%%D"

FOR /F "skip=2 tokens=3,*" %%E IN ('%comspec% /c %systemroot%\System32\reg.exe query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\CmgShield" /v "Server"') DO set "ddpeserver=%%E"

:: Gather service status

for /f "tokens=4" %%F in ('sc query CMGShield ^| findstr STATE') do set cmgstatus=%%F

for /f "tokens=4" %%G in ('sc query EDPA ^| findstr STATE') do set symantecstatus=%%G

for /f "tokens=4" %%H in ('sc query wssad ^| findstr STATE') do set bcstatus=%%H

:: Timestamp for last script run time.

for /F "usebackq tokens=1,2 delims==" %%K in (`wmic os get LocalDateTime /VALUE 2^>NUL`) do if '.%%K.'=='.LocalDateTime.' set ldt=%%L
set ldt=%ldt:~0,4%-%ldt:~4,2%-%ldt:~6,2% %ldt:~8,2%:%ldt:~10,2%:%ldt:~12,6%

:: Write data to McAfee Agent Custom Props

"C:\Program Files\McAfee\Agent\maconfig.exe" -custom -prop1 "DDPE: %DDPE%; Symantec WSS: %bluecoatversion%; Symantec DLP: %symantecversion%" -prop2 "DDPE: %cmgstatus%; Symantec WSS: %bcstatus%; Symantec DLP: %symantecstatus%" -prop3 "DDPE Server: %ddpeserver%" -prop4 "Last Script Run: %ldt%"

:: Send data to McAfee EPO server

"C:\Program Files\McAfee\Agent\cmdagent.exe" /p

[McSecurity]

For what its worth here's what it looks like in EPO when its run, one from an EPO task, and once locally where it is able to write the data successfully to the EPO custom props keys.Run via EPO task, version data and server data missing.Run locally from system, all data is supplied.

[cdinet]

You might want to enable some audit logging for all failure events to see if there is some permission issue with it. So your script does write some things, just not all, to be clear? You can also run procmon to see if there are any access denied entries when running the task.

[McSecurity]

Yes it can write the service state that I gather using "sc query" but anything I do using "reg query" doesn't work. My last post includes screenshots showing working (run locally) and not-working (run via EPO) results. The working state should publish the version numbers of each product I am checking in the registry.

It works just fine when running the batch script locally as "SYSTEM" by launching PSExec and running a command prompt as SYSTEM and then running the batch file. This is the advised testing method according to the EEDK documentation.

I don't think its a permissions issue because I have tested it as SYSTEM. I have a feeling after reading several of the community posts on EEDK (https://community.mcafee.com/t5/Documents/ePO-Endpoint-Deployment-Kit-9-6-1-Enterprise-Edition/ta-p/...) that it has something to do with the way reg.exe is invoked during the batch file processing that is different when McAfee Agent is doing it vs. when I am running it locally as SYSTEM. I don't know what it needs to invoke reg.exe properly.

I'm looking for someone who has successfully run batch scripts to query registry data using EEDK to hopefully shed some light on it.

[JoeBidgood · Accepted solution]

I suspect this is due to the bitness of the version of reg.exe. When you run it manually you're running the 64bit version, but when the agent runs it it's using the 32bit version. If the reg values you're querying only exist in one location then it's likely that reg.exe is running, but not finding them.

Try overriding the default location with the /reg: switch to specify the correct location - for example if the the Dell key in the first variable is only in the HKLM\Software\Dell hive, try the following:

 FOR /F "skip=2 tokens=3,*" %%B IN ('%comspec% /c %systemroot%\System32\reg.exe query "HKEY_LOCAL_MACHINE\SOFTWARE\Dell\Dell Data Protection\Encryption" /v "ProductVersion" /reg:64') DO set "DDPE=%%B"

[McSecurity]

Hi Joe,

Thanks for the suggestion but I tried this and unfortunately it did not work.

[McSecurity]

Actually you know what, scratch that, it did work. Had another issue on my side but adding the /reg:64 does seem to have fixed it.

Thanks a lot I appreciate it!

[JoeBidgood]

Excellent news - you had me worried there for a moment 🙂
It had worked for me so I was wondering what was different...