Reverse engineering of applications

Security experts, DevOps and SRE personnel often find themselves in situations where they are given an application that they do not own but must know enough about it to do their job. Their concerns overlap over the discipline of reverse engineering. It is not enough to know what an application is by doing static analysis whenever possible, but it is also necessary to know what it does at runtime. Observability of an application does not come easily with even sophisticated and learning tools that are now so ubiquitous on-premises and in the cloud. System center agents for public clouds, third-party monitoring tools, on-premises support for telemetry, logging and tracing and cloud-based x-rays of workloads can help with many cases. But they do not adequately cover standalone application-database pairs that are remnants of an age gone by. While arguably every organization can claim to have only a finite number of these applications, more recently container images have proliferated by mutations to the point where organizations might not even bother to make an inventory of all usages.

There are many runtimes analysis tools that are designed to closely monitor the behavior of an application or container image. Companies like Twistlock and Tenable.IO have opened new ways of investigating them for the purposes of vulnerability assessment.  Some tools have found a way to allow source code insertion to instrument the source code providing dynamic analysis of the application while it is running either on a native or an embedded target platform. Tools also vary by purpose. For example, code coverage tools perform code coverage analysis. Memory profilers analyze memory usage and detect memory leaks. Performance profiling provides performance load monitoring. Runtime tracing draws a real-time UML sequence diagram of the application. Tools can also be used alone or together. When the source code is run with any of the runtime analysis tools engaged, the resulting instrumented code is then executed, and the result is dynamically displayed in the corresponding reports.

Among these runtime tracing is perhaps the most comprehensive way of observing real-time dynamic interaction analysis of the source code by generating trace data, which can then be used to create UML Diagrams.

Model driven Software discovery evolves existing systems and facilitates the creation of new software systems. 

The salient features of model driven software discovery include: 

1.       Domain-specific languages (DSLs) that express models at different abstraction levels. 

2.       DSL notation syntaxes that are collected separately 

3.       Model transformations for generating code from models either directly by model-to-text transformations or indirectly by intermediate model-to-model transformations. 

An abstract syntax is defined by a metamodel that uses a metamodeling language to describe a set of concepts and their relationships. These languages use object-oriented constructs to build metamodels. The relationship between a model and a metamodel can be described by a “conforms-to” relationship. 

KDM helps to represent semantic information about a software system, ranging from source code to higher level of abstractions. KDM is the language of architecture and provides a common interchange format intended for representing software assets and tools interoperability. Platform, user interface or data can each have its own KDM and are organized as packages. These packages are grouped into four abstract layers to improve modularity and separation of concerns: infrastructure, program elements, runtime resources and abstractions.  SMM is the metamodel that can represent both metrics and measurements. It includes a set of elements to describe the metrics in KDM models and their measurements. 

These are some of the ways reverse engineering is evolving fueled by the requirements called out.