The Ultimate Path to Absolute Digital Security

Code Translator Software

The code translator will be defined as a compiler, interpreter or any entity that generates computer instructions. The code translator implements a set of abstract rules through granular operations that convert code to machine or intermediate instructions. These granular operations can be extended for the sole purpose of reporting on activities based on a different set of rules. The set of rules would be aimed at producing a report of code activities instead of computer instructions. These activities must constitute a scope that completely embodies what is possible for all malicious digital operations. The activities will be defined as system resources engaged through code. The translator would take adavantage of a capacity to detect operating system calls that engage hardware, memory and file system resources. The set of rules for such detection will be explained in another section. This section is dedicated to activities of the code translator related to those rules.

A code translator is the point of origin that can detect activities related to code and data. We defined code as a resource that contains any type of computer instructions. We must take an effective approach in clarifying our expectations of this resource. A wrong approach can lead to inadequate protection or overprotection that incorrectly identifies useful code as malicious. Rather than quantify the characteristics of harmless code, we should pinpoint or detect all software operations that can be harmful. This detection should occur at a certain stage of software creation. Only the compiler, interpreter and similar code processors are appropriate for this responsibility. Every software operation originates from code that must be processed by a translator. The translator is fully aware of code details. We can exploit this fact to generate a report of system resources engaged by the code.

Code Translator Software

All malicious code operations do not go beyond engaging file or other system resources. The translator should generate a Secure Engaged System Resources (SESR, pronounced Say-Zar) report. The details of this report and how it should be generated by a translator will be provided later. We will also explain how malicious engagement of system resources can be distinguished. The report would state all reading, writing, creation and updates related to system resource engagements. A software interface (like APSCCS) should encrypt this report to produce a SESR signature and security key. These pieces of data would be unique to each report. The report should also include features that can protect it from piracy. Therefore, safe code begins with including a SESR report. We will later elaborate on how this condition can be established.

The creation of a SESR report can be seemlesly coherent with default operations of a code translator. This goal can be achieved in two stages that culminate in a report. The first stage involves saving data related to a normal translation process. This stage reflects the primary goal of a translator to generate instructions. The saved elements would be separated as system calls, memory locations (or references) and devices. The translator would retrieve such data specific to an operating system and CPU. These three elements would be retireved at the instance they can be correctly identified. The translator may also create a header that contains information specific to a programming language (such as entry points and function access levels). The three elements would be linked to this header. This saved information provides raw material for the next stage. The software that hosts a code translator should cater to stage two.

Code Translator Software

A SESR report should be generated by the parent software of a code translator. This software is a user interface, command-line interface or browser that hosts the code translator. The translator activity that leads to a SESR report occurs when an option is set through this interface. A report would be generated when created code is tested for execution. Any software that allows embedded code in data should integrate with a SESR report generator or implement one internally. A report belonging to embedded code would be checked before reading the associated data. A report for compiled, intermediate or interpreted code would have been ready before reaching the deployment target. The SESR report can then be checked at an intermediate stage before placing software in a stable location. The Operating System section provides details.

A SESR report includes a unique signature created through reliable encryption. This form of encryption does not involve public or private keys. An operating system would provide the report generator access to a security provider. This access occurs through a secure system call (SSC). A security provider (e.g. APSCCS) applies the OS as a common execution environment for encryption and decryption without a need for potentially vulnerable keys. Furthermore, an OS vendor can select a list of acceptable report generators through the SSC protocol. This implies that only specific code translators would be permissible. The Operating System section provides details of this SSC protocol.

Code Translator Software

The SESR report defines a set of status flags to represent a security outline for any software. These flags belong to two software categories stated as either Vulnerable or Intrusive. The criteria for vulnerability are elements that expose a program to intrusion by another program. The vulnerable program may fail to either prevent unauthorized access or secure authorized access. The criteria for intrusion are elements that allow a program to breach another program. The intrusive program may attempt direct unauthorized access, attempt indirect unauthorized access, or simulate authorized access. The flags for vulnerable software are classified as Primary Status and Security Status. A Primary Status indicates the state of a program. An example of program state would be Accepts data from external programs. A Security Status indicates that a corresponding program state is secure. The flags for intrusive software are classified as Primary Status, Security Check and Security Status. The first and third flags are similar to those defined for vulnerable software. A Security Check confirms a program to be malicious. The SESR Report section provides further details.

A code translator parent would implement the second stage of report generation by retrieving saved data to evaluate status flags. An example for the status flag Accepts data from external programs follows. The header file would be read to identify elements relevant to external program access. The Primary Status would be established as false at this point if no indicators for external access are found. Otherwise, a further check would be necessary for input parameters that exist in form of memory references to either data or file paths. A check for the Security Status of this state would verify that memory boundaries are established. Any set of input parameters that involve a data structure must include a size. Any file that is read must be accomodated within a memory boundary defined by the translated program. These checks are both granular and composite. They can be fully served by data saved during the first stage. The SESR Report section states each check that should occur for status flags.

Code Translator Software

Finally, the translator should mark an input resource as Code after compilation, interpretation or other operation that produces instructions on a source device. This should occur by creating a file to be read during installation (or placement of the code resource in a stable location). The SESR report can promote an opportunity to define a universal standard for safe code. Any operating system vendor may encourage the extension of status flags in a SESR report. This would require relevant code translators to comply. A trend toward reducing the complexity of granular checks related to status flags may even occur. This would be possible through setting appropriate constraints for acceptable code. The creation of surreptitious code would become discouraging. What is left is to seek attempts at making explicit code malicious. The SESR report would expose any exploit of such code. The build process that determines executable code may even become aligned with criteria in a SESR report.

Summary of Code Translator Software role

Saves specific data during the default operation of a code translator

Stores low-level data related to operating system calls, memory and devices
Creates a header that stores useful data for a programming language

Coordinates data generated by the code translator

Applies saved data to evaluate status flags defined by the SESR report

Creates the SESR report for reading by humans and any software
Creates entities that verify the authenticity of a SESR report

Generates a file that contains the SESR signature
Generates a file that contains the executable signature

Creates a file that identifies the translated resource as code

Previous Next