The "old" DOS way was as follows:
www.tomshardware.co.uk...ial-number

A VSN is generated by Format.COM and DiskCopy.Com from Dos date and Dos time.
It is a double word (4 bytes) value stored in reverse notation on disk.
The VSN is stored at offset 0027h (FAT12 and FAT16) or 0043h (FAT32) in the bootsector.

The routines used to generate a VSN stayed the same from Dos 5.0 - Dos 7.1

Routines in Format.Com and DiskCopy differ slightly.
Compared with Format.COM the High and Low word have changed place
Format: [Seconds/Hundredth] + [Month/Day of mo] = High word of VSN
[Hour/Minutes] + [Year] = Low word of VSN

DiskCopy: [Seconds/Hundredth] + [Month/Day of mo] = Low word of VSN
[Hour/Minutes] + [Year] = High word of VSN

Cannot say if the NT/2K/XP/2003 use different algorithms.

jaclaz  

NTFS stored VSN at offset 0048H (8 BYTE) on the PARTITION TABLE.

NO, it is stored in the bootrecord, NOT in the partition table.

I was hinting that the method used by NT systems on FAT (FAT16 and FAT32) used maybe the same algorithm than the old DOS one.

NTFS uses 4 more bytes, but the first four should be the SAME ones as for FAT16/32:

The VOL command only shows the first 4 bytes (48h-4Bb) of the VSN (reversed from how you�d see them via Disk Probe). And VolumeID only writes the first 4 bytes of an NTFS VSN.

www.computing.net/wind...77308.html

See also this:
mirror.href.com/thesta...NTFSBR.htm

Given for true that 2 of the supplemental four bytes are always the same as the middle ones of first four, only two bytes remain as a "mistery", but the date part should be all in the first four ones, which was the original question.

Just a wild guess on my part, of course, but this could reflect the same difference you have in time stamps between FAT16/32 and NTFS, with NTFS wanting to be more accurate

jaclaz  

I attentively read the article by Craig Wilson:
www.digital-detective....umbers.pdf

The Authors explicitly says that there is NO way to decode the volume serial number into the actual date/time when the formatting was performed, which makes perfectly sense, since the real scope of the algorithm is to generate a pseudo-random number unlikely to be a duplicate of another volume, but since I am a bit "tough" I put together a small spreadsheet to verify the algorithm.

The GOOD news is that hour can be calculated UNEQUIVOCALLY, at least in a "reasonable" range of years (verified for 1991÷2010).

The BAD one is that for the rest the Author is correct, and the result is "a suffusion of yellow":
www.thateden.co.uk/dirk/

The only useful thing you can get from it is a "negative affirmation":
If anyone swears he was never in the office between 21 and 24, and the serial shows that the volume was formatted at 22, he is lying (or the volume was formatted by someone else).

But I am still not so sure about something wrong in the algorithm (a missing factor ?) or in my implementation of it, as while most of test serials verify, a few do not, provoking negative numbers.

For some particular values the amount of possible results is decreased, but it still remains very large.

Definitely NT/2K/XP use a different volume serial number generating algorithm, so we are anyway back to square #1.

If anyone needs/want to check/try my little spreadsheet, PM me, we'll find a way to send or upload it somewhere.

jaclaz  

Just for the record I hopefully finished the (DOS) Volume Serial checking spreadsheet.

I have posted it here:
www.msfn.org/board/top.../?p=980297

jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. -