Search NASA⌕ Search

SEARCH · Search NASA

Results for “security vulnerabilities”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2017

Security Vulnerability Profiles of NASA Mission Software: Empirical Analysis of Security Related Bug Reports

NASA develops, runs, and maintains software systems for which security is of vital importance. Therefore, it is becoming an imperative to develop secure systems and extend the current software assurance capabilities to cover information assurance and cybersecurity concerns of NASA missions. The results presented in this report are based on the information provided in the issue tracking systems of one ground mission and one flight mission. The extracted data were used to create three datasets: Ground mission IVV issues, Flight mission IVV issues, and Flight mission Developers issues. In each dataset, we identified the software bugs that are security related and classified them in specific security classes. This information was then used to create the security vulnerability profiles (i.e., to determine how, why, where, and when the security vulnerabilities were introduced) and explore the existence of common trends. The main findings of our work include:- Code related security issues dominated both the Ground and Flight mission IVV security issues, with 95 and 92, respectively. Therefore, enforcing secure coding practices and verification and validation focused on coding errors would be cost effective ways to improve mission's security. (Flight mission Developers issues dataset did not contain data in the Issue Category.)- In both the Ground and Flight mission IVV issues datasets, the majority of security issues (i.e., 91 and 85, respectively) were introduced in the Implementation phase. In most cases, the phase in which the issues were found was the same as the phase in which they were introduced. The most security related issues of the Flight mission Developers issues dataset were found during Code Implementation, Build Integration, and Build Verification; the data on the phase in which these issues were introduced were not available for this dataset.- The location of security related issues, as the location of software issues in general, followed the Pareto principle. Specifically, for all three datasets, from 86 to 88 the security related issues were located in two to four subsystems.- The severity levels of most security issues were moderate, in all three datasets.- Out of 21 primary security classes, five dominated: Exception Management, Memory Access, Other, Risky Values, and Unused Entities. Together, these classes contributed from around 80 to 90 of all security issues in each dataset. This again proves the Pareto principle of uneven distribution of security issues, in this case across CWE classes, and supports the fact that addressing these dominant security classes provides the most cost efficient way to improve missions' security. The findings presented in this report uncovered the security vulnerability profiles and identified the common trends and dominant classes of security issues, which in turn can be used to select the most efficient secure design and coding best practices compiled by the part of the SARP project team associated with the NASA's Johnson Space Center. In addition, these findings provide valuable input to the NASA IVV initiative aimed at identification of the two 25 CWEs of ground and flight missions.

vulnerability↗
NASA NTRS2017

Security Vulnerability Profiles of Mission Critical Software: Empirical Analysis of Security Related Bug Reports

While some prior research work exists on characteristics of software faults (i.e., bugs) and failures, very little work has been published on analysis of software applications vulnerabilities. This paper aims to contribute towards filling that gap by presenting an empirical investigation of application vulnerabilities. The results are based on data extracted from issue tracking systems of two NASA missions. These data were organized in three datasets: Ground mission IVV issues, Flight mission IVV issues, and Flight mission Developers issues. In each dataset, we identified security related software bugs and classified them in specific vulnerability classes. Then, we created the security vulnerability profiles, i.e., determined where and when the security vulnerabilities were introduced and what were the dominating vulnerabilities classes. Our main findings include: (1) In IVV issues datasets the majority of vulnerabilities were code related and were introduced in the Implementation phase. (2) For all datasets, around 90 of the vulnerabilities were located in two to four subsystems. (3) Out of 21 primary classes, five dominated: Exception Management, Memory Access, Other, Risky Values, and Unused Entities. Together, they contributed from 80 to 90 of vulnerabilities in each dataset.

Goseva-Popstojanova, Katerina↗
NASA NTRS2018

Ground Software Technologies – Embracing Change: Mission Drivers and Technology Opportunities to Enable Long Lived Missions

