views:

660

answers:

6

Hi,

Is it possible to restrict a .NET executable to a specific machine somehow so that it can only be run on that machine.

+2  A: 

Can't use the processor id and check it everytime(?)

Here is a sample code which I wrote some time back.

Imports System.Management

Public Class Form1

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

        'Declare following three object variables

        Dim objMOS As ManagementObjectSearcher
        Dim objMOC As Management.ManagementObjectCollection
        Dim objMO As Management.ManagementObject

        'Now, execute the query to get the results
        objMOS = New ManagementObjectSearcher("Select * From Win32_Processor")

        objMOC = objMOS.Get

        'Finally, get the CPU's id.
        For Each objMO In objMOC
            MessageBox.Show("CPU ID = " & objMO("ProcessorID"))
        Next

        'Dispose object variables

        objMOS.Dispose()
        objMOS = Nothing
        objMO.Dispose()
        objMO = Nothing

    End Sub
End Class
Shoban
CPU ID didn't used to be a reliable unique ID. Has that changed?
John Saunders
It may not be a reliable solution. but one of the solution (?) ;-)
Shoban
A: 

I presume if you right clicked on the file and accessed it security setting, you could remove all user who cannot run it apart from the account that sits on that specific machine.

Of course this is the manual way, i dont know how to do this programatically.

kevchadders
What about a romaing account?
Shoban
A: 

Out of the box - no.

You can try generating a machine signature during installation and lock your application to not start when the signature file is not present or is not valid for this particular machine.

User
A: 

You could digitally sign your EXE and use certificates to aid some sort of protection, however if you truly want to prevent your EXE from running on a specific PC you might be better prompting the user for a password and using a key file?

.NET Encryption Examples http://aspnet.4guysfromrolla.com/articles/112002-1.aspx http://www.eggheadcafe.com/articles/20020630.asp

JamesM
+1  A: 

Assuming the machine has an NIC you can use the MAC address:

http://stackoverflow.com/questions/218284/read-mac-address-from-network-adapter-in-net

DrG
You can do that, but this is exactly one of the techniques that infuriates users. They should be able to update their networking equipment without having to inform their software vendors!
John Saunders
I completely agree. I'm just saying :D
DrG
On some systems, I've seen MAC addresses change on reboot. In particular one old IBM Thinkpad system.
Duncan Bayne
+3  A: 

Yes, and I do that in my apps. It works wonderfully.

Getting the system info (CPUID, MacID, HDD details) is easy using WMI (highly recommended).

I created a system that's practically foolproof (unless you're a pro hacker).

When my apps are installed for the first time on the user's PC, they go back to my server using web services. They identify themselves using a password hash and look for an authorisation code/order id for the client.

If the client has the correct authorisation code the application encrypts and stores the system details on the client's computer and sends a hash of the info to my server where it is stored. The software is then activated on the client's computer using some hashed flags and every time the app is run the system info is compared with the hashed info in the files.

If the client re-formats the computer, all he needs is the order id to activate the software again automatically (when the program checks with my server, the system details are verified and approved if they match). If the client installs the software on another machine he must contact my support team to get approval.

-- All the information is encrypted and hashed (double encryption). -- All code is obfuscated and packed.

It's working pretty securely at the moment.

So yes, it's possible, it's been field tested and found working as well as any other protection system.

Cyril Gupta
The problem with using WMI is that it requires the application to run as an admin for many of the most stable components (MAC address, HDD serial, etc.) This is a usability issue on Vista/Windows 7 where applications no longer have admin access by default.
Paul Alexander