AutoSketch

Posted on by Thor 1 Comment

There was a lot of CAD programs in the 1980’s through the 1990’s. Some titles might be TurboCAD, DesignCAD, Generic CADD, KeyCAD, SwiftCAD, CADKEY, VersaCAD, MiniCAD, EasyCAD, and of course AutoCAD. Also, many file formats. Some had chosen the common DXF exchange format, but most chose their own way to do things.

AutoCAD is software made by AutoDesk, but is one of many software tools made by them. AutoCAD has its own native file format, DWG, as is well documented, but there was a little brother to AutoCAD marketed for a few years and it also had its own format(s).

AutoSketch was a less powerful version of AutoCAD and only supported 2D models, but still found a good following of users. Unlike its big brother, the AutoSketch native format(s) don’t have much documentation and are not supported in any AutoDesk product today. The PRONOM entry for the SKF (fmt/306) is missing a signature, it is an outline entry only. In addition, SKF, AutoSketch had an earlier format that needs to be documented and a signature created. Let’s take a look.

The first version of AutoSketch came out in 1986 for DOS and files stored in RAM which could be written out as a SKD file. Looking at a saved file, we see a very easy to identify file. 

% hexdump -C TEMPLATE.SKD | head
00000000  41 75 74 6f 53 6b 65 74  63 68 20 64 72 61 77 69  |AutoSketch drawi|
00000010  6e 67 20 64 61 74 61 62  61 73 65 0d 0a 1a 00 00  |ng database.....|
00000020  49 03 00 44 00 00 00 01  00 00 00 00 00 00 00 00  |I..D............|
00000030  00 00 00 00 00 40 41 00  00 10 41 00 00 00 00 00  |.....@A...A.....|
00000040  00 00 00 00 00 40 41 00  00 10 41 00 00 00 3f 01  |.....@A...A...?.|
00000050  00 09 00 00 00 00 00 00  00 00 00 00 00 00 00 33  |...............3|
00000060  33 33 33 33 33 d3 3f 00  00 00 00 00 00 f0 3f 00  |33333??......??.|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 80 3f 00 00 80 3f 0a  00 08 00 00 00 00 00 ff  |..?...?........?|
00000090  ff 00 00 00 00 00 00 00  00 00 00 00 00 00 00 25  |?..............%|

Most formats don’t make it this easy. Having the ASCII string “AutoSketch drawing database” makes identification very easy. Lets see if this pattern stays true with the next version, version 2.0 for DOS.

% hexdump -C ENGINE.SKD | head
00000000  41 75 74 6f 53 6b 65 74  63 68 20 64 72 61 77 69  |AutoSketch drawi|
00000010  6e 67 20 64 61 74 61 62  61 73 65 0d 0a 1a 00 fd  |ng database....?|
00000020  49 06 00 12 04 00 00 01  00 00 00 64 20 88 40 f7  |I..........d .@?|
00000030  eb 38 c2 88 fe 1b 44 25  83 dd 43 00 00 00 00 00  |?8?.?.D%.?C.....|
00000040  00 00 00 00 80 1d 44 00  80 d9 43 00 00 00 41 01  |......D..?C...A.|
00000050  00 07 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 14 40 00  00 00 00 00 00 f0 3f 00  |......@......??.|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 40 41 00 00 40 41 0a  00 08 00 00 00 00 00 1f  |.@A..@A.........|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 1d  |................|

AutoDesk also released version 3.0 of AutoSketch in 1990.

Version 3.0 of AutoSketch produced files which appear very similar, but needs a closer look.

% hexdump -C ASSY.SKD | head
00000000  41 75 74 6f 53 6b 65 74  63 68 20 64 72 61 77 69  |AutoSketch drawi|
00000010  6e 67 20 64 61 74 61 62  61 73 65 0d 0a 1a 00 8b  |ng database.....|
00000020  49 09 00 db 00 00 00 01  00 00 00 00 00 00 00 00  |I..?............|
00000030  00 00 00 b7 cc a4 41 79  99 79 41 00 00 00 00 00  |...?̤Ay.yA.....|
00000040  00 00 00 00 00 04 42 00  00 90 41 00 00 00 3f 01  |......B...A...?.|
00000050  00 07 00 00 00 00 00 00  00 00 00 00 00 00 00 9a  |................|
00000060  99 99 99 99 99 c9 3f 00  00 00 00 00 00 f0 3f 00  |.....??......??.|
00000070  00 00 00 00 00 00 00 00  00 00 00 01 00 00 00 00  |................|
00000080  00 80 3f 00 00 80 3f 0a  00 08 00 00 00 00 00 ff  |..?...?........?|
00000090  00 00 00 00 00 00 00 00  00 33 33 33 33 33 f3 1e  |.........33333?.|
*
000001b0  00 00 00 00 00 f0 3f 01  00 01 00 00 00 00 00 00  |.....??.........|
000001c0  00 00 00 00 00 00 00 74  78 74 00 f5 eb 0e 05 08  |.......txt.??...|
000001d0  04 15 01 08 00 eb 02 62  c0 76 32 00 fe fe fe fe  |.....?.b?v2.????|
000001e0  fe fe fe fe fe fe fe fe  fe 55 55 55 55 55 55 55  |?????????UUUUUUU|
000001f0  55 57 77 55 55 55 55 55  55 55 55 55 55 55 55 55  |UWwUUUUUUUUUUUUU|
00000200  55 55 55 55 55 55 35 55  53 33 55 00 00 00 00 00  |UUUUUU5US3U.....|
00000210  00 50 00 00 00 07 77 77  77 77 77 77 77 77 77 00  |.P....wwwwwwwww.|

