The linked document specifies a data exchange format based on XML. It describes how to package all data (including the fingerprint.codex.xml) in 3. (U) Directory Structure.
The whole CODEX data including single xml files (e.g fingerprint.codex) or metadata of the retrieved data (like emails or screenshots) mustn't be generated on the target host:
Generation of these metadata files and
formats MUST NOT take place on the target. Instead, tools MUST ship back to the user the necessary
details such that a Codex file or structure can be produced from the tool-specific custom format on usercontrolled,
potentially not internet connected, hardware. To repeat, tools MUST not store data on
target in Codex format or generate any custom Codex format on target.
Target here means: a monitored/attacked host. User here probably means: a data evaluator/processor of the agency or one of its contractors.
As a consequence the fingerprint.codex.xml doesn't even exist on the target's host but is generated somewhere else based on the conveyed data.
According to the document (4.4 (U//FOUO) Fingerprint XML Format) a macOS fingerprint simply consists of the md5'd lowercase UUID of the root system. All other keys except usertag are related to Windows or Linux operating systems.
The UUID can be retrieved by entering:
diskutil info / | grep "Volume UUID" | tr '[:upper:]' '[:lower:]' | awk '{print $3}'
and its md5 hash with:
md5 -s $(diskutil info / | grep "Volume UUID" | tr '[:upper:]' '[:lower:]' | awk '{print $3}')
The whole fingerprint file would look like this for a Mac (here an example macOS VM):
<codex version=”1”>
<fingerprint target=”machine” type=”os” version=”1”>
<uid>“db78ec1b99a4e71fabbc0e23888baf64</uid>
<rootfsid>d15d6f4e-d213-373d-893e-f975126cb767</rootfsid>
<usertag>NONE</usertag>
</fingerprint>
<fingerprint target=”machine” type=”hardware” version=”1”>
</fingerprint>
<timestamp>2017-03-24 07:11:00.000000Z</timestamp>
</codex>
Under the given circumstances the fingerprint file can't get "corrupted" or "spoofed" on your host - it's simply generated and stored somewhere else.
You can of course invalidate the current fingerprint related to your Mac by erasing your boot volume and installing a new system - this will generate a new Volume UUID (or rootfsid).
I don't know whether the agency has a tool or a method to link a new fingerprint (and related CODEX data) created after a "friendly second visit"/surveillance/attack to the old fingerprint (and related CODEX data) of your now overwritten root volume. It probably has!
And to answer your questions somehow:
- You can't detect if the fingerprint file is corrupted because you probably have no access to CIA data storage facilities
- You can't spoof the fingerprint file because you probably have no access to CIA data storage facilities and how should malware get non-functional at boot by a remote fingerprint file?
- You can use any more or less "secure" hash algorithm to compute the uid in the fingerprint file. By definition it's md5 though.