Mission lifecycles have proven to extend well beyond their original design. The benefits to this are countless but introduce challenges in today’s rapidly changing ground infrastructure and software technologies used to enable mission success. What remains constant is the risk posture missions maintain when accepting change and the use of new technologies. Larger missions are ready for change in early lifecycle development but near launch and especially in operations, few continue to evolve beyond what is set in place in phase C. This paper will discuss how the Advance Multi-Mission Operations System (AMMOS) intends to address, three driving missions concerns: Maintaining functionality (hardware/software) for decades, rapidly responding to security vulnerabilities in software, and finally the ability to quickly evolve infrastructure and software changes. These driving concerns are briefly described below: 1. Maintaining functionality (hardware/software) for decades. Hardware updates considerably faster than 10 years ago. Expectations that a system can remain in place for more than 10 years is no longer valid. Expecting to find hardware replacements for a system older than 5 years will increasingly become more and more challenging. How than do missions plan for hardware changes for long lived missions? Principle Objective: Provide abstraction by virtualizing and containerizing software abstract away any hardware dependencies and package up the application lightweight units. 2. Rapidly responding to security vulnerabilities in software. Cost is often the main impediment and largely driven by the revalidation and testing of system that undergo change. In todays, environment security updates are a major diver demanding systems remain up to date. How then do missions accept these changes and avoid large testing efforts? Principle Objective: Help reduce the cost of re-testing by automation of testing, deployment, and compartmentalizing change. 3. Ability to quickly evolve infrastructure and software changes. Responding quickly to change is similar to the second concern in this paper regarding security vulnerabilities. In this case, it address broader concerns of updating software and infrastructure on a more realistic timeline. How do missions stay up to date with the most recent versions of software and allowing for improved functionality? Principle Objective: Use continuous integration techniques at the system level to ensure rapid turnaround. This paper explores each of these concerns in more detail. It focuses the AMMOS’s current plans, challenges and current roadmap.

Giovannoni, Brian J.↗
DOE OSTI2026

Blueprint: Stakeholder-Specific Vulnerability Categorization Guidance

Vulnerability management is a process of discovering, analyzing, and handling new or reported security vulnerabilities in systems to prevent the systems from being exploited, to reduce risk, and to protect assets. For vulnerability analysis, handling, and response, the prioritization of organizational and analyst resources must precede. The Common Vulnerability Scoring System (CVSS) is a standard prioritization method that is used to rate the severity of security vulnerabilities in systems by assigning numerical severity scores, but it does not provide clear guidelines of how the numerical severity scores might inform decisions. The Stakeholder-Specific Vulnerability Categorization (SSVC) provides a method for prioritizing vulnerabilities based on the needs of the stakeholders involved in the vulnerability management process. Instead of the numerical scoring used in the CVSS, the SSVC focuses on contextual decision-making to determine how quickly and effectively an organization should respond to vulnerabilities. The main functionality of the SSVC accommodates the diversity of the stakeholders in the vulnerability management process, including finders, vendors, coordinators, deployers, and others. So, the SSVC should be designed to be used by any of these stakeholders, and it should be customizable to enable specific stakeholder decision models and risk appetites.

33 ADVANCED PROPULSION SYSTEMS↗
NASA NTRS2016

Empirical Analysis and Automated Classification of Security Bug Reports

With the ever expanding amount of sensitive data being placed into computer systems, the need for effective cybersecurity is of utmost importance. However, there is a shortage of detailed empirical studies of security vulnerabilities from which cybersecurity metrics and best practices could be determined. This thesis has two main research goals: (1) to explore the distribution and characteristics of security vulnerabilities based on the information provided in bug tracking systems and (2) to develop data analytics approaches for automatic classification of bug reports as security or non-security related. This work is based on using three NASA datasets as case studies. The empirical analysis showed that the majority of software vulnerabilities belong only to a small number of types. Addressing these types of vulnerabilities will consequently lead to cost efficient improvement of software security. Since this analysis requires labeling of each bug report in the bug tracking system, we explored using machine learning to automate the classification of each bug report as a security or non-security related (two-class classification), as well as each security related bug report as specific security type (multiclass classification). In addition to using supervised machine learning algorithms, a novel unsupervised machine learning approach is proposed. An ac- curacy of 92%, recall of 96%, precision of 92%, probability of false alarm of 4%, F-Score of 81% and G-Score of 90% were the best results achieved during two-class classification. Furthermore, an accuracy of 80%, recall of 80%, precision of 94%, and F-score of 85% were the best results achieved during multiclass classification.

Cybersecurity↗
DOE OSTI2024

Hardware Fuzzing with An Emulator

