.DWG File Format – File structure

Version strings

The first six bytes are an ASCII version string. The ODA specification lists these; the code in the third column is the one the auxiliary header stores for the released (non-beta) format.

The auxiliary header’s list also gives codes for AC1010 (17), AC1011 (18) and AC1013 (20), and a beta code one below each released code from AC1015 on. LibreDWG’s version table names AC1010 and AC1011 as R13 betas and AC1013 as Release 13c3. The specification notes that the layout changed between R13 C2 and R13 C3; a file is in the C3 layout when it has four or more section locators.

R13 to R2000 (AC1012, AC1014, AC1015)

Layout

The parts of the file, in order:

1. File header (below), ending in a CRC and a sentinel
2. Header variables, then a CRC
3. Class definitions
4. Template (R13 only, optional)
5. Padding (R13 C3 and later; see Not confirmed for its size)
6. Image data (before R13 C3)
7. Object data: all entities, table entries, dictionary entries and other objects
8. Object map
9. Object free space (optional)
10. Template (R14 and R2000, optional)
11. Second header
12. Image data (R13 C3 and later)

File header

The CRC is the 8-bit CRC with initial value 0, and the result is XORed with a value that depends on the number of locator records:

Section locators

Worked example

The specification prints the start of an empty R14 drawing, empty14.dwg. These are its first 0x58 bytes and the 16 that follow:

00000  41 43 31 30 31 34 00 00  00 00 00 00 01 3F 0C 00
00010  00 00 00 1E 00 05 00 00  00 00 58 00 00 00 ED 01
00020  00 00 01 45 02 00 00 26  00 00 00 02 27 0B 00 00
00030  50 00 00 00 03 77 0B 00  00 35 00 00 00 04 3B 0C
00040  00 00 04 00 00 00 2D 5C  95 A0 4E 28 99 82 1A E5
00050  5E 41 E0 5F 9D 3A 4D 00  CF 7B 1F 23 FD DE 38 A9
00060  5F 7C 68 B8 4E 6D 33 5F  C7 01 00 00 00 00 07 00

The sizes agree: 16 (sentinel) + 4 (size) + 0x1C7 (data) + 2 (CRC) + 16 (sentinel) is 0x1ED, and the class section starts at 0x58 + 0x1ED = 0x245.

R2004 and later (AC1018, AC1024, AC1027, AC1032)

After the file header, the file is a sequence of pages. A system section is one page; a data section is one or more pages. Two system sections, the page map and the section map, act as the table of contents; once they are read, every other section can be reached directly. R2010, R2013 and R2018 keep this layout (see below).

File header

Security flags (offset 0x18)

When the value is above 0, the file has an AcDb:Security section.

Encrypted header data

The 0x6C bytes at 0x80 are XORed with a fixed sequence. The sequence comes from this generator, which the specification gives:

int randseed = 1;
for (int i = 0; i < 0x6c; i++) {
    randseed *= 0x343fd;
    randseed += 0x269ec3;
    data[i] = (unsigned char)(randseed >> 0x10);
}

Decrypted, the bytes are the “2004 file header data”. The same data is repeated near the end of the file (the second header data).

The next 0x14 bytes of the file header, at 0xEC, are copied from the magic sequence starting at its offset 0x100 − 0x14. They appear in the header at the start of the file but not in the copy at the end.

Page checksum

System and data page headers carry a 32-bit checksum computed by this function:

uint32_t checksum(uint32_t seed, const uint8_t *data, uint32_t size)
{
    uint32_t sum1 = seed & 0xffff;
    uint32_t sum2 = seed >> 0x10;
    while (size != 0) {
        uint32_t chunk = size < 0x15b0 ? size : 0x15b0;
        size -= chunk;
        for (uint32_t i = 0; i < chunk; i++) {
            sum1 += *data++;
            sum2 += sum1;
        }
        sum1 %= 0xFFF1;
        sum2 %= 0xFFF1;
    }
    return (sum2 << 0x10) | (sum1 & 0xffff);
}

System section pages

A system page starts with a 0x14-byte header:

CompDataSize bytes of compressed data follow, and then a second copy of the header with the sizes and checksum set to zero. The checksum is computed in two stages: first over the header (with its checksum field 0) with seed 0, then over the compressed data using the first result as the seed. Every page starts on a 0x20-byte boundary; the gap before it is filled with bytes from the magic sequence.

Section page map

Decompressed, the page map is a list of entries, one per page in the file:

A negative page number marks a gap (unused space), and four more fields follow it:

The first page is at address 0x100; each later page’s address is the previous address plus the previous size. Pages are numbered consecutively, the system pages last, with a gap of one between the data page numbers and the system page numbers. The list, indexed from 1, is called the SectionPageMap.

Data section map

The section map describes the data sections only. Decompressed, it starts:

Then each section description:

And then, page count times:

Rules for assembling a section from its pages:

• If a page’s start offset is greater than the total decompressed size of the pages before it, zero pages (each of the section’s page size) were left out and must be inserted until the totals match. A smaller start offset means the file is malformed.
• After the last page, if the total is still short of the section size, add zero pages until it is reached.
• The order in the map is authoritative; pages must not be reordered. Page i starts at i times the page size.
• Every stored page is a whole page, padded to the page size, and the padding is covered by its data checksum. Take only the logical part: the lesser of the page size and the section size minus the page’s start offset.
• The page size must be read from each section description, not assumed: AcDb:FileDepList, AcDb:AppInfo, AcDb:Preview and AcDb:SummaryInfo use smaller pages.

Sections

Sections seen in R2004 files, in section map order:

The order in the file is different: file header, empty section, AcDb:SummaryInfo, AcDb:Preview, AcDb:VBAProject, AcDb:AppInfo, AcDb:FileDepList, AcDb:RevHistory, AcDb:Security, AcDb:AcDbObjects, AcDb:ObjFreeSpace, AcDb:Template, AcDb:Handles, AcDb:Classes, AcDb:AuxHeader, AcDb:Header, section map, section page map. R2013 adds the AcDb:AcDsPrototype_1b data storage section.

Data section page headers

Each data page starts with a 32-byte header masked with a fixed XOR (unrelated to password encryption). Treat the header as eight 32-bit little-endian words and XOR each with 0x4164536B ^ offset, where offset is the low 32 bits of the header’s absolute address in the file, exactly as the SectionPageMap gives it (0x100 plus the sizes of the pages before it).

For R2004 and later, the decompressed AcDb:AcDbObjects data starts with an RL of 0x0DCA, of unknown meaning.

Compression

R2004 compression is a variant of LZ77: back-references (offset and length) to data already decompressed, mixed with runs of literal bytes. A length may be greater than its offset. A compressed stream starts with a literal length, giving the first run of literal bytes. Then come opcode sets, each giving three values: compressedBytes to copy from earlier output, compOffset backwards from the current position, and litCount literal bytes to copy from the input after them.

LibreDWG’s decoder (decompress_R2004_section) reads these opcodes a little differently, which matters to anyone writing a decoder: it adds 1 to every back-reference offset, so the offsets above are the distance minus one; for opcodes 0x10 to 0x1F it takes the length from the low three bits (0 meaning an extended length, read like a long compression offset and added to 7, then 2 added) and uses bit 3 of the opcode as offset bit 14, adding 0x4000; and its literal length accepts 0x01 to 0x0F.

R2007 (AC1021)

R2007 also has system and data sections made of pages, but every part is coded differently from R2004. The order in the file:

Meta data

File header

At 0x80 is a 0x400-byte block. Its last 0x28 bytes, from 0x3D8, are check data: five 64-bit values (the normal CRC, the mirrored CRC, two random values and the encoded CRC seed, in that order in the file). The first 0x3D8 bytes are Reed-Solomon (255, 239) coded, interleaved with a factor of 3. Decoded, they hold:

The decompressed 0x110 bytes are the file header proper:

