Content Export & Import

Glasswall provides the ability to export and import content items for supported file types.

This allows internal components of processed files to be made available to external processes and applications for additional processing outside of the Glasswall Embedded Engine domain. Once exported, these components can be validated externally before the Glasswall Engine imports the components and recomposes the files.

To enable the user to carry out additional analysis on components within files, the files must be processed by the Glasswall Embedded Engine twice; once to extract a package containing the components that make up a file (export), and a second pass to reintegrate the externally analysed and/or modified components back into the file (import). Files are also automatically protected through the Embedded Engine CDR process throughout both the export and import cycles.

Example use cases

Example use cases for Export-Import processing include but are no limited to:

• Pattern For Safely Importing Data - Glasswall exposes the internal file structure in a standard form such as XML, enabling third parties to carry out hardware verification as part of the pattern for safely importing data
• Data Loss Prevention - Exported content such as text is annotated to allow for all text to be identified, enabling users to carry out DLP processes such as text search and redaction.
• Image analysis - Additional image processing to detect and/or prevent steganography attacks.

Exportable content

Glasswall provides the ability to export a document object model (DOM), which includes all content, for all supported file formats. The exported DOM is presented in one of two intermediate formats, XML or SISL. Users have the option to extract embedded images in their original form or export them as a DOM representation.

Importable content

Glasswall provides the ability to re-import a document object model (DOM) for all supported file formats, regardless of external modification made to the exported content (provided that modifications comply with the file format specification).

Export package content

The Export package is a ZIP archive containing XML or SISL file streams, embedded images and corresponding JSON files with metadata (for PDF images).

Internal names of XML tags/attributes and SISL types/parameters are shortened to minimize the size of exported file streams.

XML tags and SISL types:

Tag / Type (Shortened)	Tag / Type (Full)	Description
"S"	STRUCT	Represents a structure node from our tree.
"SA"	STRUCTARRAY	The array of STRUCT objects.
"I"	ITEM	A property within a STRUCT object (e.g., whitespace indicators, end-of-file markers etc.)
"V"	VALUE	Represents the stored integer value that was read from a file.
"VA"	VALUEARRAY	Represents a data block read from a file.
"B"	BASE64BLOCK	XML only. One block of a base64 VALUEARRAY payload that is too large to be carried as a single run of character data. See Chunked base64 value arrays.

XML attributes and SISL parameters

Attribute / Parameter (Shortened)	Attribute / Parameter (Full)	Data Type	Description
"o"	offset	<integer string>	The attribute contains the offset of the current item in the buffer. The buffer can represent things such as the file, a file within an archive, an amalgamation of streams from a CFB object, and more.
"s"	size	<integer string>	The total length of the current structure in bytes.
"i"	itemEnum	<integer string>	The internal numerical representation of the current ITEM.
"n"	name	<string>	The internal name of the current structure.
"t"	isText	<string> [ "true | "false" ]	Indicates if the element contains text or not. Only applicable to items which are marked as text within internal schemas.
"se"	structEnum	<integer string>	The internal numerical representation of the current STRUCT.
"sn"	streamName	<string>	The current stream name.
"c"	cameraName	<string>	The current camera (parser/validator/writer) name.
"st"	isStructuralText	<string> [ "true | "false" ]	The attribute to distinguish between structural information and the file's visible text content. Only applicable to items which are marked as text within internal schemas.
"e"	encoding	<string> [ "UTF 8 | "Base64"]	The attribute specifies the encoding of data within the current element. Only applicable to items which are marked as text within internal schemas.

SISL specific parameters

Parameter (Shortened)	Parameter (Full)	Data Type	Description
"__s"	struct	<dictionary>	General SISL structure of type: [ S | SA | I | V | VA ]
"__m"	meta	<dictionary>	Dictionary of the current SISL structure parameters
"__d"	data	<string>	The stored data of ITEM, VALUE or VALUEARRAY
"__l"	length	<integer string>	The original size of data stored in __d before non-printable characters were escaped.

Chunked base64 value arrays

A VA element normally carries its base64 payload as direct character data. Above a size threshold the XML exporter instead writes the payload as a sequence of B block elements inside the VA:

<VA i="31" n="data" o="120" e="Base64"><B>ABCD...</B><B>EFGH...</B></VA>

This form is used only above that threshold; at or below it, the payload remains direct character data of VA and the exported bytes are unchanged. B applies to the XML interchange format only - SISL writes value arrays as escaped raw data and never base64 encodes them, so it has no equivalent.

Reading a chunked value array. Concatenate the contents of the B blocks in document order, then base64 decode the result. Do not decode blocks individually and join the bytes, and do not assume a fixed block size: the block size is an exporter setting and may change between releases.

Writing a chunked value array. Every block except the last must hold a whole number of 4-character base64 groups and contain no = padding - equivalently, cut the raw payload on a multiple of 3 bytes, so that padding can only appear in the final block. This is a requirement of the format, not just a convention of the Glasswall exporter. Base64 padding is not a separator: a decoder skips = and carries its bit accumulator straight into the following characters, so blocks padded individually concatenate into valid-looking base64 that decodes to shifted, incorrect bytes from the first padded block onwards, with no error raised. The schema cannot express this constraint and importers do not detect its violation.

Mixing the two forms. The schema permits a VA that contains both character data and B blocks. The Glasswall exporter never writes both in one VA; on import, the VA character data and each block's contents are concatenated in document order into a single payload. Whitespace between blocks is ignored.

Note: A package containing a chunked value array requires an Embedded Engine release that supports the B element to import correctly. An older engine does not recognize B, skips it, and imports the value array as empty without reporting an error - the payload is silently lost. If an import appears to succeed but content is missing, check the engine version against the version that produced the package.

Export text dump (alpha)

The Export Text Dump feature introduces the option to produce a file containing all the text within the input file being exported. The file is produced and stored in the same directory as the output ZIP file.

Text dumps can be exported alongside or without content export zips.

File Format	Supported
Office 2003	✓
Office 1997	✓
PDF	✓ *
Binary formats	✗
Audio formats	✗
Image formats	✗
MPEG formats	✗

Note: Text Dump for PDF is currently unavailable when the sysConfig switch export_embedded_images set to true. It is also only limited to a subset of PDF text encodings.