Bugs in digital logic have led to some significant security vulnerabilities. Hardware bugs are particularly troublesome since they cannot be easily patched. Additionally, if the bug is in the root of trust, all trust built upon it can be vulnerable. Traditional testing either require a deep knowledge of the system, creative attack vectors and lots of human interaction. This is not scalable as there are very few engineers that can wear the hat of a designer, a verification engineer, and a cybersecurity expert. Hardware fuzzing is a relatively new research area in dynamic hardware testing. It has proven to be an effective method for discovering bugs, unexpected behaviors, and security vulnerabilities in software. While hardware fuzzing is new to the hardware domain, it has a strong track record in software testing. Fuzzing is a testing technique that randomly mutates the input data to uncover bugs or vulnerabilities in the design. It is especially good at finding corner cases that test engineers can not envision. Another advantage over other dynamic testing techniques is that, if done well, deep knowledge of the design is not required. Additionally, fuzzing scales well. If the system is set up correctly, it can run unsupervised for weeks if necessary. In this work, we propose using hardware fuzzing to improve the input vector generation for an information flow tracking tool. To get reasonable throughput of test vectors, an emulator is targeted as the execution platform. Efficient emulator execution has some specific requirements.

42 ENGINEERING↗
DOE OSTI2023

MARVEL 90% Final Design Report

This document provides documentation of the Microreactor Applications Research Validation and Evaluation Project’s (MARVEL) 90% Final Design, as required by U.S. Department of Energy (DOE) Standard-1189, “Integration of Safety into the Design Process." Per DOE-STD-1189-2016, the 90% Final Design documentation focuses on design completion, at a level capable of supporting procurement, construction, testing, and operation. At this phase, the design organization finalizes the hazards and accident analyses, Fire Hazard Analysis (FHA), security vulnerability assessments, and other supporting analyses for design completion. The objective of this report is to provide a high-level summary of the design thus far and provide references including, but not limited to, the following design deliverables: • Complete final drawings, specifications and commercial grade dedications that may be released for bid and/or construction. • Clearly defined testing plans for the safety and functionality of all subsystems. • Quality Assurance Program for Design, Testing and Procurement. • Software Quality Assurance Plan. • Code of Record (COR), applicable design requirements including codes and standards. • Final design that meets all the requirements stipulated in the COR. • Final design review, consisting of final validation of comment resolution from previous reviews, and a review of any additional developments since the last review. • Updated Safety Design Strategy. • Hazard Analysis. • Fire Hazard Analysis. • Accident analysis. • Security vulnerability assessment. • Current and detailed cost estimate. • Current construction schedule, and • Risk & Opportunities Assessment.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗
DOE OSTI2026

Assessing Energy Infrastructure Devices for Vulnerabilities

Industrial control systems prove to be vital to the health and security of the nation in our critical infrastructure. Critical infrastructure includes the most foundational systems to support modern civilization which includes water and wastewater systems, communications, and the electricity we use to name a few sectors. However, these devices' overall composition remains largely unknown and are untested from a cyber security perspective. As part of the Cyber Testing for Resilient Industrial Control Systems (CyTRICS) program, I analyzed one such energy infrastructure device to better understand how it functions, what hardware and software components are present within it, and assess it for security vulnerabilities. To achieve this, I reverse engineered binary files using Ghidra to understand system functionality and learned more about how to collaborate with other researchers on a shared Ghidra project. I learned more about how web sockets function and how to interact with them through Python to test if they are secure or not. This work led me to assess possible vulnerabilities in this device and provide a better understanding of its composition and function, which are essential to INL's mission of securing our nation's energy infrastructure.

99 - GENERAL AND MISCELLANEOUS↗
DOE OSTI2024

CAST Technical Bulletin #004: Network Time Protocol Introduction

Network Time Protocol (NTP), as it traditionally generated and widely consumed, is a legacy system with known security vulnerabilities. The vulnerabilities can be mitigated by modern implementations of NTP that use internal and external redundancy for better accuracy and fault tolerance. Precision Time Protocol (PTP) is an alternative that uses master clocks inside secure networks to eliminate the known vulnerabilities of NTP.

24 POWER TRANSMISSION AND DISTRIBUTION↗
DOE OSTI2025

Entropy of the Quantum–Classical Interface: A Potential Metric for Security