The file header is written at 0x80 and again at the end of the file. To write it, the specification computes the CRCs and check data, compresses the header, builds a buffer of 3 × 239 bytes holding a checking sequence, the compressed CRC, the compressed size and the data, repeated as often as it fits and padded with bytes from the random encoder, Reed-Solomon codes it to 3 × 255 bytes, pads the 0x400-byte page with random bytes and puts the check data in its last bytes. The CRC seeds are themselves encoded with the random encoder. The check data uses a 64-bit rotate, Encode(value, control), which rotates value left by control & 0x1F bits; the specification gives the full order of operations in its section 5.2.1.

Page map

The page map is one system page at PagesMapOffset, decoded as a system page. Its data is pairs of 64-bit values, a size and an ID; a page’s offset is the sum of the sizes before it:

int64_t offset = 0;
while (!eof) {
    int64_t size = read_int64();
    int64_t id = read_int64();
    int64_t index = id > 0 ? id : -id;
    pages[index].id = id;
    pages[index].size = size;
    pages[index].offset = offset;
    offset += size;
}

Section map

The section map is at the offset of page SectionsMapId, decoded as a system page with the SectionsMap sizes, CRCs and correction factor from the file header. For each section it holds:

Then, for each page:

Each page may be Reed-Solomon coded, compressed or encrypted. By default nothing is encrypted; the specification says encryption is still to be described.

Sections

Encoding 1 means the Reed-Solomon blocks are not interleaved; 4 means they are. In R2007 the AcDb:Classes and AcDb:Header data keep their strings in a separate string stream, and the header’s handles in a separate handle stream, as objects do (see the string stream).

System and data pages

System pages (the page map and section map) take the data and a 64-bit CRC seed. The specification computes a mirrored 64-bit CRC of the data (seed updated with UpdateSeed1), compresses it if that makes it shorter, computes another CRC of the result, pads it with zeros to a multiple of 8, repeats it as many times as fits, Reed-Solomon codes it (255, 239), interleaved, and fills the rest of the page with random bytes. The number of repeats is the correction factor stored in the file header. The page size is at least 0x400:

uint64_t system_page_size(uint64_t data_size)
{
    uint64_t aligned = (data_size + 7) & ~7ULL;       /* CRC block size 8 */
    uint64_t size = (aligned * 2 + 239 - 1) / 239 * 255; /* fit the data twice */
    if (size < 0x400)
        return 0x400;
    return (size + 0x1F) & ~0x1FULL;                  /* page alignment 0x20 */
}

Data pages hold all other sections, split into pages of the section’s maximum size. For each page: a 32-bit checksum of the data (below), then optional compression (kept only if shorter), optional encryption, a mirrored 64-bit CRC (seed: the file’s CRC seed updated with UpdateSeed1), zero padding to a multiple of 8, and Reed-Solomon (255, 251) coding, interleaved when the section’s encoding is 4. Pages start on 0x20-byte boundaries and are padded with zeros.

The data page checksum seeds the R2004 checksum with seed = (seed + length) * 0x343FD + 0x269EC3, then adds bytes in the same way, except that within each 8-byte group the bytes are taken in the order 6, 7, 4, 5, 2, 3, 0, 1, and a remainder of 1 to 7 bytes has its own order (section 5.4.1 of the specification lists each case).

Compression

R2007 uses another LZ77 variant. The source contains opcodes, offsets and lengths; a literal run is followed by one or more back-references. If the first opcode’s high nibble is 2, the source pointer moves 2 bytes, a length is read from the next byte and masked with 0x07, and the pointer moves one more byte. A literal length is read as opcode + 8; if that is 0x17, the next byte is added, and if that byte was 0xFF, 16-bit little-endian values are added until one is not 0xFFFF. Literal bytes are copied in 32-byte blocks, with the bytes of each block in a shuffled order that the specification tables for counts 1 to 32.

Back-references are read by opcode high nibble:

After each copy, opcode & 7 gives the next literal length; if it is 0 and input remains, the next byte is read as an opcode: high nibble 0 ends the run of back-references, high nibble 15 is masked to its low nibble.

CRC random encoding

Some CRCs are stored as 64-bit values carrying only 10 data bits, the rest filled from a pseudo-random table of 0x270 32-bit values made from one 64-bit seed:

