Setting up CUDA environment in Visual Studio 2017

In this post I will briefly summarise two issues I came across while trying to setup the development environment for CUDA. CUDA is an environment that allows you to code the application with support of potent computational capabilities of your GPU-s. In my case, I wanted to utilise the power of NVIDIA GeForce 1050 Ti card. The idea of having this SDK is to facilitate a way for your application to distribute processing over parallel processing and multithreading. You can download CUDA SDK from https://developer.nvidia.com/cuda-downloads. (I used 10.1 version and Visual Studio 2017).
Having downloaded and installed CUDA SDK (which takes some time), I tried to compile the deviceQuery utility - the example that, if compiled ok, would show you the attributes of your GPU.
This is where the troubleshooting started. First of all, the compilation did not work due to missing Microsoft 10 SDK 10.0.15063.0 component. This can be easily installed by modifications in the Visual Studio. Go into the Control Panel->Programs->Programs and Features->right click on "Microsoft Visual Studio Installer" and select "Change".

That solved the first problem, but the next one was also tied to the compilation process- a number of include files were not found. So, I first searched to locate them on the disk.
I soon realised that "ucrt" was not added in the Visual Studio environment variable , so I moved on to append this path to the appropriate VS 2017 variable.

After this modification, the compilation finally generated valid deviceQuery.exe.
Upon starting the deviceQueery.exe, its execution did not identify any CUDA capable devices. I realised that the whole CUDA installation process somehow somewhere corrupted my original GeForce driver. deviceQuerry reported "error 999" - "unknown error". When I opened device manager and checked the driver capabilities of NVidia Driver, I noticed a little yellow exclamation point and a Windows message saying that the driver's signature was not recognised and file might have been maliciously modified. I had to manually update the GeForce driver and rerun the deviceQuery.exe. This time all worked as expected.
Last point I wish to make - the driver update was also quite cumbersome. First the NVidia utility reported it cannot scan the system so I had to use the GeForce Experience utility to create account and login into NVidia kind-of-support portal which scanned my system and downloaded and installed proper driver. Not sure why I had to put my birthdate (!) to download and install the driver.

Comments

Post a Comment

Popular posts from this blog

Signature verification bypass vulnerability in some Huawei routers

Image
This blog will describe the discovery of the digital signature bypass on some Huawei routers.  The idea of digital signature check is simple - you have a piece of code and you calculated the checksum/hash of that file. The hash or checksum can be thought of as a "signature", a mathematical value that is uniquely assigned to the code (in our case the code was a firmware file). As soon as you change anything in the file and recalculate the hash, it should be significantly different from the original value - that is the feature of the hashing algorithm. Even the small change in the code will change the hash significantly. Vendors in most cases provide the such a pre-calculated hash so that the customer or the system may check if the hash of the image is indeed the same as vendor required. What was found in this investigation was that the system command on the Huawei AR1220E router does not perform this check properly. As a consequence, the attacker might be abl
Read more

Attacking encrypted VOIP (SIP) protocols

Image
In this post I will be explaining the approach in attacking the encrypted voice over IP (VOIP) protocol, more specifically, SIP (Session Initiation Protocol).  When we are talking about the SIP encryption, it will most likely assume some kind of SSL/TLS wrapping (SIP over TLS). An example below shows the solution design that allows interception, decryption and manipulation of SIP messages. The central component consists of mitm_relay.py and BURP. It is not required that both BURP and mitm_relay run on the same machine, but my setup did run both of them on the same virtual instance. The communication chain looked like this: Client -> mitm_relay->BURP->SIP Server->Client 2 The mitm_relay.py is a python script available at https://github.com/jrmdev/mitm_relay Before we fire up the mitm_relay, we need to configure couple of things- its certificate (self signed in my case, and private key). Once this is in place, we can run it: Few details about the mitm_relay setup:
Read more

DNS insights - UDP vs TCP and EDNS

Image
In this article I will elaborate the research I did in relation to DNS (Domain Name Service). The particular issue discussed here is when and how DNS uses TCP or UDP transport layer in relation to the packet size. Normally, DNS will run queries and replies via UDP protocol unless there is a Zone Transfer , incremental or full (IXFR or AXFR , respectively). According to the original DNS specification as given in the RFC 1035 (https://www.ietf.org/rfc/rfc1035.txt), DNS will also use TCP for packets larger than 512 bytes. However, there was another RFC issued in 2013 which is RFC 6891 (Extension Mechanism for DNS), labelled as EDNS(0). https://tools.ietf.org/html/rfc6891 I came across this issue accidentally, but as we will see in the text, some issues were noticed that are some not well documented reasons why DNS may fail to comply with EDNS. To do the proper investigation, here are some assumptions I worked with: a) I wanted to check DNS clients from both Windows and Linux b) I wan
Read more