#5140 introduced automatic tagging of events that are "recovered" or "corrupted" (or both).
Different states/traits that are beneficial to capture and surface to analysts:
- corrupted; the parser encountered a format (edge) case where parsing failed. Note that this could be also related to the parsing configuration such as a code page. For now this includes certain edge cases, such as UCS-2 string conversion, where technically it is not corruption, given that due to technical reasons it is the parser that cannot handle the edge case
- recovered; the parser undertook steps to recover the event data outside "regular" (allocated) structures of the data format
Consider adding:
- dirty; the data format indicates its structures are "dirty", e.g. ESE databases
- recovered_from_journal or recovered_from_log: the parser undertook steps to recover the event data outside "regular" (allocated) structures of the data format using an accompanying journal or transaction log. What about SQLite WAL, should this be recovered_from_wal?
- incomplete; the parser encountered a format (edge) case it could not complete parse the event data, e.g. payload_type != xml in windows_push_notification parser. What about unsupported record types as in ios_app_privacy? or log action in xchatlog.py?
- stored_external/stored_remote; To indicate files with content stored remotely (network or Cloud)?
#5140 introduced automatic tagging of events that are "recovered" or "corrupted" (or both).
Different states/traits that are beneficial to capture and surface to analysts:
Consider adding: