So yesterday there was a whole bunch of drama and angry shouting going on regarding the addition of telemetry to the Nvidia drivers.
See
http://www.majorgeeks.com/news/story/nvidia_adds_telemetry_to_latest_drivers_heres_how_to_disable_it.html
and
https://www.reddit.com/r/nvidia/comments/5b5v18/nvidia_adds_telemetry_to_latest_drivers_heres_how/.
As there was absolutely no information other than "There's a service from Nvidia with telemetry in the name!!!!" at the time, I decided to take a deeper look into it.
The majorgeeks website highlights the NvTmMon (Nvidia telemetry monitor), NvTmRep (Nvidia telemetry reporter) as well as NvTmRepOnLogon tasks as the telemetry additions.
Out of these two the most interesting one should be the reporter, as that should be the one that actually sends the data.
By opening up the task scheduler and looking at what the tasks actually do, we can see that it simply runs a program at a given time every day.
(the NvTmRepOnLogon does the same thing except calls the program with the argument "--logon").
After some debugging, and binary reversing I noticed that the program looked for the registry key "HKLM\SOFTWARE\NVIDIA CORPORATION\Global\iCafe" (https://www.nvidia.com/content/apac/icafe/en/driver.html, I had no idea this was a thing), but since I didn't have the iCafe driver installed, and therefore the registry key didn't exist, the program simply threw an exception and crashed, since Nvidia apparently hadn't heard about exception handling.
Surprised at how poorly implemented this was, I thought surely Nvidia must know about this, so I checked if there was an update available, and sure enough there was.
After updating geforce experience NvTmRep no longer crashed, since they added an exception handler.
This allowed me to see all of the registry keys they looked for, here they are in order:
HKLM = HKEY_LOCAL_MACHINE
HKCU = HKEY_CURRENT_USER
HKLM\SOFTWARE\NVIDIA CORPORATION\Global\iCafe
HKLM\SOFTWARE\NVIDIA CORPORATION\Global\GFExperience
HKLM\SOFTWARE\NVIDIA Corporation\Global\NVUpdatus
HKCU\SOFTWARE\NVIDIA Corporation\NvBackend
the program then continues by checking if the "installed" registry key is set.
Fun fact: if none of those registry keys exist the application seems to crash and call home (presumably to tell Nvidia that it crashed).
After its found a registry key (I can't remember if it stopped after finding the first or if it kept going but it's pretty irrelevant), the program connects to the service "NvContainerLocalSystem", and checks if it's set to SERVICE_AUTO_START (which means that it's "started automatically by the service control manager during system startup").
I got curious at this point and decided to see what this service did, luckily the struct that the QueryServiceConfig function returns includes just, that.
So it was as simple as peeking at that pointer :D
"C:\Program Files\NVIDIA Corporation\NvContainer\nvcontainer.exe" -s NvContainerLocalSystem -f "C:\ProgramData\NVIDIA\NvContainerLocalSystem.log" -l 3 -d "C:\Program Files\NVIDIA Corporation\NvContainer\plugins\LocalSystem"
Now comes the part that surprised me the most: if the service is set to run at startup, the program simply exits.
So as it is right now for this environment and this program, NvTmRep doesn't seem to be actually sending much data to Nvidia (however I'm sure Geforce Experience does atleast some).
Having come to this conclusion I decided to check whether the functionality to send data to nvidia was there, so I checked the strings in the binary and came upon these
text/plain
SHIM log
Telemetry lock acquired
Cannot add Poll Info record from file, skipping:
attribute
id
APIType
averageFrameRate
openTime
closeTime
maxFrameRate
minFrameRate
exeName
SLI_mode
SLI_numSLIAA
SLI_numSFR
SLI_numAFR
SLI_num
ActiveGpus
BatteryPercent
CordedPercent
0
Streamed
PerFrameCreateTimeHistogram
PerFrameCreateTimeDerivativeHistogram
PStateHistogram
DRSName
DRSUserFriendlyName
DRSProfileName
Invalid argument
Cannot create DRSSupport:
nvtmru
BlacklistedSessions
count
cumulativeDuration
UnmatchedSessions<!--Insert additional sections here-->
AccountInfo
UserId
as well as the address https://telemetry.gfe.nvidia.com/ which at the time resolved to 8.36.112.102
which only has a single port open and no services (atleast that shodan can see).
There's also functions inside NvTmRep dedicated to connecting and sending data via HTTP, that reference the strings listed above, so the functionality to send data is definitely there.
Also fwiw: if the program is called with the --logon argument, it makes a reference to "Logon argument found, checking FRL." that I have no idea what it means and haven't checked what the function call right after it actually does. After that it then references the string "Stopping logging", and calls yet another function.
TL;DR: NvTmRep isn't much to worry about right now it seems, however it has the ability to send the information if it wants to. I could also have missed some path of execution that would allow the data to be sent right now, I'm in no way perfect.