The VRAM memory included in the graphics cards is not part of the system’s RAM addressing and is for the exclusive use of the GPU, at least that is what happens on the PC where, unlike other platforms such as PostPC devices, both RAM as VRAM they do not have unified addressing. This difference in the way of handling access makes all memory space not directly accessible by the CPU as the ideal hiding place so that antivirus programs do not detect malicious programs.
Well, viruses have taken a qualitative leap when it comes to avoiding control and they no longer only run using the system’s RAM and the main CPU, but now they make use of the hardware of your graphics card. That is, the GPU and VRAM, not only to run, but also to be undetected. Let’s see below how they have achieved it.
They manage to run viruses from the graphics card
The way is very simple: they have taken advantage of the computing capabilities of the GPUs, which allow them to run programs apart from the generation of graphics, the main objective of this component. These types of programs are often used to perform high-speed parallel calculations and, in combination with the CPU, allow accelerating the performance of certain algorithms by several orders of magnitude compared to using only the CPU.
How did they get viruses to run on the Graphic card? For this they have used the OpenCL 2.0 API, which allows them to copy the virus code from RAM to VRAM. Let’s not forget that only the GPU has exclusive access to the VRAM which is from where the malicious part of the code is executed. While the benevolent part runs on the CPU in combination. This cannot be detected by antivirus due to the fact that when they check the memory they can only detect the devices in the memory space or address of the CPU, which makes the VRAM escape from their scrutiny.
In the event that you are users of an operating system other than Windows, you do not have to worry, at least for the moment, since this can only be done in the Windows version of the OpenCL 2.0 computing API. We do not know if due to characteristics of the operating system or the API controller itself. In any case, it is a nail in the coffin of OpenCL 2.0, especially when version 3.0 is not an improvement of the first one, but is simply an optional upgrade as extensions that part of the real version 1.3.