Hybrid quantum–classical systems are emerging as key platforms in quantum computing, sensing, and communication technologies, but the quantum–classical interface (QCI)—the boundary enabling these systems—introduces unique and largely unexplored security vulnerabilities. This position paper proposes using entropy-based metrics to monitor and enhance security, specifically at the QCI. We present a theoretical security outline that leverages well-established information-theoretic entropy measures, such as Shannon entropy, von Neumann entropy, and quantum relative entropy, to detect anomalous behaviors and potential breaches at the QCI. By linking entropy fluctuations to scenarios of practical relevance—including quantum key distribution, quantum sensing, and hybrid control systems—we promote the potential value and applicability of entropy-based security monitoring. While explicitly acknowledging practical limitations and theoretical assumptions, we argue that entropy-based metrics provide a complementary approach to existing security methods, inviting further empirical studies and theoretical refinements that can strengthen future quantum technologies.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

Motivation and Design of the OCPP Security Service

Pacific Northwest National Laboratory is conducting in-depth research aimed at exploring how zero trust security principles can be effectively applied to electric vehicle charging infrastructure. This investigation seeks to enhance the resilience and reliability of these systems against cyber threats, ensuring secure and uninterrupted access to charging services for electric vehicle users and electric supply. Zero trust is a security concept centered on the belief that system operators should not automatically trust users or systems based on their location, whether inside or outside the organization, but instead must verify everything trying to connect to their systems before granting access. A key aspect of the project is to demonstrate and validate zero trust approaches targeted to electric vehicle (EV) charging infrastructure. It has been observed that both open-source and commercial solutions often overlook the specific protocols employed in managing EV charging stations and proceeded with a general, protocol-agnostic approach. While these strategies effectively block non-authorized routes to the charging infrastructure, they do not tackle the situations where attackers may exploit legitimate access channels, such as the inattentive operator model posited by the Idaho National Laboratory. To address this gap, this paper proposes and discusses a new security service targeted to the Open Charge Point Protocol (OCPP), which is the de facto protocol for the management of charging stations and serves a critical role in the broader adoption of electric vehicles. The design and architecture of the proposed OCPP security service are discussed in detail, outlining how it aims to safeguard charging station management system (CSMS) functions. The service is particularly important in scenarios where the charging station operator (CSO), responsible for the maintenance and operation of charging stations, and the charging network provider (CNP), which manages the charging network's accessibility and billing, are separate entities. This distinction is crucial because CSOs and CNPs often have different priorities, objectives, and operational responsibilities, which may not always align perfectly. For instance, a CSO might prioritize uptime and customer satisfaction, while a CNP might focus on maximizing revenue and network utilization. Such misalignment can create security vulnerabilities, as each entity might implement different policies and standards, potentially leaving gaps in the overall security posture.

33 ADVANCED PROPULSION SYSTEMS↗
DOE OSTI2025

FL‐ADS: Federated learning anomaly detection system for distributed energy resource networks

Abstract With the ongoing development of Distributed Energy Resources (DER) communication networks, the imperative for strong cybersecurity and data privacy safeguards is increasingly evident. DER networks, which rely on protocols such as Distributed Network Protocol 3 and Modbus, are susceptible to cyberattacks such as data integrity breaches and denial of service due to their inherent security vulnerabilities. This paper introduces an innovative Federated Learning (FL)‐based anomaly detection system designed to enhance the security of DER networks while preserving data privacy. Our models leverage Vertical and Horizontal Federated Learning to enable collaborative learning while preserving data privacy, exchanging only non‐sensitive information, such as model parameters, and maintaining the privacy of DER clients' raw data. The effectiveness of the models is demonstrated through its evaluation on datasets representative of real‐world DER scenarios, showcasing significant improvements in accuracy and F1‐score across all clients compared to the traditional baseline model. Additionally, this work demonstrates a consistent reduction in loss function over multiple FL rounds, further validating its efficacy and offering a robust solution that balances effective anomaly detection with stringent data privacy needs.

Purohit, Shaurya [Iowa State University Ames Iowa ↗
NASA NTRS2014

Scalable Asset Discovery, Vulnerability Scanning, and Penetration Testing for Remote Sites and Wireless Spectrums Utilizing an Embedded Linux Plug - PwniPlug and the Raspberry Pi B+ as a Sample Pen Test

All devices attached to the NASA KSC network are subject to security vulnerability scanning and/or penetration testing. In today's changing environment, vulnerable and/or unprotected systems can easily be overlooked. Systems that are not properly managed can become a potential threat to the operational integrity of our systems and networks. This includes all NASA (internal and external) information systems within NASA KSC Internet Protocol (IP) address space, and NASA KSC facilities. The Office of the Chief Information Officer (OCIO) recommends that all NASA Centers and information systems be subject to penetration testing on a regular interval in accordance with the guidelines identified by the National Institute of Standards and Technology (NIST). (ITS-HBK-2810.04-02A) Protecting information and equipment at NASA is an area of increasing concern. In addition to the CPU's on the network; Supervisory, Control and Data Acquisition (SCADA) systems are especially vulnerable because these systems have lacked standards, use embedded controllers with little computational power and informal software, are connected to physical processes, have few operators, and are increasingly also being connected to corporate networks. The scope of work is comprised of several individual components which together build upon previous work by Drew Branch, NASA KSC Intern. The Pwn Plug is the selected COTS (Commercial-Off-The-Shelf) device chosen to test simplification of mandatory IT Security tasks. The device will be utilized to provide services to NASA KSC and enable an assessment of infrastructure soundness and regulatory compliance in an efficient, economical, and business responsive manner. The Pwn Plug is designed as a pen testing appliance which provides a hardware platform that can support commercial penetration testing efforts at significantly reduced costs. The expected outcomes are: 1) External Penetration Testing, 2) Social Engineering, 3) Procedural Documentation, 4) Recommended Remediation Action Plan, 5) System Retest & Remediation Attestation and 6) Final Reports, out briefing and Presentation. Due to physical and material constraints beyond intern and mentor control, the project was redefined as a working pen-test scenario. Limitations of lab availability and tools dictated an academic exercise. This report was developed within the scenario guidelines suggested by the project mentor. The guidelines were to be creative in developing a Pen Test program for a client.

Penetration Testing↗
DOE OSTI2024

A Four-Layer Cyber-Physical Security Model for Electric Machine Drives Considering Control Information Flow

Despite the IEEE Power Electronics Society (PELS) establishing Technical Committee 10 on Design Methodologies with a focus on the cyber-physical security of power electronics systems, a holistic design methodology for addressing security vulnerabilities remains underdeveloped. This gap largely stems from the limited integration of computer science and power/control engineering studies in this interdisciplinary field. Addressing the inadequacy of unilateral cyber or control perspectives, this article presents a novel four-layer cyber-physical security model specifically designed for electric machine drives. Central to this model is the innovative control information flow (CIF) model, residing within the control layer, which serves as a pivotal link between the cyber layer's vulnerable resources and the physical layer's state-space models. By mapping vulnerable resources to control variable space and tracing attack propagation, the CIF model facilitates accurate impact predictions based on tainted control laws. The effectiveness and validity of this proposed model are demonstrated through hardware experiments involving two typical cyber-attack scenarios, underscoring its potential as a comprehensive framework for multidisciplinary security strategies.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2004

Toward Synthesis, Analysis, and Certification of Security Protocols

