How can I get the serial number of harddisk ?

[UserOfPure]

My dad has admin rights on his PC, yes. It's a fixed hard drive with letter C, formatted NTFS. Windows XP Professional is on that drive, and I installed it on his PC over a year ago myself. I don't live near him but he does swear it's returning 0000-0000 for him. I got him to do the cmd.exe test too and that DOES return the serial number. So, something's going on. Maybe his anti-virus is blocking access from the app or something, but he uses AntiVir like me and it works fine for me, so I don't know. My best guess is that yes, the code works fine, but something else is probably interfering with it accessing the hard drive. So if that's the case, then the tip still isn't 100% reliable as it can be blocked so easily from working. Imagine he is a paying customer of one of your apps, he'd be pretty upset that your app doesn't work, even if it's not the app's fault.

I will send him another exe that shows GetLastError too for further investigation, but he's away now until the 7th so it'll be a while. Rest assured though, that I'm NOT making this up. I have no reason too and I'm not trying to cause trouble, I'm just reporting the truth.

[SFSxOI]

are you compiling it as ascii or unicode? Personally, i've used it for years and its never failed for me.

OK, try this one:

Code: Select all

Procedure.s GetDriveSerial(Drive.s)
  Protected lpVolumeNameBuffer.s, lpVolumeSerialNumber.l
  If Len(Drive) = 1 : Drive + ":\" : EndIf
  If Right(Drive, 1) <> "\" : Drive + "\" : EndIf
  lpVolumeNameBuffer.s = Space(#MAX_PATH +1)
  
  Lib = OpenLibrary(#PB_Any, "kernel32.dll")
  
  If Lib
    *Mem_Func = GetFunction(Lib, "GetVolumeInformationA") 
    If *Mem_Func 
    CallFunctionFast(*Mem_Func, @Drive, @lpVolumeNameBuffer, #MAX_PATH +1, @lpVolumeSerialNumber, 0,0,0,0) 
    EndIf 
    CloseLibrary(Lib) 
  EndIf
  ProcedureReturn Hex(PeekW(@lpVolumeSerialNumber + 2) & $FFFF) + "-" + Hex(PeekW(@lpVolumeSerialNumber) & $FFFF)
EndProcedure

Debug GetDriveSerial("C:")

and in the code from ts-soft, compile it as ansi and give it a try also. I can simulate you problem without crashing the code in the code I posted above by placing a space in the 'GetFunction(Lib, "GetVolumeInformationA")' between the 'A' in 'GetVolumeInformationA' and the last quote so it looks like this:

Code: Select all

GetFunction(Lib, "GetVolumeInformationA ") ; Note the space.

and the return is then 0-0 with the space, removing the space gives a serial number.

[cas]

Ahhhhhh...is the drive formatted? You can install the OS on an unformatted drive and some manufacturers do that.

Every drive must be formatted before use either with quick format or full format.
I believe you meant that they do quick format which only erases file allocation table. But even after that new drive serial is generated and written to disk...

Yes, if drive is formatted with FAT32 or is compressed then GetLastError_() should help...

[SFSxOI]

Ahhhhhh...is the drive formatted? You can install the OS on an unformatted drive and some manufacturers do that.

Every drive must be formatted before use either with quick format or full format.
I believe you meant that they do quick format which only erases file allocation table. But even after that new drive serial is generated and written to disk...

Yes, if drive is formatted with FAT32 or is compressed then GetLastError_() should help...

Yes, thats what I meant. I changed my post and removed that. But actually you don't need to format a drive at all to use it, i do it all the time at work for testing.

[UserOfPure]

OK, try this one

I just noticed, with your new code above, that if I run it as Unicode, then I too get 0-0 as the result! If I then make it non-Unicode, it correctly returns the serial for my C drive. So, maybe something is set to Unicode on his PC? Is that even possible? Or maybe my PureBasic was set to Unicode when I compiled it for him the first time without realising. I think this must be part of the problem, because I can now reproduce it locally if I change the type.

[SFSxOI]

GetVolumeInformationA < is the ansi version
GetVolumeInformationW < is the unicode version

Yes, also if you compile the above as unicode it will return 0-0, i was waiting for you to say that.

Its possible that you were set to unicode when you compiled for him. Try an ansi version and see if that works.

[ts-soft]

The posted code by me works in unicode and ascii without any priviliges.
I see no problem with 0 as result. The serial is only set from the OS when formating.
Some OEMs formating without windows or Imaging the Computer, so 0 is the serial
The Serial of my mainboard is 0.

The serial is not designed for protection or anything, so why is this a problem.
The serial is absolute useless, the code is useless but correct!

[SFSxOI]

I agree ts-soft, just trying to rule out the small stuff. Its true that not every drive will return a serial. And besides this is the volume serial anyway and the very last thing you would want to base any sort of protection on.

[ts-soft]

With the physical serial number you have the same problem, that is not always included in the firmware. Often is only on the case

[SFSxOI]

True, but for the hardware serial you have to resort to other methods. I use WMI to get the hardware serial myself.

Anyway, time for another beer haven't had a long four day weekend in a longggg time like this so i'm setting back and relaxing and enjoying some beer a friend brewed for me in his basement brewery set up. I don't get it that often, he only does his special stuff around the holidays and he gave me two cases of the stuff this year and its the best i've ever had. He'd make a fortune if he ever went commercial with it as it would put most of the stuff on the market now to shame.

[Rescator]

Why not simply read HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductID ?

[SFSxOI]

Why not simply read HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductID ?

Why would you want to base a software protection upon something that can probably be read by anyone wanting to crack your software (if its based upon something like that)?

[Rescator]

*shrug* I assumed the OP just wanted to tie it to the machine, the OS (and thus it's key) is less likely to change than any underlying hardware.
If properly done the app should also have a deactivation tool in situations where the user wish to "move" to a different OS or machine.

When it comes to any DRM the best way to implement it is to think "If I where a user, would I like it to behave this or that way?"
I would never use an annoying software, and I'd hate to make annoying software as well
Obviously as a developer it's very hard to "think as the end user" but I still advice you should try.

Tying it to the HD is bad in any case, and you can't guarantee to be able to get the info on all systems.
Just look at all the BIOS serial attempts out there. (several posts in the forum about that as well)

Keep it simple enough that it works and isn't annoying but able to prevent casual "borrowing" using the same app serial.
You'll never stop anyone from cracking an app, nor should you waste the time trying.
If DRM is so vital to ensure that every copy used is a sale then you already have sales issues without taking DRM and cracking into count,
focusing on improving sales is more vital in that case.

DRM is basically a balance game. How many % of users are you willing to loose to prevent a % of pirate copies.
Is it worth loosing 10% of users to prevent 10% piracy? Maybe you'll convert 2% pirates, but you've lost 8% users in the process.
I'm just picking numbers out of the air here, but so does the "industry" lawyers and PR folks out there

I believe Windows does provide a machine ID of sorts that you can either find in the registry or query some way.
Then again, if it's a semi online app you could always create a client login system but you'd need a server then.