I have an application and I'm trying to make sure it's running in a secure environment. First of all, I check if Windows is genuine, which makes it more likely that the user keeps it up-to-date. If not, I just pop up a message warning the user there's a possible risk because he still needs to validate Windows.
Now, I want to do a bit more. I also want to check if the user has installed a virusscanner. I don't care which one, as long as he has installed one. Then the same for checking if a firewall is installed. And if possible, I want to check when the user updated his Windows/Scanner/Firewall the last time just to make sure it's not too old. So:
1) How do I check if a virusscanner is installed?
2) How do I determine when the virusscanner was updated?
3) How to detect when the virusscanner did it's last full-system check?
4) How do I detect if a firewall is installed and active?
5) How do I check when Windows received it's most recent update?
Basically, when my application starts I want to display a screen with warnings (just once per day) just in case any of these things have a problem. This because my application works with all kinds of sensitive information that the user collects from his clients. (Which includes bank account numbers, ID numbers of passports, NAW+DOB, income and a lot more.) Basically, if the system has a problem, the user must confirm that he's aware of these problems. It takes the possible liability away from my application if he continues while knowing his system is possibly insecure...And language? Basically C++ or Delphi for WIN32 examples and C# for .NET examples. It's more about .NET/Windows API/.NET than language.
I think you can do most of this via WMI
Something like this:
ManagementObjectSearcher wmiData = new ManagementObjectSearcher(#"root\SecurityCenter", "SELECT * FROM AntiVirusProduct");
ManagementObjectCollection data = wmiData.Get();
foreach (ManagementObject virusChecker in data)
{
// This is the virus checkers name.
String virusCheckerName = virusChecker["displayName"];
}
[You didn't mention what language, so the sample above is in C#, but WMI can be done from pretty much anything]
[Edit: You can do the same but with "FirewallProduct" instead for firewall info. Also, for the anti virus, you can look at the "productUptoDate" property on the results for info on if it's up to date]
The WMI reference should help you find the others. (1, 2, 3, and 4 I'm pretty certain are available through WMI. 5 I'm not so certain about, but I think it probably should be)
You'll probably find WMI Code Creator helpful for testing and figuring out what queries/objects you need to use. Also Scriptomatic and WMI Admin tools might be useful.
Since I was looking for a C++ and not .NET depended way, I mixed between this answer and MSDN example: Getting WMI Data from the Local Computer.
The commands that need to be changed in order to get the AV name are:
_bstr_t(L"ROOT\\CIMV2") to _bstr_t(L"ROOT\\SecurityCenter2"). Keep in mind that SecurityCenter2 is for Win 7, Vista SP2 and beyond according to this. Below Vista SP2, you need to use SecurityCenter.
bstr_t("SELECT * FROM Win32_OperatingSystem") to bstr_t("SELECT * FROM AntivirusProduct")
hr = pclsObj->Get(L"Name", 0, &vtProp, 0, 0); to hr = pclsObj->Get(L"displayName", 0, &vtProp, 0, 0);.
This changed code has been checked and fully working.
For a simpler method you can always iterate over this algorithm and look for your AV by name.
Related
As read on topic here How to find the unique serial number of a flash device? and especially here How to get manufacturer serial number of an USB flash drive? I know it is possible to get properties of hardware devices (particularly hard drives and usb drives...) using WMI Win32_PhysicalMedia and Win32_DiskDrive, which I'm getting done successfully.
However, I really want to know about the safety of these informations.
PhysicalMedia property SerialNumber returns the actual serial number of the main hard drive, while using other Win32_LogicalDisk and other calls we can map the drive letter of flash storage to actual Win32_DiskDrive device, and from there read properties like Name, Model, FirmwareRevision, SerialNumber, DeviceID, Manufacturer...
Now, DeviceID is generated by Windows / Pc itself, while SerialNumber should be the one that manufacturer added to the physical flash drive.
Manufacturer in most cases returns "Standard" something, Name is also of no use, while SerialNumber actually gets me a something that looks like unique ID, (I've read that in some cases this is not returned, so PNPDeviceID should be used instead? , Model gives the actual model of the flash drive, and FirmwareRevision just a number that could be used to add safety switch to the licensing, but is not vital.
However, the only one of these that seems / should be actually safe to use is SerialNumber, right?
So, the question here goes: Which level is Win32_DiskDrive actually reading this info from? Is it possible to fake that at all (Ok, letalone the actual lowlevel hacking stuff or driver injection etc...(??)), and if so, how hard it is?
If there's a known way / guide / example, I'd be also happy to read it. (not necessary info looking for here though.)
This is not for intention of bypassing some licensing. I'm making licensing for my SW, and am curious, whether it would be safe enough to use USB drive's SerialNumber property, and lock license against the presence of that USB flash, for which the license was bought for? Basically to use it as kind of a dongle, but not like the dongles actually work (using communication with the actual hardware inside the dongle...)
I know it may not seem as a safe solution, as flash drives dies quite often these days, or get lost etc, but this is just to add an option to my licensing from "Per PC" to "Portable - per USB device".
Thanks for any info!!!
EDIT:
I am completely aware that bypassing these kind of safety switches is very possible. Of course, even Windows itself is not licensed in a way that couldn't be hacked, nor Adobe, ProTools etc, (software that is widely used and costs a lot!).
But that wasn't a real question, and also, that's not the case for me -> the software will not be that expensive and not used by that much people, that I'd be afraid to drag interest in someone who will do extensive programming to make a patch/crack for it. Regular debugger use and workaround is pretty unlikely to be used by regular client who would need the software, ( and also, since it is something to be used in business environment, where stability is vital, I doubt they will really play around that...).
Main point here:
It is possible for sure, but: HOW hard is it to do for a regular person? (I know, the answer is: depending on your code.)
Main question of the post: Is it possible to change the ID on the USB itself, OR to make an app that will fake that data to my app? If it is, I'm sure it might be easier than making a crack/patch, that's why I wanted to know, whether WMI reads explicitly from hardware, or could one make an app that would pass fake data to it?
WMI just returns what the hardware tells it. It's as unique as the hardware. Which ultimately depends on the vendor.
But...
If someone has an administrator account to the computer†, then there are very few things that can be done to keep them from just hooking up the kernel debugger to your program and overriding your checks, or recording the raw USB communication session and replaying it on an unauthorized system. The real dongles do some to mitigate this, by having the hardware generate a response to a particular challenge. The challenge/response changes for each request, so it's not as susceptible to replay attacks, but the debugger tricks still work.
This is the real problem with the serial number approach. Uniqueness is not the primary concern for dongled software. The primary concern is unpredictability.
An illustrative example-
Let's say that I'm a bouncer at an exclusive night club. We're so exclusive that you have to answer a question to get in. You really want to get in, but no one will tell you the answer to the question. One night, you hatch a plan. You hang out in the alley and listen to the conversations that I'm having with the patrons trying to enter the club. It doesn't take you long to realize that I'm asking everyone the exact same question, and you're in. (This is the serial number approach)
After a while, I notice that there are a lot of people coming into the club that I've never seen before, and begin to suspect something. The people we really want to allow in are all given a card with a formula‡ on it. Whenever they come to the door of the club, I give them a number and they apply their formula and tell me the result. Since I also know the formula, I can tell if they are really allowed in. Now, even if you hear the entire challenge and response, without the formula, you aren't getting in. (This is one common approach taken by dongles.)
But what about the debugger? The debugger just made herself the club's owner, fired me, and can come and go as she pleases.
†Or has physical access to the machine and a password reset disk.
‡Stop laughing, this could totally happen. :)
Photo credit: Guillaume Paumier, CC-BY. Found on the Wikimedia Commons 7-Oct-15
Edit to address the question edit:
HOW hard is it to do for a regular person? (I know, the answer is: depending on your code.)
The question is how skilled is the 'regular person'? If you're talking about software/electrical engineers, then this is a trivial task. If you're talking about sales/marketing then it's a challenging task.
Is it possible to change the ID on the USB itself, OR to make an app that will fake that data to my app?
It depends and Yes. Changing the ID on the device itself is possible with some devices, and impossible with others. Software to spoof/man-in-the-middle the USB communication, or to create a virtual USB device is possible.
If it is, I'm sure it might be easier than making a crack/patch, that's why I wanted to know, whether WMI reads explicitly from hardware, or could one make an app that would pass fake data to it?
As I led with above, WMI reads from the hardware. This can be intercepted or bypassed.
Some ways to bypass the check:
Make a virtual USB device
Modify the USB MSD device driver to report the same serial number for all devices.
Build hardware using commercially available cheap host controllers that identifies with the same information as the authorized device. ($10 worth of raw components and a little bit of time.)
Redirect the system calls to/from USB to a compromised library.
Note also that:
Some places have restrictions on USB storage devices, ranging from discouraging their use, to outright bans. This would prevent your software from being used in sensitive computing environments processing private data, like credit cards, PII, trade secrets, classified information, etc. (In the US many governmental agencies have outright bans on USB storage devices, and block the install of any MSD.)
The Mass Storage specification doesn't require serial numbers. They are usually there, but they don't have to be, and many low-cost vendors
A USB PKI token costs a little bit more, but would probably do what you want. Here's an example from Safenet (Disclaimer: I am in no way affiliated with Safenet Inc, and you should evaluate all the possible options from all vendors. I suggested this because it was the first thing that came up through CDW, and the price was ~$30)
I am implementing SMBIOS reading functionality for Windows systems. As API levels vary, there are several methods to support:
trouble-free GetSystemFirmwareTable('RSMB') available on Windows Server 2003 and later;
hardcore NtOpenSection(L"\\Device\\PhysicalMemory") for legacy systems prior to and including Windows XP;
essential WMI data in L"Win32_ComputerSystemProduct" path through cumbersome COM automation calls as a fallback.
Methods 1 and 3 are already implemented, but I am stuck with \Device\PhysicalMemory, as NtOpenSection always yields 0xC0000034 (STATUS_OBJECT_NAME_NOT_FOUND) — definitely not one of the possible result codes in the ZwOpenSection documentation. Of course, I am aware that accessing this section is prohibited starting from Windows Server 2003sp1 and perhaps Windows XP-64 as well, so I am trying this on a regular Windows XP-32 system — and the outcome is no different to that of a Windows 7-64, for example. I am also aware that administrator rights may be required even on legacy systems, but people on the internets having faced this issue reported more relevant error codes for such scenario, like 0xC0000022 (STATUS_ACCESS_DENIED) and 0xC0000005 (STATUS_ACCESS_VIOLATION).
My approach is based on the Libsmbios library by Dell, which I assume to be working.
UNICODE_STRING wsMemoryDevice;
OBJECT_ATTRIBUTES oObjAttrs;
HANDLE hMemory;
NTSTATUS ordStatus;
RtlInitUnicodeString(&wsMemoryDevice, L"\\Device\\PhysicalMemory");
InitializeObjectAttributes(&oObjAttrs, &wsMemoryDevice,
OBJ_CASE_INSENSITIVE, NULL, NULL);
ordStatus = NtOpenSection(&hMemory, SECTION_MAP_READ, &oObjAttrs);
if (!NT_SUCCESS(ordStatus)) goto Finish;
I thought it could be possible to debug this, but native API seems to be transparent to debuggers like OllyDbg: the execution immediately returns once SYSENTER instruction receives control. So I have no idea why Windows cannot find this object. I also tried changing the section name, as there are several variants in examples available online, but that always yields 0xC0000033 (STATUS_OBJECT_NAME_INVALID).
Finally, I found the cause of such a strange behavior, — thanks to you, people, confirming that my code snippet (it was an actual excerpt, not a forged example) really works. The problem was that I did not have Windows DDK installed initially (I do have now, but still cannot integrate it with Visual Studio in a way that Windows SDK integrates automatically), so there was a need to write definitions by hand. Particularly, when I realized that InitializeObjectAttributes is actually a preprocessor macro rather than a Win32 function, I defined RtlInitUnicodeString as a macro, too, since its effect is even simpler. However, I was not careful enough to notice that UNICODE_STRING.Length and .MaximumLength are in fact meant for content size and buffer size instead of length, i. e. number of bytes rather than number of characters. Consequently, my macro was setting the fields to a half of their expected value, thus making Windows see only the first half of the L"\\Device\\PhysicalMemory" string, — with obvious outcome.
I have a software activation logic which relies on thre parameters:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate
Id of system volume
I'm interested in question: could these parameters ever change under any conditions except manual modification of registry values (for 1, 2) in single OS installation?
System volume id, as far as i know, can change only when the volume is formated.
Both DigitalProductId and InstalLDate also should be constant in single OS as they identify a license (concrete windows installation) and the date the OS was initially installes respectively. So according to this logic they shouldn't ever change.
I want to find any documentation that proves these points. Unfortunately my searching for such a documentation didn't give me enough as all that i've found are articles like this http://technet.microsoft.com/en-us/library/cc709644(v=ws.10).aspx which contain inderect information on the topic.
Also i've looked through this great post: http://siginetsoftware.com/forum/showthread.php?596-Investigating-the-Microsoft-Digital-ProductID-(DPID)
It partially proves my points but doesn't give a 100% guarantee
I repeat a question here once again:
Could parameters 1-3 ever change in single Windows installation?
Thanks in advance
My research has shown that independently of windows updates, service packs and other software, these keys remain the same.
I want to develop a program which keeps track of the amount of data written to my hard drive. I searched the Internet but didn't find the necessary API calls.
But they have to exist as I found a commercial program (www.hddled.com) which does exactly what I want to achieve and it even shows the amount of data read/written when it's started way after Windows was started. Thus I strongly suppose Windows keeps itself track of this figures somewhere?
In general, this sort of information is available through the Windows Performance Counters. In particular, the disk subsystem will publish (somewhere!) the number of bytes read and written to each disk device. Be prepared to do some digging to find exactly the information you are looking for.
Physically? Probably in the file file descriptor table.
After some further digging on the internet I found the perfect solution. It's called "Windows Management Infrastructure" and the following lines of C# code deliver the amount of read/written data during the a windows session, although the values' names are a little misleading:
ManagementObjectSearcher searcher =
new ManagementObjectSearcher("SELECT * FROM Win32_PerfRawData_PerfDisk_PhysicalDisk");
ManagementObjectCollection col = searcher.Get();
m.GetPropertyValue("DiskReadBytesPerSec");
m.GetPropertyValue("DiskWriteBytesPerSec");
foreach (ManagementObject m in col)
{
m.GetPropertyValue("DiskReadBytesPerSec");
m.GetPropertyValue("DiskWriteBytesPerSec");
}
Using VB6
I want to compare the system date, if the exe should not work after 02/11/2009
vb6 code
Dim dte As Date
dte = DateValue(Now)
'MsgBox DateValue(Now)
If dte > DateValue("01/11/2009") Then
Unload Me
End If
But if the user change the system date, it will work, my exe should not work after 10 days. How to set.
Need VB6 CODE Help.
There is no 100% secure way of doing this. Usually software doing that encrypts the date into some obscure registry key. But is not in accord with Kerkhoffs' principle.
Generally speaking you would have to persist the installation or first run date somewhere on the system (where users cannot easily modify or delete it) to compare it to the current system data. Beside this you shall protect your program against tampering attacks.
To protect against system time changes there is also no 100% good solution. An easy one would be to look at some files in the profile of the user and take the newest one. If this time is later than the current system time (with some delta), then someone manipulated the datetime settings.
All this is worth almost nothing, as it is really easy to workaround such a protection (even without deep programming knowledge). I would consider a solution in limiting the functionality of your program and protecting your code against tampering (what you have to do anyway, no matter what you choose as a solution).
The amount of effort to implement a truly robust date-based protection system is not proportional to the protection provided.
In any case, the last scheme I used seemed to work. I stored the last run date and number of days left in some obscure registry keys. Each time the app started I checked that last run date key was still in place and had a valid value and I checked the number of days left. Both these values were stored encrypted. To add a level of confusion I read and wrote a number of garbage keys in more obvious locations.
The trial expired if I found evidence of tampering such as changed garbage keys, a current date that was older than the last run date and a few other things.
To slow down users trying to hack the software I encrypted the names of the registry keys in the code so they wouldn't be obvious when the exe was viewed in a hex editor.
Was all that effort worth it? Probably not. I suspect a lot less would have detered most casual crackers and the serious ones, well, they would have cracked it anyway.
I my opinion, it is possible just save time difference between your exe release date and future locking date.
If user system clock is set back than release date give user to set it right and then simply check if exe is running before future locking date.
I think you got it……
Software copy protection is a big subject, and there's many possible approaches, from commercial libraries and hardware keys, to "roll your own" like you're suggesting.
I advise you read some of the other discussions on copy protection on Stack Overflow. E.g. this or this or this.