Turns out AutoDesk made a change to the SKD format and you can see the version number at 473rd byte (0x1D9). This version of SKD is required for later versions of AutoSketch to open and use the format. A special version of AutoSketch, 2.1fc, was released with limited features to allow users to open earlier versions of the SKD format and convert them to the second version of the format. The readme file for the 2.1fc version has this statement:

This limited release of AutoSketch has been provided for file conversion purposes only. All functionality other than opening and saving files has been removed from this release.

Please follow the steps below to perform a drawing file conversion for files created in AutoSketch Release 2.0 for Windows, or earlier. Once drawing files have been converted, you will be able to open them in AutoSketch Release 5.0 and later.

AutoDesk released the first version of AutoSketch for Windows in 1992. This first version for Windows used the new SKD format as well. Even though it was version 1.0 for Windows, the new version of the format is known as the v2.x format.

% hexdump -C AS1-S01.SKD
00000000  41 75 74 6f 53 6b 65 74  63 68 20 64 72 61 77 69  |AutoSketch drawi|
00000010  6e 67 20 64 61 74 61 62  61 73 65 0d 0a 1a 00 00  |ng database.....|
00000020  49 0b 00 00 00 00 00 01  00 00 00 00 00 00 00 00  |I...............|
00000030  00 00 00 00 00 40 41 00  00 10 41 00 00 00 00 00  |.....@A...A.....|
00000040  00 00 00 00 00 40 41 00  00 10 41 00 00 80 3f 01  |.....@A...A...?.|
00000050  00 07 00 00 00 00 00 00  00 00 00 00 00 00 00 33  |...............3|
00000060  33 33 33 33 33 d3 3f 00  00 00 00 00 00 f0 3f 00  |33333??......??.|
00000070  00 00 00 00 00 00 00 00  00 00 00 01 00 00 00 00  |................|
00000080  00 80 3f 00 00 80 3f 0a  00 08 00 00 00 00 00 ff  |..?...?........?|
00000090  ff 00 00 00 00 00 00 00  00 9a 99 99 99 99 99 1f  |?...............|
000000a0  40 cd cc cc cc cc cc 23  40 00 00 01 00 00 00 00  |@??????#@.......|
000000b0  00 00 00 00 00 f0 3f 00  00 00 00 00 00 f0 3f 00  |.....??......??.|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001d0  00 00 00 00 00 00 00 e8  9a 76 32 00 00 00 00 00  |.......?.v2.....|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

This is the format used through version 2.1 for Windows which was released in 1996. It was after this version AutoDesk made a major change to the software. In version 5, skipping 3 and 4, an entirely new drawing engine was used, changing the software and the file format. This new format is actually the format used by the software the new drawing engine came from, DrafixCAD. AutoDesk purchased the software company Softdesk Drafix and used the DrafixCAD software, originally developed by Foresight Resources Corp., for this new version of AutoSketch.

Let’s compare a couple of DrafixCAD files to an AutoSketch 5 and 6 file.

% hexdump -C DEMOPLAN.CAD | head
00000000  0a 75 00 00 00 0b 02 38  30 13 05 46 4c 4f 41 54  |.u.....80..FLOAT|
00000010  14 05 53 48 4f 52 54 0c  04 30 2e 38 30 0d 08 4f  |..SHORT..0.80..O|
00000020  63 74 20 31 39 38 39 0e  12 44 72 61 66 69 78 20  |ct 1989..Drafix |
00000030  57 69 6e 64 6f 77 73 20  43 41 44 0f 06 49 42 4d  |Windows CAD..IBM|
00000040  20 50 43 10 07 44 4f 53  20 33 2e 30 11 06 4d 53  | PC..DOS 3.0..MS|
00000050  20 32 2e 31 12 1e 31 39  38 39 20 46 6f 72 65 73  | 2.1..1989 Fores|
00000060  69 67 68 74 20 52 65 73  6f 75 72 63 65 73 20 43  |ight Resources C|
00000070  6f 72 70 2e 00 28 43 03  00 00 29 b6 01 00 00 01  |orp..(C...)?....|
00000080  07 00 02 01 00 04 01 00  05 01 00 06 01 00 07 00  |................|
00000090  00 80 3f 08 00 00 09 0d  00 0a 01 00 0c 04 00 11  |..?.............|

