57 replies to this topic

[Wonko the Sane]

nice

Yep, but anyway "overcautious".
You see, for VOL use the way the batch loops, the "FIND" is only used to reduce the number of CALLs as, in *any* language the line that contains the serial is always the last one, and this (though looping more) would work as well:

@ECHO OFF
SETLOCAL ENABLEEXTENSIONS
IF %1.==. ECHO Missing drive letter&GOTO :EOF
FOR /F "tokens=* delims=" %%? IN ('VOL %1') DO CALL :do_serial %%?
ECHO Serial is: %Serial%
GOTO :EOF

:do_serial
IF %2.==. SET Serial=%1&GOTO :EOF
SHIFT
GOTO :do_serial
GOTO :EOF

all in all it just ECHOes the last token of last line. (but it won't apply well to FORMAT output .
This would work as well (still for VOL use only):

@ECHO OFF
SETLOCAL ENABLEEXTENSIONS
IF %1.==. ECHO Missing drive letter&GOTO :EOF
FOR /F "tokens=*" %%? IN ('VOL %1') DO SET Serial=%%?
ECHO Serial is: %Serial:~-9%

Wonko

[steve6375]

Just to complete this thread, I had trouble getting the Volume Label too!

wmic doesn't work on an ImDisk drive. VOL is language specific and there is no clear 'marker'

For instance if the label has spaces in it e.g.  'My VOL', then it is not easy to programatically get the volume label just using Windows and cmd scripts.

 

So I used a small Nirsoft utility called DriveLetterView - here are my scripts:

 

e.g. call :getvolim U:  for an imdisk volume, or

call :getvol E: for a disk volume

:getvolim
:: this should work for any language and if label has spaces! Only for Imdisk volumes
.\utils\DriveLetterView.exe /scomma myvol.log
for /F "usebackq delims=, tokens=7" %%A in (`find /i "%1\," myvol.log`) do set MYVOL=%%A
goto :EOF

:getvol
:: this should work for any language and even if label has spaces!
.\utils\DriveLetterView.exe /scomma myvol.log
for /F "usebackq delims=, tokens=10" %%A in (`find /i "%1\," myvol.log`) do set MYVOL=%%A
goto :EOF

[Wonko the Sane]

As I said above, the VOL needs NO marker to get the serial because the serial is last token of last line.
 
About the "label", you can use the already mentioned:

fsutil fsinfo volumeinfo <volume>

as there is a separator (language independent), which is the ":" colon (which is a non-valid character in a Volume name), and since the label is FIRST line of output, you can have something *like*:

@ECHO OFF
FOR /F "tokens=2 delims=:" %%? IN ('fsutil fsinfo volumeinfo %1') DO ECHO %%?&GOTO:EOF

KISS principle
 

Wonko

[steve6375]

Hi Wonko

fsutil does indeed work on FAT32 ImDisk volumes 

 

re. using the VOL command - what if the Volume label consists of two or three words? Taking the last word would not work which is why I couldn't use it.

 

I will switch to fsutil  (for some reason I thought it only worked on NTFS drives??) - it looks useful for getting the filesystem type too... (NTFS or FAT32)

[Wonko the Sane]

Just for the record FSUTIL works also on CDFS (or .iso's mounted through IMDISK)

 

This should be (hopefully) a *complete* batch:
 

@ECHO OFF
SETLOCAL ENABLEEXTENSIONs ENABLEDELAYEDEXPANSION
IF %1.==. ECHO Missing drive letter&GOTO :EOF
IF NOT EXIST secinspect.exe ECHO Missing secinspect.exe&GOTO :EOF
SET /A Counter=0
FOR /F "tokens=2 delims=:" %%? IN ('fsutil fsinfo volumeinfo %1') DO (
CALL :check_param %%?
IF !Counter!.==4. GOTO :out_of_for
)
:out_of_for
IF %Line4%.==NTFS. (
FOR /F "tokens=10,11,12,13,14,15,16,17 delims=- " %%A IN ('secinspect -dsec \\.\%1 0 1 ^| FIND "0x0040"') DO (
FOR %%? IN (%%H %%G %%F %%E %%D %%C %%B %%A) DO CALL :do_hex 0x%%?
)
) ELSE (
FOR %%? IN (%Line2:~2,2% %Line2:~4,2% %Line2:~6,2% %Line2:~8,2%) DO CALL :do_hex 0x%%?
)
ECHO Filesystem is %Line4%
ECHO Label is %Line1%
ECHO Serial is %Serial:~-8,4%-%Serial:~-4,4%
ECHO UUID is %Serial%

GOTO :EOF

:check_param
SET /A COunter+=1
SET Line%Counter%=%*
GOTO :EOF

:do_hex
SET /A dec=%1
CMD /C EXIT /B %dec%
SET "Serial=%Serial%%=ExitCode:~-2%"
GOTO :EOF

Yes, getting the label through the VOL or LABEL command would become complex, one could (if there is more than one volume available) compare the output of the commands issued against the two volumes and strip the "same part", but as an example the two volumes used have as label respectively "My label" and "My label2" the "My" would be considered part of the "localized" output of the VOL command.

Maybe there is some of the "queer" tricks that can be used, I'll have a look if I can find something.

 

 

Wonko

[Wonko the Sane]

BTW:

wmic doesn't work on an ImDisk drive.

It works here . 

C:\batches\Vol>wmic logicaldisk get name,volumeserialnumber,volumename
Name  VolumeName       VolumeSerialNumber
C:                     C08CCFD9
D:    Dati             F89757AC
E:
F:
G:
H:
I:
J:
K:    HITMA NPR        2715A7A9
L:    CRMSEVL_EN       82B5A121
M:    My test ramdisk  A4064CF3
 

L: is a .iso and M: is a Ramdisk, both IMDISK drives.


Wonko

[steve6375]

Doh! I tried VOLUME not LOGICALDISK

 

The serial number from this is the short one so that's no good, but the wmic works for volume label - e.g.

for /F "tokens=*" %A in ('wmic logicaldisk where "name='I:'" get volumename /value ^| FIND "="') do set VNAME.%A

sets the variable  VNAME.VolumeName  to the volume label

 

I prefer to avoid wmic however as I have seen weird problems when using it (mainly with vbs scripts).

 

cheers

Steve

[Wonko the Sane]

Sure, let's tag this as "news"
 

WMI (at least on XP) returns also the "short" serial only:

wmic logicaldisk get name,volumeserialnumber

This:

for /F "tokens=*" %A in ('wmic logicaldisk where "name='I:'" get volumename /value ^| FIND "="') do set VNAME.%A

can be "simplified" (JFYI) in:

@ECHO OFF
SETLOCAL ENABLEEXTENSIONS
FOR /F "tokens=2" %%? IN ('wmic logicaldisk get name^, volumename ^| FIND "%1"') DO ECHO %%?

Wonko

[Vortex]

Hi Steve,

 

I coded a small console application to get the volume serial number. Using the tool :

GetVolSerialNumb.exe U:\

4454-DE64

The application uses the GetVolumeInformation API to read hard disk information.

 

U: is an Imdisk RAM drive. You need to specify the terminating slash symbol \

Attached Files

•  GetVolSerialNumb.zip   1.79KB   397 downloads

[steve6375]

Hi

I thank you for doing this and it works for FAT32 volumes, but I am afraid that on NTFS volumes it only returns the short serial number.

I need the long one so that it is the same as used by grub4dos and linux.

[Vortex]

Hi Steve,

 

OK, Let me check the long number issue. By the way, could you try the GetVolName tool to read the volume label?

GetVolName.exe U:\
testvolume

Attached Files

•  GetVolName.zip   1.65KB   372 downloads

[Vortex]

Hi Steve,

 

The blkid tool from the Cygwin package does the job but it does not display the information of Imdisk partitions :

blkid.exe

/dev/sda1: UUID="F0FA68E3FA68A814" TYPE="ntfs"

/dev/sda2: UUID="7A18B3EA18B3A413" TYPE="ntfs"

Or simply :

blkid.exe /dev/sda1

/dev/sda1: UUID="F0FA68E3FA68A814" TYPE="ntfs"

The dependencies of blkid.exe :

cygblkid-1.dll

cyggcc_s-1.dll

cyguuid-1.dll

cygwin1.dll

[steve6375]

Thanks, but I know the drive letter, I don't know the /dev/xxx designation.

 

I am using Wonko's secinspect script at the moment and it is small, so I think that is the best solution, so far

[Vortex]

Hi Steve,

 

Here is ReadVolUUID Version 1.0 This tool reads the complete UUID values :

ReadVolUUID.exe C:

F0FA68E3FA68A814

ReadVolUUID.exe C

F0FA68E3FA68A814

Attached Files

•  ReadVolUUID-V1.zip   4.47KB   443 downloads

[Wonko the Sane]

Small correction, the snippet in post #33 w't work for labels with spaces, this should:

@ECHO OFF
SETLOCAL ENABLEEXTENSIONS
FOR /F "tokens=1,*" %%A IN ('wmic logicaldisk get name^, volumename ^| FIND "%1"') DO ECHO %%B

but as Steve6375 pointed out, particularly in the case of some connected to RMPREPUSB, i.e . to something "portable" if we can avoid using WMI is better.
 
@Vortex
The theory of operation of a program to provide the serial (or - better - the GRUB/grub4dos UUID) should be similar to the way I use secinspect.exe in the batch, just plainly and directly access the first sector of the volume (and the "volume" exists also if it is an IMDISK device, i.e. *anything* that can be accessed through a drive letter), then parse it's contents.
Since hexdump.exe:
http://www.fileforma...o/tool/hexdump/
 is 6656 bytes and dsfo (part of the dsfok toolkit):
http://members.ozema...ware/index.html
is 6637 bytes (but the issue here is that both cannot use pipes) it should be entirely possible to create a suitable program with no dependencies in 12000 bytes or less.
 
Another option could be the od.exe in UNXutils:
http://sourceforge.n...jects/unxutils/
but it is a tadbit larger than the Secinspect tool.
 
Ideally someone with the "right" kind of knowledge could/should find a way to actually compile/recompile the Unxutils, taking the "relevant bits" from it's od.exe, compare with this:
http://reboot.pro/to...uest-for-ddexe/
 

Wonko
 
OOPS completely missed your new post with ReadVolUUID, nice! 

[Vortex]

Hi Wonko,

 

No problem and thanks for the links.

 

New beta2 uploaded at the top.

[Wonko the Sane]

Very good.

Slightly OFF-TOPIC, but if anyone is interested in the matter, questions  and problems . (being typical of my picky nature ), but this is something that was never AFAIK "finalized".

 

What happens (in a Windows NT) when either CDFS or UDF are encountered?

 

See:

http://www.osronline...cfm?link=134085

http://reboot.pro/to...-number-of-iso/

 

BTW the grub4dos uuid command does not support CDFS/UDF AFAIK.

 

Wonko

[Vortex]

Hi Wonko,

 

Testing a Scientific Linux 6.3 Live CD, the blkid command didn't report the UUID of the CD :

[root@livecd liveuser]# blkid

/dev/loop0: TYPE="squashfs"

/dev/loop2: TYPE="squashfs"

/dev/loop3: LABEL="_SL-63-i386-Live" UUID="d1c45be6-45e4-448e-8311-ecd724d0873a" TYPE="ext4"

/dev/loop4: TYPE="DM_snapshot_cow"

/dev/sda1: UUID="F0FA68E3FA68A814" TYPE="ntfs"

/dev/sda5: UUID="7A18B3EA18B3A413" TYPE="ntfs"

/dev/sda6: UUID="52A8C09AA8C07E4B" TYPE="ntfs"

/dev/sdb1: UUID="72BC7413BC73CFD9" TYPE="ntfs"

/dev/sdb2: UUID="E8C03612C035E808" TYPE="ntfs"

/dev/mapper/live-rw: LABEL="_SL-63-i386-Live" UUID="d1c45be6-45e4-448e-8311-ecd724d0873a" TYPE="ext4"

/dev/mapper/live-osimg-min: LABEL="_SL-63-i386-Live" UUID="d1c45be6-45e4-448e-8311-ecd724d0873a" TYPE="ext4"

[root@livecd liveuser]# blkid /dev/sr0

/dev/sr0: LABEL="SL-63-i386-LiveCD" TYPE="iso9660"

GetVolumeInformation can read the serial number of CDFS like the vol command.

[Wonko the Sane]

Hi Wonko,

 

Testing a Scientific Linux 6.3 Live CD, the blkid command didn't report the UUID of the CD :

....

GetVolumeInformation can read the serial number of CDFS like the vol command.

Yep .

The whole point is that Windows - unlike most other Operating Systems - calculates the serial number with a seemingly not documented method, as there is actually NO serial number on the actual CDFS (and most probably not one also in the UDF filesystem).

 

I was just hinting that it could be a good idea to:

1. find out HOW exactly this serial number is calculated (as seen in the given link I found where the "base" is stored) by the VOL command
2. replicate the behaviour in your little, nice tool
3. backport the feature into grub4dos

 

Wonko

[Vortex]

Hi Wonko,

 

New upload at the top. Now,  ReadVolUUID reads the serial number of CDs using the GetVolumeInformation API. The number is the same as reported by the vol command.

[Wonko the Sane]

Hi Wonko,

 

New upload at the top. Now,  ReadVolUUID reads the serial number of CDs using the GetVolumeInformation API. The number is the same as reported by the vol command.

Very good .

Still, we miss how (the heck) this number is calculated (I simply hate to "have to" use an API for this).

 

Wonko

[erwan.l]

Well, at least if we knew the windows API that sets the serial number, we could then disassemble it but we miss that information as well right?

 

It is probably a mix of a randomise function with a seed based on time.

 

Erwan

[Wonko the Sane]

Well, at least if we knew the windows API that sets the serial number, we could then disassemble it but we miss that information as well right?

 

It is probably a mix of a randomise function with a seed based on time.

 

Erwan

I don't think (see the already given links):

http://reboot.pro/to...-number-of-iso/

http://www.osronline...cfm?link=134085

that the "creation" of the Primary and secondary volume is the actual point (even because this is something that is done also -say - on a "created with mkisofs or genisoimage under Linux" .iso)

The point is only how exactly the Windows API (or whatever) uses the existing data on a CD to calculate the "serial" VOL and DIR.

Can you verify that this:

 

Not much goes on for ISO-9660/Joliet and CD audio serial generation so I imagine
UDF is very similar. For ISO-9660 all the explanation would have to be is
something like this:

1) Go to PVD (sessionstart sector + 16) for the most recent session and read
the 2048 bytes of user data.
2) Run the bytes through the following algorithm:
{
union {
UCHAR Bytes[4];
unsigned long SerialId;
} Checksum;

Checksum.SerialId = 0;

while (ByteCount--)
Checksum.Bytes[ByteCount & 0x3] += *(Buffer++);
}

 