Implemented security protocols are basically pieces of software which are used to (a) authenticate the other communication partners, (b) establish a secure communication channel between them (using insecure communication media), and (c) transfer data between the communication partners in such a way that these data only available to the desired receiver, but not to anyone else. Such an implementation usually consists of the following components: the protocol-engine, which controls in which sequence the messages of the protocol are sent over the network, and which controls the assembly/disassembly and processing (e.g., decryption) of the data. the cryptographic routines to actually encrypt or decrypt the data (using given keys), and t,he interface to the operating system and to the application. For a correct working of such a security protocol, all of these components must work flawlessly. Many formal-methods based techniques for the analysis of a security protocols have been developed. They range from using specific logics (e.g.: BAN-logic [4], or higher order logics [12] to model checking [2] approaches. In each approach, the analysis tries to prove that no (or at least not a modeled intruder) can get access to secret data. Otherwise, a scenario illustrating the &tack may be produced. Despite the seeming simplicity of security protocols ("only" a few messages are sent between the protocol partners in order to ensure a secure communication), many flaws have been detected. Unfortunately, even a perfect protocol engine does not guarantee flawless working of a security protocol, as incidents show. Many break-ins and security vulnerabilities are caused by exploiting errors in the implementation of the protocol engine or the underlying operating system. Attacks using buffer-overflows are a very common class of such attacks. Errors in the implementation of exception or error handling can open up additional vulnerabilities. For example, on a website with a log-in screen: multiple tries with invalid passwords caused the expected error message (too many retries). but let the user nevertheless pass. Finally, security can be compromised by silly implementation bugs or design decisions. In a commercial VPN software, all calls to the encryption routines were incidentally replaced by stubs, probably during factory testing. The product worked nicely. and the error (an open VPN) would have gone undetected, if a team member had not inspected the low-level traffic out of curiosity. Also, the use secret proprietary encryption routines can backfire, because such algorithms often exhibit weaknesses which can be exploited easily (see e.g., DVD encoding). Summarizing, there is large number of possibilities to make errors which can compromise the security of a protocol. In today s world with short time-to-market and the use of security protocols in open and hostile networks for safety-critical applications (e.g., power or air-traffic control), such slips could lead to catastrophic situations. Thus, formal methods and automatic reasoning techniques should not be used just for the formal proof of absence of an attack, but they ought to be used to provide an end-to-end tool-supported framework for security software. With such an approach all required artifacts (code, documentation, test cases) , formal analyses, and reliable certification will be generated automatically, given a single, high level specification. By a combination of program synthesis, formal protocol analysis, certification; and proof-carrying code, this goal is within practical reach, since all the important technologies for such an approach actually exist and only need to be assembled in the right way.

Schumann, Johann↗
NASA NTRS2004

Using software security analysis to verify the secure socket layer (SSL) protocol

nal Aeronautics and Space Administration (NASA) have tens of thousands of networked computer systems and applications. Software Security vulnerabilities present risks such as lost or corrupted data, information the3, and unavailability of critical systems. These risks represent potentially enormous costs to NASA. The NASA Code Q research initiative 'Reducing Software Security Risk (RSSR) Trough an Integrated Approach '' offers, among its capabilities, formal verification of software security properties, through the use of model based verification (MBV) to address software security risks. [1,2,3,4,5,6] MBV is a formal approach to software assurance that combines analysis of software, via abstract models, with technology, such as model checkers, that provide automation of the mechanical portions of the analysis process. This paper will discuss: The need for formal analysis to assure software systems with respect to software and why testing alone cannot provide it. The means by which MBV with a Flexible Modeling Framework (FMF) accomplishes the necessary analysis task. An example of FMF style MBV in the verification of properties over the Secure Socket Layer (SSL) communication protocol as a demonstration.

software↗
NASA NTRS2004

Model based verification of the Secure Socket Layer (SSL) Protocol for NASA systems

The National Aeronautics and Space Administration (NASA) has tens of thousands of networked computer systems and applications. Software Security vulnerabilities present risks such as lost or corrupted data, information theft, and unavailability of critical systems. These risks represent potentially enormous costs to NASA. The NASA Code Q research initiative 'Reducing Software Security Risk (RSSR) Trough an Integrated Approach' offers formal verification of information technology (IT), through the creation of a Software Security Assessment Instrument (SSAI), to address software security risks.

software security↗
DOE OSTI2024

Forensic Analysis of SOHO Router Binaries

Small Office/Home Office (SOHO) routers are used by millions of consumers across the United States, and are commensurately vulnerable. Forensic analysis of SOHO router firmware helps to understand and mitigate those vulnerabilities. This poster focused particularly on analysis of BusyBox executables, a software suite that provides several Unix utilities in a single file. Three main tools were used to analyze the binaries. BinWalk was used to extract the files, but also to build entropy graphs, extract Linux kernel images, and identify CPU architectures; WiiBin processed the binaries to find endianness, architecture, the percent compressed/encrypted, and compiler data; and @DisCo, a machine learning tool used to determine function similarity in disassembled binaries, analyzed similarities and determined versions of extracted BusyBox files from each router. These tools found that venders from all five routers utilized the same version of the BusyBox software across different firmware updates, demonstrating the importance of constant firmware scrutiny to protect against security vulnerabilities.

24 POWER TRANSMISSION AND DISTRIBUTION↗