Qualifier Challenge - KPRCA_00033

Original Versions

Known Vulnerabilities

  • CWE-843 - Access of Resource Using Incompatible Type ('Type Confusion')
  • CWEs are listed as indicated by the challenge author.


  • CodeJitsu: 0.43
  • Disekt: 0.0
  • ForAllSecure: 0.0
  • Lekkertech: 0.0
  • TECHx: 0.0
  • Shellphish: 0.0
  • CSDS: 0.0
  • FuzzBOMB: 0.0
  • TrailofBits: 0.0
  • DeepRed: 0.0
  • The maximum score for each challenge in CQE is 4, following the CQE Scoring Document.

Passed consensus evaluation

  • CodeJitsu - CB1
  • CSDS - CB1
  • ForAllSecure - CB1
  • Shellphish - CB1

Proved a POV in reference challenge

Defense against reference POVs

  • CodeJitsu: 100.0% - CB1
  • Shellphish: 100.0% - CB1
  • CSDS: 100.0% - CB1

No submission

  • Eighth Place Team
  • Eleventh Place Team
  • Fifth Place Team - Finalist
  • First Place Team - Finalist
  • Fourth Place Team - Finalist
  • Ninth Place Team
  • Second Place Team - Finalist
  • Seventh Place Team - Finalist
  • Sixth Place Team - Finalist
  • Tenth Place Team
  • Third Place Team - Finalist
  • Thirteenth Place Team
  • Twelfth Place Team

All Submissions

DARPA performer group

Kaprica Security (KPRCA)


This service is an implementation of the LSIMP message parsing, which is used in White Phones. The protocol is very simple, but fast and secure by employing a binary data protocol and obfuscation techniques.

Feature List


  • Secure mode through key'd XOR
  • Out-of-order data transmission for secure messages
  • Guard value for detecting packet corruption
  • Batch process for queued messages


  • Operation Types:
  • QUEUE queues a message
  • PROCESS processes the message queue
  • QUIT closes connection
  • Message Types:
  • HELO initializes the connection
    • version: protocol version
    • secure_mode: flag specifying obfuscated mode
    • ttl: number of valid messages after this message
  • KEYX exchanges the key; only used for secure messages
    • key: variable length key
    • key_len: length of the key
    • option: flag specifying how the key should be used
  • DATA only used for secure messages; should come after KEYX
    • seq: sequence number
    • data: variable length data
    • data_len: length of the data
  • TEXT used for clear text messages
    • msg: variable length text message
    • msg_len: length of the text message

HELO message must come first. Then, following messages up to 'ttl' is parsed. If the number of messages reaches 'ttl', new HELO message needs to be processed. Only one 'mode' can be used for one HELO session.

Option field in the key exchange message defines two modes:

  • prepend/append: In order to make it more 'secure', 4 byte dummy data is either prepended or appended to the original data.
  • inverted/as-is: The key used for secure mode is either (bit-wise) inverted or used as-is.


  • One operation 'packet' may contain multiple messages; Although, it results in one message (last seen).
  • When parsing a message, it updates the message object data, including the message type
  • With a different message type, different offset of the message object is set (with user-controlled data)
  • By making it back to the original type (but not supplying data), manipulation of field is possible

Generic class of vulnerability

Type confusion error

CWE classification

CWE-843: Access of Resource Using Incompatible Type 'Type Confusion'


  • Must figure out how to initiate and interact with the protocol
  • Must realize that modifying the type and data for the internal object is possible
  • Cause a type confusion to overwrite the pointer to a buffer
  • Trigger the bug by making it to process the message

Curated by Lunge Technology, LLC. Questions or comments? Send us email