is actually accurate?

 

BTW:

1) Welcome back from your trip

2) There is work for you : 

http://reboot.pro/to...disk-from-ewf/ 

http://reboot.pro/to...m-ewf/?p=183495

 

Wonko

[erwan.l]

Hey Wonko

 

Indeed, back from Rome.

This is an incredible city : you just dont know where to look !

There are beautiful things to look at everywhere (and I am not talking about girls ).

 

By the way, I went and visit the gardens of Santa Sabina in the Aventino and this is indeed a lovely place.

Not to mention that this is barely mentionned in touristic flyers which makes it even more special.

 

About a command line version of ImgMount : very easy, I'll add that to my to do list !

I have also the offline registry .reg file parser/import next on my list.

And the new wimboot windows 8.1 update 1 is also keeping me busy.

 

Back to the topic : the seralid would then be a checksum of block of byte (all or part of the 512 boot sector for NTFS?).

[Wonko the Sane]

By the way, I went and visit the gardens of Santa Sabina in the Aventino and this is indeed a lovely place.
Not to mention that this is barely mentionned in touristic flyers which makes it even more special.

Yep , that is why I suggested it to you, touristic fliers are made for tourists, not for travelers .

 

Back to the topic : the seralid would then be a checksum of block of byte (all or part of the 512 boot sector for NTFS?).

Naah, the issue is ONLY for CDFS (and for UDF ), FAT, FAT32 and NTFS all "sport" a serial in the bootsector that can be read "as is", and that is already nicely solved by Vortex's nice little app (and/or via batch), and CDFS sector is 2048 bytes, as mentioned.

Just for the record, the generation of the serial for FAT/FAT32/NTFS is made like you hinted (time seed), BUT the algorithm is known for DOS (for FAT/FAT32), BUT NOT for NT based systems and/or NTFS, see what may happen in a Swiss Watch Company :

http://www.msfn.org/...mages/?p=987748

and here is the "full" discussion:

http://www.forensicf...ewtopic/t=2134/

http://www.msfn.org/...e-4#entry980297

 

 

 

BTW, @Vortex :

ExFAT (and TexFAT):

http://shullich.blog...009/12/vbr.html

 

Question:

Does it make sense to add generation of Serial for Ext2/3/4?

 

Wonko