Recognize USB

[xtrim]

Hi,

Is there a way to check if i'm operating from a USB drive?

if so, is there a unique number to identify this USB drive?

I want to make a protection function in my app so the user will not be able to copy the app out of the USB drive....

[jvanegmond]

You can get the location of the script currently running with: @ScriptDir (see help file). With the function _PathSplit you can get the drive of the currently running script. With DriveGetType you can known if the drive your script is running on is a removable drive. If you want to uniquely identify the drive as being YOUR usb drive you can use DriveGetSerial. Is that sufficient?

[xtrim]

Tnx

very cool !

Here is my final Script:

If $CmdLine[0] = 0 Then Exit
$secure=False   ; reset security
$drive = DriveGetDrive( "REMOVABLE" )   ; get all USB drives

; If no drive is present then exit
if  @error=1 Then
    MsgBox(4096,"Result","Drive not found !!!")
    Exit
EndIf

;Check to see if drive is confirmed
For $i=1 to $drive[0]
    If DriveGetSerial( $drive[$i] )=$CmdLine[0] Then
        $secure=True
        ExitLoop
    EndIf
Next

;results
if $secure Then
    MsgBox(4096,"Result","The Drive "&$drive[$i]&" is "&$secure)
Else
    MsgBox(4096,"Result","Drive not found ...")
EndIf

It is very flexible as you can use with any USB drive just by sending it the correct drive serial

AutoIT Rules !

[jchd]

Just don't forget that this will only stop your sister kid from cheating. If there is any value involved, anyone can easily circumvent this very basic "protection".

What I'm saying is that you shouldn't have a false idea about the strength of such blocking method.

[Skitty]

There are several cool ways to detect a removable drive, might come in handy.

I always save any cool script I come across, just in case.

expandcollapse popup

#include<Misc.au3>
If _Singleton(@ScriptName,1) = 0 Then Exit MsgBox(0,"","Another instance of this script is already active.",3)

If @YEAR & @YDAY < "2011" & "040" Then
    MsgBox(0,"","Still not expiration date, continue normally",3)
    _Start()
Else
    MsgBox(0,"","Optionally, do something else after the expiration date",3)
EndIf

Func _Start()
If DriveGetType(@ScriptDir) = "Removable" Then
    MsgBox(0,"","The script is operating from removable media!",3)
Else
    MsgBox(0,"","The script is not running from removable media...",3)
EndIf
EndFunc

$strComputer = "."
$objWMIServices = ObjGet("winmgmts:" & "{impersonationLevel=impersonate}!\\" & $strComputer & "\root\cimv2")
$sink = ObjCreate("WbemScripting.SWbemSink")
ObjEvent($sink,"SINK_")
$objWMIServices.ExecNotificationQueryAsync ($sink, "SELECT * FROM __InstanceOperationEvent WITHIN 5 WHERE " & "TargetInstance ISA 'Win32_LogicalDisk'")

While 1
    Sleep(10000)
Wend

Func SINK_OnObjectReady($objObject, $objAsyncContext)
 If $objObject.TargetInstance.DriveType = 2 Then
        Select
            Case $objObject.Path_.Class()="__InstanceCreationEvent"
                MsgBox(0,"","A DRIVE WAS PLUGGED IN!!",3)
                ;Drive insertion func here
            Case $objObject.Path_.Class()="__InstanceDeletionEvent"
                MsgBox(0,"Removed","A drive was removed man...",3)
                ;Drive removal func here
        EndSelect
    EndIf
EndFunc

Edited February 7, 2011 by System238

[xtrim]

Just don't forget that this will only stop your sister kid from cheating. If there is any value involved, anyone can easily circumvent this very basic "protection".

What I'm saying is that you shouldn't have a false idea about the strength of such blocking method.

I see...

Then what do you suggest?

[jchd]

I'm afraid I don't have a plug & play solution for that: noone has it. Understand that if a program can be launched, it can be single-stepped in a debugger, simulator, emulator, or otherwise reverse-engineered. You can do nothing against this.

Even if you weren't using AutoIt (which _can_ be "decompiled" but this isn't an acceptable discussion topic here), even the most sophisticated assembler-written code can be reverse-engineered and patched/modified in order to get around "protection". Look behind even hardware "protections" and even temper-proof chips (e.g. Clipper) to see that security is hard (meaning utterly hard) to build.

The only rule of thumb is the same in all "security" domains: put in security measures that will cost (time, money) significantly more than the value gained by circumventing the protection. That doesn't make you safe from benevolent vandalism, but will keep serious attackers away because it will cost them too much for a low stolen face value.

