We present a method and initial results on reverse engineering the architecture of monolithic software systems. Our approach is based on analysis of system binaries resulting in a series of models, which are successively refined into a component structure. Our approach comprises the following steps: 1) instrumentation of existing binaries for dynamically generating execution traces at runtime and connected analysis, 2) static inspection of binaries, 3) interpretation using domain knowledge, and 4) identifying component boundaries using software clustering. We motivate a generic method which covers a large class of software systems, and evaluate our method on concrete software tools for industrial automation systems development, focusing on Intel x86 and Microsoft Windows-compatible applications.
Related Work Published work on architecture reconstruction and related reverse
engineering tasks focussing on derivation of component candidates and inter-dependencies
is covered in existing surveys and overview papers [
Our method for collecting runtime based architecture information has these steps:1) We instrument an existing tool such that dynamically loaded libraries and control flow events are tracked and collated as execution traces. These traces contain information (e.g. available methods) for dynamically loaded libraries, as well as the order of method calls. Instrumentation is done on a binary level. 2) The instrumented tool is run and execution traces are generated. A user interacts with the tool (e.g. editing, simulating, compiling). All dynamically loaded libraries and method calls (traced by memory address) and time of invocation are traced. The generated execution traces are further processed and abstracted. This involves the resolution of traced memory addresses to primitives such as methods, objects or executables. Calls between methods denote a graph. Here, each primitive corresponds to a node and the number of distinct caller/callee combinations in the execution trace is annoted as a weight on a directed edge. We cluster primitives into candidate components using the LIMBO algorithm (see below). This gives first candidates for a component architecture. Final clustering is based on interactions between methods, existing dll structure, analysis of names and knowledge about reference architectures. 3) The generated data is interpreted by using information from binaries and the domain, to derive information about the underlying architecture of the tool. Manual binary inspection and domain knowledge are used to complete reconstruction.Several tasks are carried out for the runtime-based analysis part of our method: Usage Scenarios for Runtime Based Evaluation We evaluate our tools with the help of usage scenarios. These are sequences of user interactions with tools. The component interactions are then extracted from the generated execution trace in order to gain hints on architectural details. The idea is to invoke the distinct components of a tool by user interaction. For example a user may trigger a compilation at a certain time and the execution trace may show the loading of distinct libraries and the invocation of the desired methods. We can also compare interaction sequences in order to see if different tools have a similar way of interacting e.g. with a compilation component. Evaluating Execution Traces, Clustering and Component Candidate Identification We aim to generate a graphical view showing a few high-level components and their interactions. In Windows and similar environments components are most often associated with distinct executables and libraries (or possibly packages), and their inter-dependencies (associated with dynamic linking, import or transfer of control between their respective methods). However a high-level view at such a level is often inappropriate because the view has either too many or too few executables. We therefore tried to identify high level component candidates by clustering groups of other programming languagespecific notions such as classes/object or method. We will use the term primitives to refer to low-level component categories selected for clustering.
Software clustering is a long-standing and commonly used method for imposing abstract, high level structure on an over-detailed view of primitives and their relationships. For software, a set of low-level components is typically clustered on the basis of properties such as which other components they call, authorship, or location in source directories. As shown, clustering may be thought of as partitioning a collection of objects based on the similarity of their properties. Typically clustering is based on static analysis, here, we are using clustering based on the dynamic call structure between primitives observed at runtime.
Figures 1 (a) and (b) depict the clustering for a usage scenario in the open source
tool PLCEdit [
We use the LIMBO clustering algorithm [
16 (0) : QBtSyntax, : QBtBrowser, : QBtSeparator, : NVT QBtBrowser, : QBtSet ings, : QBtWorkspace, : QBtConfig, : QBtOperator, : QBtNumeration, : QVector<QBtRange>, 2 (0) : QBtShared, : QVector<QBtMarkerInfo>, : QBtEvent, : NVT QBtIndicator, : Dif Dialog, : QVector<QBtDif Info>, : QBtEventsControl er, : QBtDif Proces , : NVT QBtWorkspace, : BtStringTo l, : QBtDif Info, : QBtIndicator, : NVT QBtOperator 2 (0) 10 (2) 40 (12) 326 (0) 20 (0) 6 (4)
1 (0) : QBtSeparator, : NVT QBtBrowser, : QBtSet ings, : QBtWorkspace, : QBtConfig, : QBtOperator, : QBtNumeration, : QVector<QBtRange>, : QBtShared, : QVector<QBtMarkerInfo>, : QBtEvent, : NVT QBtIndicator, : Dif Dialog, : QVector<QBtDif Info>, : QBtEventsControl er, : QBtDif Proces , : NVT QBtWorkspace, : BtStringTool, : QBtDif Info, : QBtIndicator, : NVT QBtOperator 20 (7) : NVT FindDialog, : Ui_HelpWidget, : NVT BatchDialog, : Ui_FncDialog, : NVT UpdateInfo, : Ui_BatchDialog, : Ui_Ses ionDialog, : Ui_FindReplaceDialog, : Ui_FBDialog, : NVT HelpWidget, : NVT FncDialog, : Ui_POUInfoDialog, : NVT FBDialog, : NVT POUInfoDialog, : NVT Ses ionManager, : Ui_UpdateDialog 3 (0) attributes by interpreting the primitive call about graph as directed or undirected—That is, whether two primitives which call each other have the same value in both directions (sum of the number of ways they can call each other) or possibly-distinct values. In our work the call graph is interpreted as undirected.
objects closest
and Domain
Binaries like .dll files can encapsulate multiple components and provide hints on development history. Names and size of components can indicate usage. Binaries can contain method names and plain that hint on component functionality. A major source of knowledge in our reverse text engineering method is the PLC development domain. For example we know what types of components to expect.
We started with the following expected components: Source and target code storage manage the modeling, storage and exchange of source and target specification models and code by using a file system or a database. Compilers,
specification models and perform operations on them, like generating target code, interacting with a
GUI component behaviour or properties.
Editors manage the editing of models in by order to
visualize the user.
Management and other miscellaneous functionality can be realized as a separate component e.g. that may interact with a third party license server. The GUI provides a user interface. It does not have to be realized as a separate component inside the tool, since existing GUI frameworks can be used. 3
Instrumentation of binaries is done by using the Intel Pin tool [
Case Study Tools We have used our method for analysing the architecture of a mix of
proprietary and open source tools. Tools are designed for performing at least some of
the following operations for the development of PLC software: 1) Editing PLC
specification models, 2) Saving and loading of PLC specification models, 3) Analysing and
compiling PLC specification models, 4) Simulating PLC specification models. We
initially expected that this functionality is provided by distinct software components as
described in the previous section. Open source systems considered included PLCEdit [
Evaluation and Improvements The method was applied to different PLC development tools. Execution of the usage scenarios was done manually, while the processing of the execution traces was done automatically to generate models – one single model for each usage scenario and number of desired components – comprising component candidates and their interactions. Clustering based on dynamically linked libraries and executables did not always provide the right granularity, since several major components are typically encapsulated in a main executable. Determining the begin and end of entities like methods or classes in the binaries as a basis for clustering was sometimes possible. In some cases e.g. due to the use of different programming languages, additional information on the location of entities for the basis of clustering was provided by the tool developers and used by us. For example for some applications while symbol table information is not available in the executable, a “.map” file provides similar information for debugging purposes. There are a number of possible reasons why a clustering may not reflect a system’s true architecture, for example there may be insufficient data in the run time call graph, or architectural anti-patterns may be present. It may be desirable to associate each component with a meaningful name or feature. As discussed in clustering literature, this depends on understanding what abstractions (e.g. aspects) are semantically common to all objects of a component, or the principle abstraction of the component, which can be difficult. Currently all attributes are structural, derived from the Pin call graph, however the graph is created by exercising tools using just a few use case scenarios. There is scope to assign so-called non structural attributes, that is, properties other than call relationships on which clustering could be based, possibly based on manual assessment and with input from domain experts. These could pertain to specific features or aspects such as GUI or safety. For example if several objects are clearly GUI components, an additional GUI attribute could be assigned to those objects and taken into account during clustering. There are existing aspect mining approaches in the literature which may be applicable or adaptable to this purpose.
The LIMBO algorithm was implemented by us in few hundred lines of Python. This is supported by additional scripts which process output from our pin plugin.