table[0] = (uint32_t)seed * 0x343fd + 0x269ec3;
table[1] = (uint32_t)(seed >> 32) * 0x343fd + 0x269ec3;
uint32_t value = table[1];
for (uint32_t i = 2; i < 0x270; i++) {
    value = ((value >> 0x1e) ^ value) * 0x6c078965 + i;
    table[i] = value;
}

To encode, take the next 64-bit random value (the index moves on by 2), mask its low word with 0xDF7DF7DF and high word with 0xF7DF7DF7, and set one bit for each of the 10 data bits:

Decoding tests the same bits.

64-bit CRCs

R2007 uses two 64-bit CRCs, each with its own 256-entry table printed in the specification. The normal CRC follows ECMA-182: table[(byte ^ (crc >> 56)) & 0xFF] ^ (crc << 8) per byte, with the result inverted at the end; its table starts 0x0000000000000000, 0x42F0E1EBA9EA3693. The mirrored CRC shifts the other way: table[(crc ^ byte) & 0xFF] ^ (crc >> 8), not inverted; its table starts 0x0000000000000000, 0x7AD870C830358979. Bytes are fed in groups of 8 in a fixed shuffled order. Two functions prepare the seed:

seed1 = (seed + length) * 0x343fd + 0x269ec3;
seed1 |= seed1 * (0x343fdULL << 32) + (0x269ec3ULL << 32);
seed1 = ~seed1;                                   /* UpdateSeed1 */

seed2 = (seed + length) * 0x343fd + 0x269ec3;
seed2 = seed2 * ((1ULL << 32) + 0x343fd) + (length + 0x269ec3);
seed2 = ~seed2;                                   /* UpdateSeed2 */

Reed-Solomon coding

Not interleaved: all data blocks come first, then the parity blocks. Interleaved: with n blocks, the bytes of block j (data and parity) go to positions n × i + j. A last block that is not full is padded with random bytes.

R2010, R2013 and R2018

• R2010 (AC1024) uses the R2004 file header, page map, section map and compression, and the R2007 bit coding, except that the object type is coded differently. As in R2007, data, strings and handles are in separate streams in the header and objects.
• R2013 (AC1027) is mostly R2010. The header section gains two fields, and a new section, AcDb:AcDsPrototype_1b, holds data storage such as ACIS data for regions and solids. Known valid maintenance versions in March 2013 were 6 and 8; the ODA writes 8.
• R2018 (AC1032) is structurally identical to R2013. The auxiliary header gains three zero shorts at its end; the header section’s extra unknown 32-bit value after the size is always present; ACAD_PROXY_ENTITY, ATTRIB, ATTDEF and MTEXT gain fields; and MLINESTYLE refers to line types by handle instead of index.

Not confirmed

• The R13 C3 padding is “200 bytes” in chapter 3 and 0x200 bytes in chapter 11 of the specification.
• The two bytes at 0x11 and 0x12 of the R13 to R2000 file header are not described.
• The meaning of the sixth section locator record, and of the RL 0x0DCA at the start of R2004 object data, is unknown.
• The R2007 check data is five 64-bit values (0x28 bytes from 0x3D8), but section 5.2.1.7 of the specification says the last 0x20 bytes of the page are overwritten with it.
• R2007 encryption is “still to be described” in the specification, and the R2004 literal length range is given as 0x01–0x0E with results 4 to 0x12, which only fits 0x01–0x0F (LibreDWG accepts 0x0F).
• The R2004 opcode table differs from LibreDWG’s decoder for opcodes 0x10 to 0x1F and in the +1 on offsets, as described under Compression; neither reading has been tested against files for this page.

Sources

• Open Design Specification for .dwg files, version 5.4.1 – Open Design Alliance; chapters 3 (R13 to R15), 4 (R2004), 5 (R2007), 6 to 8 (R2010, R2013, R2018), the header dump in chapter 9 and the version list in chapter 27
• LibreDWG include/dwg.h and src/common.c – the version table naming the pre-release strings
• LibreDWG src/decode.c – decompress_R2004_section, the R2004 decompressor