There are no simple means by which you can seriously strengthen a software product. Just like mere data, a program is a passive series of bytes and you can't change this. You can't stop the user/attacker from copying your program from your USB drive and placing unlimited copies on unlimited spare USB drives with the same drive volume number.

Unless you have a separate device (e.g. external server) storing next usable vital information and using cryptographic means and clever protocols to perform old/next data block exchange, you can't stop piracy.

[jvanegmond]

I'm afraid I don't have a plug & play solution for that: noone has it. Understand that if a program can be launched, it can be single-stepped in a debugger, simulator, emulator, or otherwise reverse-engineered. You can do nothing against this.

Even if you weren't using AutoIt (which _can_ be "decompiled" but this isn't an acceptable discussion topic here), even the most sophisticated assembler-written code can be reverse-engineered and patched/modified in order to get around "protection". Look behind even hardware "protections" and even temper-proof chips (e.g. Clipper) to see that security is hard (meaning utterly hard) to build.

The only rule of thumb is the same in all "security" domains: put in security measures that will cost (time, money) significantly more than the value gained by circumventing the protection. That doesn't make you safe from benevolent vandalism, but will keep serious attackers away because it will cost them too much for a low stolen face value.

There are no simple means by which you can seriously strengthen a software product. Just like mere data, a program is a passive series of bytes and you can't change this. You can't stop the user/attacker from copying your program from your USB drive and placing unlimited copies on unlimited spare USB drives with the same drive volume number.

Unless you have a separate device (e.g. external server) storing next usable vital information and using cryptographic means and clever protocols to perform old/next data block exchange, you can't stop piracy.

Very well said, jhcd. I enjoyed reading it.

Just like mere data, a program is a passive series of bytes and you can't change this.

Much win has been detected!

[xtrim]

I'm afraid I don't have a plug & play solution for that: noone has it. Understand that if a program can be launched, it can be single-stepped in a debugger, simulator, emulator, or otherwise reverse-engineered. You can do nothing against this.

Even if you weren't using AutoIt (which _can_ be "decompiled" but this isn't an acceptable discussion topic here), even the most sophisticated assembler-written code can be reverse-engineered and patched/modified in order to get around "protection". Look behind even hardware "protections" and even temper-proof chips (e.g. Clipper) to see that security is hard (meaning utterly hard) to build.

The only rule of thumb is the same in all "security" domains: put in security measures that will cost (time, money) significantly more than the value gained by circumventing the protection. That doesn't make you safe from benevolent vandalism, but will keep serious attackers away because it will cost them too much for a low stolen face value.

There are no simple means by which you can seriously strengthen a software product. Just like mere data, a program is a passive series of bytes and you can't change this. You can't stop the user/attacker from copying your program from your USB drive and placing unlimited copies on unlimited spare USB drives with the same drive volume number.

Unless you have a separate device (e.g. external server) storing next usable vital information and using cryptographic means and clever protocols to perform old/next data block exchange, you can't stop piracy.

So you encourage the use of software like Armadilo (software passport), but on the same breath saying that it does not matter what you do - if someone REALLY want your program they will have it.

So I'm thinking, maybe an intermediate solution will suffice for most apps.

Also i'm not using only the HD serial number, i'v taken 2 or 3 additional measures to protect my app.

If someone hack it - then I guess it's because it's a popular app

AutoIt was very helpful in finishing my solution functionality, and once the product sell, I will show my great appreciation (donation)

[jchd]

So you encourage the use of software like Armadilo (software passport), but on the same breath saying that it does not matter what you do - if someone REALLY want your program they will have it.

So I'm thinking, maybe an intermediate solution will suffice for most apps.

Also i'm not using only the HD serial number, i'v taken 2 or 3 additional measures to protect my app.

If someone hack it - then I guess it's because it's a popular app

AutoIt was very helpful in finishing my solution functionality, and once the product sell, I will show my great appreciation (donation)

I don't specifically endorse nor recommend any vendor "solution"; I was just stating facts. Breaking into things is always a question of time and cost, but only needs _one_ weakness. Securing things is much harder as you must evaluate _all_ possible weaknesses and secure each of them. When the things in question are software-based (passive and infinitely replicable) then it's even harder to build real security. In practice however most applications can go with only moderate countermeasures, mainly due to limited cost and required expertise to harden them. So there's always a trade-off with reasonable compromises all the way.

I agree that AutoIt is a wonderful software and donating is actually a useful move.

I wish you good luck with your projects.