% hexdump -C DEMOPLAN.CAD | head
00000000  0a 7d 00 00 00 0b 03 32  30 30 13 06 44 4f 55 42  |.}.....200..DOUB|
00000010  4c 45 14 05 53 48 4f 52  54 0c 03 32 2e 30 0d 0f  |LE..SHORT..2.0..|
00000020  4a 61 6e 75 61 72 79 20  37 2c 20 31 39 39 32 0e  |January 7, 1992.|
00000030  12 44 72 61 66 69 78 20  57 69 6e 64 6f 77 73 20  |.Drafix Windows |
00000040  43 41 44 0f 06 49 42 4d  20 50 43 10 07 44 4f 53  |CAD..IBM PC..DOS|
00000050  20 33 2e 30 11 06 4d 53  20 32 2e 31 12 1e 31 39  | 3.0..MS 2.1..19|
00000060  38 39 20 46 6f 72 65 73  69 67 68 74 20 52 65 73  |89 Foresight Res|
00000070  6f 75 72 63 65 73 20 43  6f 72 70 2e 00 28 28 04  |ources Corp..((.|
00000080  00 00 29 80 02 00 00 04  01 00 05 01 00 07 00 00  |..).............|
00000090  00 00 00 00 00 40 08 01  00 0a 01 00 0c 04 00 11  |.....@..........|

% hexdump -C ASv5-s01.SKF | head
00000000  0a 00 00 00 00 0b 03 34  30 31 01 00 00 00 38 00  |.......401....8.|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

% hexdump -C ASv6-s01.SKF | head
00000000  0a 00 00 00 00 0b 03 34  30 32 03 36 2e 30 01 20  |.......402.6.0. |
00000010  0f 4f 63 74 6f 62 65 72  20 32 2c 20 31 39 39 38  |.October 2, 1998|
00000020  01 00 00 00 38 00 00 00  00 00 00 00 00 00 00 00  |....8...........|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

You can see the similar pattern in the first 8 bytes. Just the 2nd and 7th byte being different. The 8th byte is consistent with all SKF files, and the 9th and 10th bytes turn out to be in sequence depending on the version.

Looking at the next few versions of AutoSketch we see: 

% hexdump -C AS7-s01.SKF | head
00000000  0a 00 00 00 00 0b 03 34  31 32 03 37 2e 30 08 42  |.......412.7.0.B|
00000010  75 69 6c 64 20 35 34 10  4f 63 74 6f 62 65 72 20  |uild 54.October |
00000020  31 35 2c 20 31 39 39 39  01 00 00 00 38 00 00 00  |15, 1999....8...|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

% hexdump -C AutoSketch8-s01.SKF | head
00000000  0a 00 00 00 00 0b 03 34  31 32 03 39 2e 30 08 42  |.......412.9.0.B|
00000010  75 69 6c 64 20 38 38 0a  30 37 2f 30 38 2f 32 30  |uild 88.07/08/20|
00000020  30 34 01 00 00 00 38 00  00 00 00 00 00 00 00 00  |04....8.........|
00000030  00 40 00 00 00 00 00 00  1f 40 00 00 00 00 00 00  |.@.......@......|
00000040  00 00 00 00 00 00 00 00  00 40 00 00 00 00 00 00  |.........@......|
00000050  20 40 00 00 00 00 00 00  00 00 00 00 00 00 00 00  | @..............|
00000060  00 00 02 00 00 00 76 5e  00 00 42 4d 76 5e 00 00  |......v^..BMv^..|
00000070  00 00 00 00 76 00 00 00  28 00 00 00 00 01 00 00  |....v...(.......|
00000080  bc 00 00 00 01 00 04 00  00 00 00 00 00 5e 00 00  |?............^..|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

% hexdump -C AutoSketch9-s01.SKF | head
00000000  0a 00 00 00 00 0b 03 34  31 33 03 39 2e 30 08 42  |.......413.9.0.B|
00000010  75 69 6c 64 20 38 38 0a  30 37 2f 30 38 2f 32 30  |uild 88.07/08/20|
00000020  30 34 01 00 00 00 38 00  00 00 00 00 00 00 00 00  |04....8.........|
00000030  00 40 00 00 00 00 00 00  1f 40 00 00 00 00 00 00  |.@.......@......|
00000040  00 00 00 00 00 00 00 00  00 40 00 00 00 00 00 00  |.........@......|
00000050  20 40 00 00 00 00 00 00  00 00 00 00 00 00 00 00  | @..............|
00000060  00 00 02 00 00 00 76 5e  00 00 42 4d 76 5e 00 00  |......v^..BMv^..|
00000070  00 00 00 00 76 00 00 00  28 00 00 00 00 01 00 00  |....v...(.......|
00000080  bc 00 00 00 01 00 04 00  00 00 00 00 00 5e 00 00  |?............^..|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

% hexdump -C AS10-s01.SKF | head
00000000  0a 00 00 00 00 0b 03 34  31 33 04 31 30 2e 30 08  |.......413.10.0.|
00000010  42 75 69 6c 64 20 31 31  0a 31 32 2f 30 32 2f 32  |Build 11.12/02/2|
00000020  30 30 38 01 00 00 00 38  00 00 00 00 00 00 00 00  |008....8........|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 25 91 48 24 12  89 30 40 5d 2c 16 8b c5  |...%.H$..0@],..?|
00000050  62 27 40 00 00 00 00 00  00 00 00 00 00 00 00 86  |b'@.............|
00000060  01 36 00 02 00 00 00 76  5e 00 00 42 4d 76 5e 00  |.6.....v^..BMv^.|
00000070  00 00 00 00 00 76 00 00  00 28 00 00 00 00 01 00  |.....v...(......|
00000080  00 bc 00 00 00 01 00 04  00 00 00 00 00 00 5e 00  |.?............^.|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Version 10 was the final version released of AutoSketch in 2008. It appears the SKF files from version 7 & 8 share the same format and 9 & 10 share one as well. This seems to be confirmed in the save as dialog in version 9 which lumps version 7 & 8 together.

So, if we wanted to make one signature for all SKF files, it might look something like:

0A000000000B0334(30|31)(31|32|33)

Or we can choose to split out versions if needed. For now, adding this signature to the existing PRONOM entry for SKF would be helpful. As for the earlier SKD format, we clearly need two signatures, one for the first version and one for the second.

Here is a small timeline of the different versions of AutoSketch.

AutoSketch Release 1.0 DOS 1986-10
AutoSketch Release 1.01 DOS 1987-02
AutoSketch Release 1.02 DOS 1987-09
AutoSketch Release 1.03 DOS 1988-02
AutoSketch Release 2.0 DOS 1989
AutoSketch Release 3.0 DOS 1990
AutoSketch Release 3.1 DOS 1991
AutoSketch Release 1.0 Windows 1992
AutoSketch Release 2.0 Windows 1994
AutoSketch Release 2.1 Windows 1996
AutoSketch Release 5 Windows 1997-11
AutoSketch Release 6 Windows 1998-10
AutoSketch Release 7 Windows 1999
AutoSketch Release 8 Windows 2001
AutoSketch Release 9 Windows 2004-09-20
AutoSketch Release 10 Windows 2008-11

I need to do a little more research on the DrafixCAD format, but I will update the signature when I do. As always take a look at my samples and suggested signatures on my GitHub page.

Microstation

Posted on by Thor Leave a comment

I recently was able to image a few Bernoulli Disks for a collection using a SCSI device I have found quite useful. The disks had been sitting around for quite some time waiting for the right tools and resources to extract the contents. I mentioned the accomplishment to a few coworkers and one asked me if I would extract the contents from their old disk they used for school back in the 1990’s. They had spent a whopping $99 at the local bookstore for a disk which held a total of 150MB. Not GB’s like we are used to now, but megabytes. I have some camera’s which takes RAW photos larger than then would fit on one disk. Once I had the data extracted from their disk, I took a look at the contents. There was a few file formats on the disk I was unfamiliar with. A quick scan with DROID revealed some matches and a few problems.

Turns out the data were files written by an old version of Bentley Microstation. The files dated from late 1995 and the disk was formatted for FAT16 which leans more to being used in a DOS system, but could have been used with the newly released Windows 95. The Bentley Microstation 95 software wasn’t released until November of 1995, so my guess is these Microstation files where created with the Microstation version 5 for DOS.

disktype HD6_imaged-004.hda 

Regular file, size 144.0 MiB (150998016 bytes)
No type and creator code
DOS/MBR partition map
Partition 4: 144.0 MiB (150978560 bytes, 294880 sectors from 32, bootable)
  Type 0x06 (FAT16)
  FAT16 file system (hints score 5 of 5)
    Volume size 143.8 MiB (150810624 bytes, 36819 clusters of 4 KiB)
    Volume name "ode 009 - I"

PRONOM has a few entries for the Microstation software:

PUIDFormat NameFormat NameExtension
x-fmt/346Microstation CAD Drawing95DGN
fmt/502Bentley V8 DGNDGN
fmt/1626MicroStation Symbology Resource FileRSC
fmt/1549Bentley Microstation Hidden Line FileHLN
fmt/1358MicroStation Base FileBSE
fmt/1183MicroStation Material PalettePAL
fmt/1177MicroStation Material LibraryMAT

The files found on this old Bernoulli disk gave varied results in identification. Most of the DGN files give me this multiple Identifications in DROID.

A little digging and we can learn a bit about the major formats. Integraph and Bentley used a Binary version of their drawing format, DGN, from versions 2 until 7, spanning 1987 to 2001, with the release of version 8, they made a major change to the format. Version 8 use the Microsoft OLE2 container to enhance the format allowing it to hold multiple drawings and more information about the model. With this change, the format became proprietary. Sure, they started an OpenDGN program to make the format more compatible with other systems, but required you to sign an NDA in order to get a copy of the format specifications. You had to request access and sign an NDA, which doesn’t sound “open” to me. You can read another file format researchers thoughts on this on her blog.

So I know many of these files are not Version 8 of the DGN format as they are not OLE2 containers, but the other issue is that x-fmt/346 for the Microstation CAD drawing 95 is an outline record. It has no signature. So DROID is guessing based on extension only. We need to dig deeper.

I noticed than many of the DGN files in my sample set also identified as a “Microstation Hidden Line File”, but instead of a HLN extension, they use DGN.

sf samp15.dgn 

filename : 'samp15.dgn'
filesize : 359424
modified : 1998-09-01T12:31:52-06:00
errors   : 
matches  :
  - ns      : 'pronom'
    id      : 'fmt/1549'
    format  : 'Bentley Microstation Hidden Line File'
    version : 
    mime    : 
    class   : 'Model'
    basis   : 'byte match at [[0 3] [359422 2]]'
    warning : 'extension mismatch'
hexdump -C samp15.dgn | head
00000000  08 09 fe 02 01 08 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 20 00 c8 45  |............ ..E|
00000020  00 00 00 00 00 00 00 00  40 06 0c 00 01 05 dc a0  |........@.......|
00000030  ff ff ff ff ff ff ff ff  b5 8b 9f 63 b9 88 85 a7  |...........c....|
00000040  00 00 00 00 19 00 b4 86  13 00 fe be 00 00 00 00  |................|
00000050  80 40 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |.@..............|
00000060  00 00 00 00 00 00 00 00  80 40 00 00 00 00 00 00  |.........@......|

hexdump -C samp7.dgn | head
00000000  c8 09 fe 02 01 08 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 04 7a 45  |..............zE|
00000020  00 00 00 00 00 00 00 00  e8 03 0a 00 01 05 fc b0  |................|
00000030  ff ff ff ff ff ff ff ff  0d 00 9d b5 0c 00 74 93  |..............t.|
00000040  ff ff a6 fd 09 00 40 11  05 00 50 aa 00 00 e5 f8  |......@...P.....|
00000050  80 40 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |.@..............|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Looking at a couple files in the same sample set, some use the header “08 09 fe 02 01 08 00 00” while another uses “c8 09 fe 02 01 08 00 00”. This is why samp15.dgn identifies as an HLN files as the signature matches, while samp7.dgn uses “C8” instead of “08” making it not identify as an HLN file. What is the difference and what is an HLN file?

First let’s define an HLN file. The name of the format is “Hidden Line File”, although most references refer to it as a “Visible Edges File“. Confusing, but the definition is: “a 2D or 3D DGN file that contains the edges visible in a 3D view (that is, with those edges that would be hidden, removed).”

Looking at a couple HLN files, we can see the format is the same as DGN files:

hexdump -C test-2d.hln | head
00000000  08 09 fe 02 08 01 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 20 00 7a 45  |............ .zE|
00000020  00 00 00 00 00 00 00 00  e8 03 0a 00 00 05 fc b2  |................|
00000030  ff ff ff ff ff ff ff ff  ff ff 5b f5 ff ff fe f9  |..........[.....|
00000040  00 00 00 00 01 00 d3 cb  01 00 36 2a 00 00 e8 03  |..........6*....|
00000050  80 40 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |.@..............|
00000060  00 00 00 00 00 00 00 00  80 40 00 00 00 00 00 00  |.........@......|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

hexdump -C test-3d.hln | head
00000000  c8 09 fe 02 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 20 00 7a 45  |............ .zE|
00000020  00 00 00 00 00 00 00 00  e8 03 0a 00 00 05 fc b2  |................|
00000030  ff ff ff ff ff ff ff ff  ff ff 5b f5 ff ff fe f9  |..........[.....|
00000040  ff ff 0c fe 01 00 d3 cb  01 00 36 2a 00 00 e8 03  |..........6*....|
00000050  80 40 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |.@..............|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  80 40 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |.@..............|

Same difference between the two previous files. These two files also explain the difference between the “08” and the “c8” values. Microstation uses the first to indicate it is a 2D file and the latter to indicate a 3D file. The DGN format has been documented in libdgn and this distinction is referenced.

This presents a problem with the current PRONOM identification. 

filename : 'MS95-2D.dgn'
filesize : 12288
modified : 2025-06-05T21:13:52-06:00
errors   : 
matches  :
  - ns      : 'pronom'
    id      : 'fmt/1549'
    format  : 'Bentley Microstation Hidden Line File'
    version : 
    mime    : 
    class   : 'Model'
    basis   : 'byte match at [[0 3] [12286 2]]'
    warning : 'extension mismatch'

filename : 'MS95-3D.dgn'
filesize : 12800
modified : 2025-06-05T21:14:00-06:00
errors   : 
matches  :
  - ns      : 'pronom'
    id      : 'x-fmt/346'
    format  : 'Microstation CAD Drawing'
    version : '95'
    mime    : 
    class   : 
    basis   : 'extension match dgn'
    warning : 'match on extension only'

The 2D files mis-identify as Hidden Line Files and the 3D files are identified through extension only. We learned from a previous test that Hidden Line Files can be both 2D and 3D and are the same format as DGN, so a separate identification PUID is unnecessary, but the x-fmt/346 identification doesn’t have a signatures, so a few things need to change.

The other issue is a Hidden Line File is also available in version 8+. 

filename : 'Microstationv8-s01.hln'
filesize : 7168
modified : 2025-06-05T19:48:09-06:00
errors   : 
matches  :
  - ns      : 'pronom'
    id      : 'fmt/502'
    format  : 'Bentley V8 DGN'
    version : 
    mime    : 
    class   : 'Image (Vector)'
    basis   : 'container name Dgn~H with name only'
    warning : 'extension mismatch'

They also identify as Bentley V8 DGN files, but with an extension mismatch. This should be easy to remedy with the addition of the extension HLN to the signature. The container signature seems to work well, no need to change anything.

My suggestions to fix these issues would be:

  • Depreciate x-fmt/346
  • Change name of fmt/1549 from “Bentley Microstation Hidden Line File” to “Microstation CAD Drawing” and use the version 2-7 to distinguish from v8
  • Change the signature for fmt/1549 from “0809FE” to “(08|C8)09FE02” no EOF of “FFFF”

The other option would be to make fmt/1549 the 2D drawing format and x-fmt/346 could be used for the 3D drawing format. What do you think?

I have uploaded a few samples to my GitHub page. Curious if your examples of DGN files match what I am seeing. There are a few other related formats that will need to be explored, but this should help for now.

SolidWorks

Posted on by Thor 1 Comment

The Digital Preservation Coalition recently released their tech watch report on Preserving Geospatial Data. This adds to reports on CAD, Construction, and others. One of the many areas of difficulties in Digital Preservation is understanding these areas of GIS, CAD, and 3D Modeling software and the file formats which belong to the software titles in this space. Not only are the file formats plentiful but the software is extensive and expensive. Documentation is lacking in understanding the different file formats associated with each software title. These tech watch reports are super useful, but more is needed to enhance the tools we use to better identify, validate, and transform these formats in order to preserve them long term.

I was processing some data sets from a recent collection added to our Scholarly repository and came across some models in the SolidWorks part format. I was surprised to find that this format has been around since 1995 and has yet to be added to the PRONOM registry.

SolidWorks is mechanical design software used for making 3D models which can be made to be individual parts, part of larger assemblies and added to drawings giving engineers access to 3D deisgn on their desktops. Bought by Dassault Systèmes in 1997, they are the makers of the CATIA CAD software. Since 1995 a new version was released almost every year, adding new features and improvements to the format. The original versions made use of the Microsoft OLE object container, but in 2015 the format shifted to a proprietary binary format. Let’s take a look at some samples.

There are three types of SolidWorks file formats, the SolidWork part (sldprt), the assembly (sldasm), and drawing (slddrw). The first versions of SolidWorks used prt, asm, and drw, but quickly added “sld” to avoid confusion with other CAD tools. 

Path = flatann.sldprt
Type = Compound
Physical Size = 5851648
Extension = compound
Cluster Size = 512
Sector Size = 64

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
1997-08-05 08:34:21 D....                            Contents
                    .....        60844        60928  Header
                    .....        45022        45056  Preview
1997-08-05 08:34:06 D....                            ThirdPty
                    .....          237          256  [5]SummaryInformation
1997-08-05 08:34:18 D....                            _MO_VERSION_629
                    .....          157          192  _MO_VERSION_629/History
                    .....          126          128  [5]DocumentSummaryInformation
                    .....       996343       996352  Contents/Definition
                    .....      1003198      1003520  Contents/Default
                    .....       781536       781824  Contents/DisplayLists
------------------- ----- ------------ ------------  ------------------------
1997-08-05 08:34:21            2887463      2888256  8 files, 3 folders

We can see this file is a compound (OLE) container file. It’s very useful to have a directory within the container with a version number. With this version number we can use the chart on the file format wiki to see this file was last modified by SolidWorks 97 Plus. The problem comes in when we look at an assembly file and compare.

Path = dispenser.sldasm
Type = Compound
Physical Size = 2143232
Extension = compound
Cluster Size = 512
Sector Size = 64

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
1997-03-19 17:29:16 D....                            ThirdPty
                    .....        16812        16896  Preview
                    .....         4655         5120  Header
1997-09-04 15:30:48 D....                            Contents
                    .....      1009461      1009664  Contents/DisplayLists
                    .....        23931        24064  Contents/Definition
                    .....          237          256  [5]SummaryInformation
1997-09-04 15:35:39 D....                            _MO_VERSION_629
                    .....          107          128  _MO_VERSION_629/History
                    .....          126          128  [5]DocumentSummaryInformation
------------------- ----- ------------ ------------  ------------------------
1997-09-04 15:35:39            1055329      1056256  7 files, 3 folders

Almost the same contents, the same version directory. The only difference in content is the file Defaults in the Contents directory. But hard to know if all have the same difference. We will have to look closer at the individual files to hopefully find what sets the different formats apart.

The SolidWorks 2000 format added additional files to the container which can help. 

Path = SW2000-s01.SLDPRT
Type = Compound
Physical Size = 20992
Extension = compound
Cluster Size = 512
Sector Size = 64

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2024-01-16 20:00:51 D....                            _DL_VERSION_1500
                    .....         5300         5632  Preview
                    .....          481          512  Header
2024-01-16 20:00:51 D....                            Contents
2024-01-16 20:00:51 D....                            ThirdPty
                    .....            4           64  Contents/OleItems
                    .....           69          128  Contents/CMgrHdr
                    .....          343          384  Contents/CMgr
                    .....         5456         5632  Contents/Config-0
                    .....          592          640  Contents/DisplayLists__Zip
                    .....          957          960  Contents/Definition
                    .....          252          256  [5]SummaryInformation
2024-01-16 20:00:51 D....                            _MO_VERSION_1500
                    .....          840          896  _MO_VERSION_1500/Biography
                    .....           98          128  _MO_VERSION_1500/History
                    .....          148          192  [5]DocumentSummaryInformation
                    .....          120          128  ISolidWorksInformation
                    .....            6           64  _DL_VERSION_1500/DLUpdateStamp
------------------- ----- ------------ ------------  ------------------------
2024-01-16 20:00:51              14666        15616  14 files, 4 folders

The introduction of the “ISolidWorksInformation” file helps give positive identification of the SolidWorks format.

hexdump -C SW2000-s01.SLDPRT/ISolidWorksInformation      
00000000  fe ff 00 00 04 0a 02 00  02 d5 cd d5 9c 2e 1b 10  |................|
00000010  93 97 08 00 2b 2c f9 ae  01 00 00 00 05 d5 cd d5  |....+,..........|
00000020  9c 2e 1b 10 93 97 08 00  2b 2c f9 ae 30 00 00 00  |........+,..0...|
00000030  48 00 00 00 02 00 00 00  02 00 00 00 18 00 00 00  |H...............|
00000040  00 00 00 00 24 00 00 00  1e 00 00 00 01 00 00 00  |....$...........|
00000050  00 00 00 00 02 00 00 00  00 00 00 00 01 00 00 00  |................|
00000060  00 02 00 00 00 0d 00 00  00 53 57 2d 46 69 6c 65  |.........SW-File|
00000070  20 4e 61 6d 65 00 00 00                           | Name...|

hexdump -C SW2000-s02.SLDASM/ISolidWorksInformation
00000000  fe ff 00 00 04 0a 02 00  02 d5 cd d5 9c 2e 1b 10  |................|
00000010  93 97 08 00 2b 2c f9 ae  01 00 00 00 05 d5 cd d5  |....+,..........|
00000020  9c 2e 1b 10 93 97 08 00  2b 2c f9 ae 30 00 00 00  |........+,..0...|
00000030  6c 00 00 00 03 00 00 00  02 00 00 00 20 00 00 00  |l........... ...|
00000040  03 00 00 00 2c 00 00 00  00 00 00 00 34 00 00 00  |....,.......4...|
00000050  1e 00 00 00 01 00 00 00  00 00 00 00 0b 00 00 00  |................|
00000060  00 00 00 00 03 00 00 00  00 00 00 00 01 00 00 00  |................|
00000070  00 03 00 00 00 0e 00 00  00 41 73 73 65 6d 62 6c  |.........Assembl|
00000080  79 20 74 79 70 65 00 02  00 00 00 0d 00 00 00 53  |y type.........S|
00000090  57 2d 46 69 6c 65 20 4e  61 6d 65 00              |W-File Name.|

hexdump -C SW2000-s01.SLDDRW/ISolidWorksInformation
00000000  fe ff 00 00 04 0a 02 00  02 d5 cd d5 9c 2e 1b 10  |................|
00000010  93 97 08 00 2b 2c f9 ae  01 00 00 00 05 d5 cd d5  |....+,..........|
00000020  9c 2e 1b 10 93 97 08 00  2b 2c f9 ae 30 00 00 00  |........+,..0...|
00000030  bc 01 00 00 0a 00 00 00  02 00 00 00 58 00 00 00  |............X...|
00000040  03 00 00 00 64 00 00 00  04 00 00 00 70 00 00 00  |....d.......p...|
00000050  05 00 00 00 7c 00 00 00  06 00 00 00 88 00 00 00  |....|...........|
*
000000d0  05 00 00 00 52 27 a0 89  b0 e1 d1 3f 05 00 00 00  |....R'.....?....|
000000e0  51 6b 9a 77 9c a2 cb 3f  03 00 00 00 00 00 00 00  |Qk.w...?........|
000000f0  0a 00 00 00 00 00 00 00  01 00 00 00 00 04 00 00  |................|
00000100  00 15 00 00 00 53 57 2d  53 68 65 65 74 20 46 6f  |.....SW-Sheet Fo|
00000110  72 6d 61 74 20 53 69 7a  65 00 05 00 00 00 11 00  |rmat Size.......|
00000120  00 00 53 57 2d 43 75 72  72 65 6e 74 20 53 68 65  |..SW-Current She|
00000130  65 74 00 08 00 00 00 19  00 00 00 41 63 74 69 76  |et.........Activ|
00000140  65 20 73 68 65 65 74 20  70 61 70 65 72 20 77 69  |e sheet paper wi|
00000150  64 74 68 00 02 00 00 00  0d 00 00 00 53 57 2d 46  |dth.........SW-F|
00000160  69 6c 65 20 4e 61 6d 65  00 09 00 00 00 14 00 00  |ile Name........|
00000170  00 41 63 74 69 76 65 20  73 68 65 65 74 20 48 65  |.Active sheet He|
00000180  69 67 68 74 00 07 00 00  00 0e 00 00 00 53 57 2d  |ight.........SW-|
00000190  53 68 65 65 74 20 4e 61  6d 65 00 0a 00 00 00 18  |Sheet Name......|
000001a0  00 00 00 41 63 74 69 76  65 20 73 68 65 65 74 20  |...Active sheet |
000001b0  70 61 70 65 72 20 73 69  7a 65 00 03 00 00 00 0f  |paper size......|
000001c0  00 00 00 53 57 2d 53 68  65 65 74 20 53 63 61 6c  |...SW-Sheet Scal|
000001d0  65 00 06 00 00 00 10 00  00 00 53 57 2d 54 6f 74  |e.........SW-Tot|
000001e0  61 6c 20 53 68 65 65 74  73 00 00 00              |al Sheets...|

Starting in 2015 the format changed from an OLE container, to a binary file. Here is what the first few bytes look like from a 2015 file and a later 2023 file:

hexdump -C Bracket.SLDPRT | head
00000000  9f e4 18 9f 00 00 00 04  26 00 42 15 14 00 06 00  |........&.B.....|
00000010  08 00 06 00 40 a5 c3 a7  0e 51 5b 03 00 00 91 07  |....@....Q[.....|
00000020  00 00 0d 00 00 00 34 f6  e6 47 56 e6 47 37 f2 34  |......4..GV.G7.4|
00000030  d4 76 27 b5 55 5d 48 14  51 14 3e ab 2e f6 63 65  |.v'.U]H.Q.>...ce|
00000040  8b be 55 2e 42 0f 45 89  05 16 68 3a 93 eb f6 03  |..U.B.E...h:....|
00000050  ab 2e ae 89 d4 c2 3a ee  ce ae 53 bb 3b cb cc 2e  |......:...S.;...|
00000060  18 42 0d f8 16 41 3d 95  42 94 24 41 b0 3d 54 14  |.B...A=.B.$A.=T.|
00000070  fd 68 ad 52 0f 45 54 06  61 84 d1 0f 52 3e 44 20  |.h.R.ET.a...R>D |
00000080  48 af 6e e7 cc cc dd 3f  5d ea a5 3b dc 3d df f9  |H.n....?]..;.=..|
00000090  b9 e7 9c 7b ef b9 67 d3  69 0b 54 41 44 76 c8 d1  |...{..g.i.TADv..|

hexdump -C SW2023-s01.SLDPRT | head
00000000  f4 e9 02 fc 00 00 00 04  51 3f 60 ad 6a 35 f9 b3  |........Q?`.j5..|
00000010  14 00 06 00 08 00 a8 8c  60 c0 d0 05 00 00 74 01  |........`.....t.|
00000020  00 00 e8 02 00 00 07 00  00 00 05 27 56 67 96 56  |...........'Vg.V|
00000030  77 d6 df ea 07 e7 cf ed  c6 8e 6c a1 48 70 d6 76  |w.........l.Hp.v|
00000040  cd 16 7f e9 6b 95 3a 4e  bb 6e 95 cc d2 b3 69 a9  |....k.:N.n....i.|
00000050  72 6b af c7 82 38 95 6f  bc 37 d2 4e a6 28 36 bd  |rk...8.o.7.N.(6.|
00000060  c3 cf 85 46 0a 85 63 97  83 56 88 a1 38 02 64 14  |...F..c..V..8.d.|
00000070  00 06 00 08 00 a8 8c 60  c0 44 07 00 00 d1 01 00  |.......`.D......|
00000080  00 a2 03 00 00 22 00 00  00 34 f6 e6 47 56 e6 47  |....."...4..GV.G|
00000090  37 f2 34 f6 e6 66 96 76  d2 03 d2 25 56 37 f6 c6  |7.4..f.v...%V7..|

The newer version of the format is much different and is in a proprietary binary format with no specifications, which makes it much more difficult to know which parts of the file can be used for identification. All these new formats have the hex values “00 00 00 04” as bytes 4 through 7. Not very unique for identification. There is another set of bytes which does seem to be consistent for all samples so far, but they vary in their location. The values “34 f6 e6 47 56 e6 47 37 f2” seem to be in every sample. The 10th byte often has the value 34, but in many samples either has 34, B4, 44, 64, or 33. The other formats, SLDASM and SLDDRW also have this pattern which might give us enough to make a good signature. At this time we may not be able to distinguish the different formats, but maybe in the future.

More work is needed to really develop signatures that can identify each format from SolidWorks definitely. My initial assumptions we not completely correct and there are a few exceptions to the patterns I felt were good enough. One unknown is the formats from SolidWorks 95 through 99 and properly identifying them. More samples are needed. I have placed my initial signature and some samples on my GitHub. Please get in tough if you have additional samples or ideas on better identification.