I distribute a client application where I would like to identify a user's hardware specifications when they begin interacting with my server. I am specifically interested in identifying the user's GPU make and model, but I would appreciate hearing techniques applicable to other facets of the hardware such as CPU or RAM.

Users are aware that I seek to collect this information and have consented to its collection. Currently, the client is self-reporting what their hardware specifications are to my server. Most of my users are honest, but we can consider some of them as attackers seeking to lie about their hardware specifications.

My first thought is that I could issue a challenge to the client from the server that requires them to use their GPU in a manner such that I could benchmark it based on the response time, similarly to how GPU mining works. My concern with this approach is that I might not be able to achieve enough granularity to distinguish between GPUs with similar performance.

I know that the attacker in this case has physical hardware access and as such I am in fact hosed as far as perfect identification is concerned. As an example for the intents of this question, if the attacker has the capacity to solve my challenge such that I believe they are using an NVIDIA 2080 Ti when they are in fact using some specialized hardware of equivalent strength, then that is acceptable.

Any tools, techniques, or existing software options that could help me achieve this would be much appreciated. Thank you!

closed as off-topic by Steffen Ullrich, Ghedipunk, drewbenn, MechMK1, Graham Hill Aug 12 at 13:58

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question does not appear to be about Information security within the scope defined in the help center." – Steffen Ullrich, Ghedipunk, drewbenn, MechMK1, Graham Hill
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Scrypt has a memory-hard function that is supposed to be easy to compute when you have the memory, and hard to compute when you have not. Maybe that can be adapted to an algorithm which can prove that the client has a certain amount of memory available. – Sjoerd Aug 7 at 18:36
  • Why do you need to know? For example if you're going to farm out work (anything from distributed calculations to specifying the settings for local rendering of games) to the clients, shouldn't you be keeping your own stats, anyway, and basing future decisions on the actual results you've gotten? – drewbenn Aug 7 at 19:42
  • 2
    I don't see an information security problem here, i.e. I consider this question as off-topic. Maybe it gets on-topic if you provide a use case why you need to detect the hardware in the first place and show how this is needed in the context of information security. In general: unless you have sufficient control over the clients system you cannot hinder the client to send faked information. – Steffen Ullrich Aug 7 at 19:48
  • 2
    @TimClancy: As the question is currently it looks like an XY problem to me. X is the unknown problem you are trying to solve and which might or might not be related to information security. Y is your idea of a solution which involves finding out about the hardware in a way the user cannot fake. I recommend that you don't concentrate too much on finding a solution to Y since there is no foolproof one as long as you don't control the users system. Instead provide more information about the problem X you are trying to solve with Y. – Steffen Ullrich Aug 7 at 21:05
  • 1
    @TimClancy: "... I would like to be able to have this information available for the sake of analytics with some reasonable sense of confidence in its reliability." - this sounds more like your real problem X. But "for the sake of analytics" is not an information security problem either so I still feel this question is off-topic. Given that you assume that some users will fake these information I would expect to be some security problem here (i.e. users would gain something if they fake the information) but you don't provide this. – Steffen Ullrich Aug 7 at 21:23

You may be overthinking the problem.

If you distribute a client to them, you can just query the OS directly. The best route is likely to ask users for their specs and query silently; they are unlikely to put forth the (rather substantial) effort to fabricate data if they don't know you are collecting it.

On Windows, you could query the Win32_VideoController class via WMI to identify their hardware. E.g.,

wmic PATH Win32_VideoController GET *

You could specify Name, PnPDeviceID, or DeviceID instead of * if you want to minimize the amount of data you collect.

Note that while this is a command line utility, WMI is exposed for application use; you do not need to rely on the native utility if you'd rather query directly.

This data is readable by locally-executed applications by default, and WMI permissions are rarely hardened due to their widespread use by regular applications as well as 3rd-party management tools.

  • 2
    If the client reports back the computer has a NVIDIA 2080 Ti, how can we know whether that is really the case? Maybe the client has been tampered with, or maybe the user directly sends a fake message to the server. – Sjoerd Aug 7 at 19:39
  • 1
    You have to compromise the OS pretty severely, and WMI data is a live repository, so there are stability/availability issues if it is tampered with. Anyone who can intercept and answer/redirect WMI calls is likely able to bounce your queries/commands to a remote sandbox for execution/analysis as well. The question is interesting as it relates to fingerprinting, but the approach is unnecessarily complicated for a legitimate, authorized application. – DoubleD Aug 7 at 19:53
  • I'm with @Sjoerd here, one does not need to compromise the OS at all to send us a fake message. It would be a trivial attack to snoop on messages between the client and our server and send false information. – Tim Clancy Aug 7 at 20:24
  • You say the attacker has fully compromised the client. So not only wmi can be messed with, but also any cpu test. It is quite ridiculous to try to protect against this scenario. – user2679290 Aug 7 at 20:57
  • In this scenario, you can only trust public encrpytion schemes where the private key is outside the reach of the attacker. For example, data protected by credguard. But anyway, it seems that the topic was overstretched – user2679290 Aug 7 at 20:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.