No announcement yet.

Creating a unique ID "Algorithm" to make run an AMS project on a single machine.

  • Filter
  • Time
  • Show
Clear All
new posts

  • Creating a unique ID "Algorithm" to make run an AMS project on a single machine.

    I'm trying to find a find that my AMS project can only be used on a single machine.
    I think that I need to use a certain "path" from Regedit.
    Can anyone tell me which "ID" I could use to make understand AMS that the project has to be read on a single specific machine ?

    For instance : If I try to run the same project file on another computer, It'd immediatly block it. and show a message.
    Thank you ! ~

  • #2
    Edit : I'm trying to find a way*
    Not "find a find" <--


    • #3
      There is no specific "ID" associated with AMS that will deliver that outcome. This is something you would need to do though lua scripting in your project. And, if you want it to be somewhat reliable, you'll need to do more than just check a registry key. Perhaps looking at a combination of PCI card data, CPU and other such hardware would provide a more reliable mechanism by which to determine the PC identity.


      • #4
        Yes, I would grab a certain hardware ID, and then compare the two values.

        This is what I did sometime ago, to get the C: drive serial, and create a MD5 hash. This hash value then can be compared to the PC's value...

        strName = cdriveser;
        -- Calculate/create the MD5 checksum/algorithm for the C: drive serial display it on a label/input
        strDigitalSignature = Crypto.MD5DigestFromString(strName);
        -- Display MD5 hash in both Label and Input -- (beta dev ongoing)
        Label.SetText("LabelCOA3", strDigitalSignature); -- display hash on label or do something else with it - such as comparing it to an existing hash value.
        Input.SetText("InputCOA3", strDigitalSignature);
        Classic IT Support


        • #5
          Just going to chime in with a few points I think worth noting here. First, I concur with Centauri's observation that for something reliable, a combination of hardware identifiers is required. Ideally, those indentifiers should be from the hardware items that are the least likely to change on a user's system over time.

          John's suggestion about employing an MD5 hash algorithm is something I'd also concur with - however if choosing the Drive Serial as was suggested, at the very least it should be the immutable Hardware Serial, not the Volume Serial which changes every time a drive is reformatted. And if you do use the immutable Hardware Serial, retrieve it from the primary HDD (ie. System Drive) and use it in conjunction with at least one other hardware identifier (preferably two).

          I'm going to suggest here two different avenues of approach for retrieving a set of 3 unique hardware identifiers to lock your application to a specific machine. These are:

          - The BIOS Serial Number
          - The CPU Processor ID
          - The immutable Hardware Serial of the user's system drive.

          The first avenue of approach, utilizes some DLLs authored by our devs here. If memory servers me correctly, I think at least one of these DLLs was originally authored by IP (correct me if I'm wrong there, sensei - think I saw reference to the Netherlands in one of them). Attached below is a demo-apz which shows how to use these DLLs to retrieve the aforementioned hardware identifiers. It does NOT demonstrate how to employ John's suggestion of an MD5 hash algorithm - just simply how to return the 3 identifiers. (We can get to the matching & hashing later if anyone's interested).

          The second avenue of approach utilizes the WMIC to pipe these same 3 identifiers back into AMS via reteset's CommandLine plugin. (Plugin is attached below - be sure to install it first, if running the WMIC apz-demo). The advantage of using the WMIC is that the range of hardware identifiers which can be retrieved is virtually endless. But concentrating for the moment on the aforementioned 3 identifiers, here are the relevant WMIC commands:
          [I]-- Retrieve the BIOS Serial Number:[/I]
          wmic bios get serialnumber
          [I]-- Retrieve the CPU Processor ID:[/I]
          wmic cpu get processorID
          [I]-- Retrieve the primary HDD Hardware Serial:[/I]
          wmic diskdrive get serialNumber
          Nb. Just a cautionary note here about using: wmic diskdrive get serialNumber

          In Windows7, this can result in an "Invalid XML Content" error. Which occurs because the Windows XML parser treats control characters from the HDD Hardware Serial as invalid. Microsoft does have a hotfix for this here but you can circumvent the problem altogether by changing the command to:
          wmic path win32_physicalmedia where tag='\\\\.\\PHYSICALDRIVE0' get serialnumber

          Additionally, WMIC is also good for grabbing the Mainboard Serial.
          wmic baseboard get product

          And one final word on unique Hardware Identifiers. Probably, the single best way to ID a machine reliably is via the UUID. It's common to both Windows and Macs. And is a universally unique 32 character string. The following WMIC command will grab it:
          wmic csproduct get UUID
          Nb. Because some motherboard vendors may not include the UUID, is best to employ it in conjunction with at least one other of the aforementioned identifiers.

          So, also attached, is a demo-apz showing how to pipe each of these identifiers from WMIC back into AMS, via the CommandLine plugin. Again, it's just showing how to retrieve the identifiers (the hash algo & checking we'll leave for another time).

          Caveat: All WMIC commands tested in WinXP & Win7 (but not Win10).

          If you need an more robust solution, I'd recommend looking into a commercial solution such as IntelliLock:

          Attached Files


          • #6
            Oops, left some superfluous functions in the first demo-apz (Unique Harware IDs via DLL).
            Grab this update instead:
            Attached Files


            • #7
              Hi Guys,
              Found this in my archives

              from microsoft
              A GUID is a 128-bit integer (16 bytes) that can be used across all computers and networks wherever a unique identifier is required.
              Such an identifier has a very low probability of being duplicated.
              Hope this helps,


              • #8
                Originally posted by colc View Post
                Hi Guys,
                Found this in my archives...

                Hope this helps,
                Interesting ... one of Riz's old DLLs. Didn't know we even had that one.
                Very useful.Thanks, Col.

                Nice find.


                • #9
                  Im pretty sure ulrichs crypto plugin also has the ability to grab a hardware identifyer.