Background  
General-purpose computers execute software to simulate the finite state machine (FSM) defined by the specification of the program. Software thus attempts to constrain execution to a set of intended, authorized/secure states and transitions. However, due to programming errors, faults, incomplete/incorrect specifications, there are also sets of unintended and unauthorized/insecure states present, some of which are reachable by presenting unexpected inputs to the software. The functionality achieved through the use of these unintended states is known as a weird machine, and the unexpected input sequences necessary to program the weird machine are known as weird instructions. For inputs connected to physical interfaces, such as sensors or radio frequency (RF) apertures, the weird instructions can take the form of the corresponding stimuli.

What is the objective?  
The goal of this challenge is to enable the field-enhancement of complex software systems by harnessing unintended states and behaviors, a/k/a weird machines. A specific objective within this goal is to define, prototype, and demonstrate a broadly-applicable, systematic, and automated process that end-users can adopt to explore the system’s state space and generate corresponding weird machine specifications. This objective includes the creation of a capability to read these specifications and program them via a high-level language and weird machine compiler.

A second objective is to apply this state space understanding to the process of vulnerability elimination by removing orisolating insecure states, and provide measurable and provable increases insecurity.

‍What problem are we trying to solve?  
Discovery and analysis of unintended software states can be a time-consuming, labor-intensive and ad-hoc process accomplished by specialists who possess a detailed understanding of the underlying processorarchitecture, operating system characteristics, and application software.Finally, modeling and reasoning over even small portions of a complex system’s state space is computationally difficult and currently hard to scale beyond simple examples.

Solving the above problems associated with a systematic,automated and scalable means of discovering, characterizing, and cataloging unintended states in software provides a common foundation for the two stated objectives:
               1. Knowledge of states determined to be secure but unintended can be used to generate one or more weird machine specifications.These specifications may then form the basis for a high-level software development environment targeting the weird machine and thus enabling programmers to enhance the original software in the field. These enhancements could accommodate changes in mission, augment available computing resources in disadvantaged and contested environments, or extend the useful life of unsupported legacy software.
               2. Knowledge of states deemed insecure can be used by the original software developer or host system administrators to make these states unreachable, or eliminate them entirely, thus increasing the overall security of the system. Because these states were identified systematically, the resulting security improvements should be quantifiable, and lead to a higher confidence than is possible with ad-hoc security evaluations such as penetration testing or red teaming.

‍What outcome do we hope to achieve?  
Desired outcomes include:
               1. A broadly-applicable, comprehensive process and toolset for discovering and analyzing the state space of complex software.
               2. The ability to automatically extract weird machine specifications from the state space analysis.
               3. A software development framework that transforms high-level source code into corresponding weird machine instructions using the corresponding weird machine specification.
               4. An ability to measure the cost and key performance indicators (KPI) of weird machines so that trade-offs between repurposing and replacement may be quantified.
               5. The ability to quantify improvements in security made through the elimination or isolation of insecure states.
               6. Broad adoption of these capabilities by those without specialized expertise, made possible by simplifying abstractions, automated tools, and transparent integrations.
               7. New areas of academic research, high quality publications, increased funding.

‍What resources could the lab provide?  
The Air Force Research Laboratory (AFRL) can provide access to subject matter experts, results from prior sponsored efforts (to include unpublished resources), computing resources, datasets and, in some cases, collaboration space. In addition, AFRL can provide insight into Air Force, DoD and other US Government use cases, and will help identify potential customers, make introductions, and assist with technology transition/transfer.

‍What would success look like?  
A fully successful result would be toolsets supporting the following workflows:
               1. Systematic, automated and comprehensive means of identifying and characterizing unintended software states and determining reachability.
               2. Automatic generation of weird machine specification(s) and identification of associate weird instruction set(s).
               3. High-level language support for field programming and execution of weird machines, given their specification and instruction set.
               4. Software security enhancement through elimination/isolation of insecure states, and/or increasing the difficulty of reaching insecure states.
‍
‍What types of solutions would we expect?  
               • Methodologies and integrated toolsets
                              o  Characterize FSM
                              o  Generate weird machine specifications
                              o  Weird machine development tools and compilers
               • Prototype demonstrations
               •  Field tests
               • Productized solutions

‍What's in it for industry?  
               • Opportunity to solve unique Air Force software life-cycle and operational challenges while creating novel products for a new marketspace.
               • Access to follow-on collaborative opportunities(e.g., Small Business Innovative Research (SBIR) or Broad Area Announcements(BAA)).
               • Methodologies and tools to improve security of software product lines.
               • Recognition of novel research contributions,publications, patents.