So yesterday there was a whole bunch of drama and angry shouting going on regarding the addition of telemetry to the Nvidia drivers.
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
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
Telemetry lock acquired
Cannot add Poll Info record from file, skipping:
Cannot create DRSSupport:
<!--Insert additional sections here-->
as well as the address https://telemetry.gfe.nvidia.com/ which at the time resolved to 188.8.131.52
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.