There are some cases when software is bounded to HDD model and S/N. When HDD becomes broken, it gives a lot of pain to reconfigure all system. In such case there is option to make full duplicate of old HDD. It needs special software and/or hardware to rewrite serial number and model in HDD, but it is possible. And it can save a lot of time and/or money.
fnet clone drive serial number
Long answer: Every manufacturer has its own naming scheme for serial numbers, and they are not guaranteed to be globally unique across manufacturers, but they should be unique per manufacturer as, after all, they want to be able to identify a specific unit.
Since everyone has their own schema, collisions are really unlikely in practice, but the combination of model and serial number should be unique (as long as no ones messes things up during production).
I recently made some code that identified the computers using our software by drive serial number. Out of about 11 stores that I gave the new code to, 3 of them had hard drives with duplicate serial numbers. It appears that hard drive serial numbers are not very consistently unique. Apparently, I'm going to have to find another means of uniquely identifying what computer is being used.
Amazing as it sounds, I recently purchased a batch of ASUS Notebooks - every one had the same hard disk serial number (which I use to secure my software)Consequently, no security any more (based on disk serial number)
First, this is what I mean about serial numbers. Suppose you're using a Windows system, have a floppy disk at drive A:/ and a regular USB flash drive at E:/, and you run these commands in the command prompt:C:\>vol E:Volume in drive E is CRUZERVolume Serial Number is 955C-59BFC:\>vol A:Volume in drive A has no label.Volume Serial Number is EC2B-36AFThese serial numbers are assigned when the drive is formatted; reformatting a floppy disk or flash drive will give it a different serial number.According to The Wikipedia, the serial number (ID) is kept in two different places on the partition depending on the version of FAT being used.In FAT12 and FAT16 (used with floppy disks), the ID begins at byte offset 0x27 (39 in decimal); in FAT32 (used with flash drives and external hard drives), the ID begins at 0x43 (67 in decimal).So, with the handy dd utility that comes standard on pretty much any Unix-like system, you can extract this information and display it. Here are a couple of one-liners you can run in a Unix terminal. I'll explain how they work afterward.# For FAT32 filesystems (modern flash drives)dd if=/dev/sdb1 skip=67 bs=1 count=4 hexdump -v -e '1/1 "%02X" " "' xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'# For FAT12/16 filesystems (old floppy drives)dd if=testfloppy.img skip=39 bs=1 count=4 hexdump -v -e '1/1 "%02X" " "' xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'I underlined the input file (if) and byte offset (skip) in both of these commands. In the first one, I ran the command on a real, physical, flash drive, that had a device node at /dev/sdb1 for its one and only partition. In the second one, I ran it on a floppy disk image file (who has a computer with a real floppy drive these days?)If you're going to be using a physical device like in my first command, you need to run the command with root privileges (regular users can't read directly from the device node). My second example (using an image file) can be run as a regular user, however.These commands printed in the terminal for me:(for the flash drive)4+0 records in4+0 records out4 bytes (4 B) copied, 3.3445e-05 s, 120 kB/sSerial Number: 955C-59BF(for the floppy image)4+0 records in4+0 records out4 bytes (4 B) copied, 3.1551e-05 s, 127 kB/sSerial Number: EC2B-36AFAnd now, how the commands work. I'll use the flash drive command as the example. In this one-liner, three commands are being executed at once:dd if=/dev/sdb1 skip=67 bs=1 count=4hexdump -v -e '1/1 "%02X" " "'xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'The dd command gets the operating system to read raw data from the flash drive at /dev/sdb1, skipping the first 67 bytes, reading only 1 byte at a time, and reading a total of 4 bytes. This gets the 4 byte serial number; now we need to display it in hexadecimal like Windows and DOS.The hexdump command takes the 4 binary bytes and displays them in hexadecimal. On my flash drive, it looks like this: BF 59 5C 95. Note that the hex codes are out of order; Windows shows them as 955C-59BF - basically, the reverse of what hexdump shows. Hexdump is showing the correct order; Windows and DOS reverse them when they show you the serial number.So, we run it through xargs (which turns the four hex numbers into four separate parameters) and sends them to a quick Perl script, which prints out "Serial Number:" and puts the hex codes in the correct order, to give the same result as Windows and DOS.One could use this information to make a vol command for Unix. If the command checks other places in the filesystem headers to determine the version of FAT, it could automatically use the correct byte offset and get the serial number from both floppy disks and flash drives. Tags: Linux Windows DOS Comments There are 15 comments on this page.Add yours.
I follow your step, but on Macintosh HD my serial number is 0000-0000 and on DVDs\CDs it response: "Resource busy". If I search this SN with Windows on Mac HD or optical support I read my real SN why?
I have a usb pen drive. I am developing an application which stores the serial number of the pen drive, so that it can check it the next time the pen drive is plugged in. Please provide me with all the steps required to find the serial number on a linux system.Thanks !
I got a question. I heard, and have seen it done, that some license company that put licenses on usb sticks, use the serial number or UUID, and you then can't just clone the usb drive to get a second license. so, I know this was a Russian hack, does anyone know how to do this. clone a usb stick with a license, so you can have 2 licenses...I know its been done before. please send me a link with the crack.
If they are using the serial numbers as described on this blog post it should be trivially easy to clone the USB drive: these serial numbers are encoded as part of the partition headers on the filesystem. When you (re)format a drive as FAT it rolls new numbers for the serial number but you could clone the whole disk including the serial easily from a Linux terminal like:
Or, without needing to copy disk images or reformat an existing FAT partition on the new USB stick, you could just hex edit the serial number in. See the original blog post for the filesystem offsets where the serial is kept for FAT16 and FAT32, you could copy the serial from the original disk and paste that same value into the same offset on the target disk.
Note: this is all assuming the software is using the FAT serial number for its DRM; it could be checking a lower level, hardware serial number which is a whole other kind of creature. The hardware serial may be difficult to modify on a regular USB stick, but - with an Arduino teensy USB development board or similar, you can program the USB device yourself to present itself as anything you want. For example a device like this could be programmed to present to your computer as being a USB hub with a USB keyboard+mouse attached plus a USB flash drive attached, or any other such shenanigans. So by programming it to present as a USB flash drive it could tell the computer anything it wants regarding its hardware serial number and can pretend to be the original flash drive which may be enough to defeat such licensing issues. I don't have any direct personal experience in that domain, however!
In the diagram below, a command in Powershell lists some values regarding the above two USB devices. Clearly, what we have been calling the serial number does not conflate with what the identification in Powershell calls a serial number.
I tried the setup on a different computer we will call Computer 2. As if by magic, GSmartControl now showed me all of the correct information including serial number. Well now I have even bigger problems. Why would it work properly on Computer 2 but not Computer 1? What does the computer have to do with it?
Sadly, Windows agreed with v1.1.3, which was the wrong Serial Number. In fact, there was no indication or marking anywhere on or inside the drive that would support any of the numbers reported by Windows or v1.1.3.
Sorry for a bit of a newbie question. I have a system with three identical SSD's (ie same model name, size, etc). I am backing up the disks using Clonezilla but wish to uniquely identify them. When they show up in Clonezilla, I see the three disks with unique names, and there seems to be a kind of a serial number identifier in Clonezilla at the end of the line when selecting the source disk.
This image is from a Clonezilla device-device tutorial where it gets to the step of choosing the SOURCE disk. What are those numbers that appear on the right. Will be something concrete that I can reference? ie; Are those serial numbers on the right in that image?
There are other virtual console (VC) you can use. Clonezila job is started in VC 1, and you can press "Ctrl-Alt-F2" to enter VC 2, run the command to check which device is source, and which is destination. Then press "Ctrl-Alt-F1" to VC 1."What are those numbers that appear on the right. " -> As shown here: -live/doc/03_Disk_to_disk_clone/images/ocs-07-source-disk.png 2ff7e9595c