Browse Prior Art Database

Discovering, verifying and visualizing dependencies between dynamically linked software components for researching build configuration, open source license compliance and security

IP.com Disclosure Number: IPCOM000236114D
Original Publication Date: 2014-Apr-07
Included in the Prior Art Database: 2014-Apr-07
Document File: 4 page(s) / 115K

Publishing Venue

Linux Defenders

Related People

Armijn Hemel: AUTHOR

Abstract

The method in this document describes how these dependencies can be found for binaries that use the ELF format (Executable and Linking Format), which is the binary format used on the Unix(-like) systems mentioned before.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Page 01 of 4

   Discovering, verifying and visualizing dependencies between dynamically linked software components for researching build configuration, open source license compliance and security

Introduction

In modern computer systems programs are frequently composed of various components. Examples are shared libraries on Unix(-like) systems like Solaris, Linux, FreeBSD, QNX and many others, or JAR files for Java.

It is important to be able to discover dependencies between these components for various reasons, like:

1. build configuration errors: by discovering, verifying and possibly visualising dependencies between binary software components it is easier to see if any components were included by accident, or left out of the build process. This is especially important if any components were included into a build process as aprebuilt binary object

2. open source license compliance: combining various components could have an impact on how the software must be distributed.

3. security: by discovering and verifying which dependencies between binary components exist it is easier to discover if functions or methods that are vulnerable in one component are used and called by other components.

The method in this document describes how these dependencies can be found for binaries that use the ELF format (Executable and Linking Format), which is the binary format used on the Unix(-like) systems mentioned before.

Tags

Linux, FreeBSD, *BSD, Unix, QNX, Solaris, ELF, software, software development, dynamic linking, open source license compliance, security, visualization, defect discovery, reverse engineering

Detailed description: ELF dynamic linking

When software components are combined they are said to be linked. A special program called "linker" takes binary objects that have been translated from source code (so called "object files") and links them


Page 02 of 4

and any dependencies together into one final executable. There are two ways a file can be linked with its dependencies:

1. static linking: the code and all its dependencies are used to create one executable. The final executable can be deployed on any system with the right application binary interface to the operating system. If two programs share dependencies then each executable will contain a copy of these executables.

2. dynamic linking: part of the dependencies are not included in the executable but are deployed as "shared libraries" on the system. The final combination step is performed on the system by a program called "dynamic linker" or "runtime linker" as soon as the program is run. This allows sharing of dependencies between programs and reduce storage space as well as the memory footprint for a program.

During build time for each function and variable that is used it is recorded in the executable where it can be found. If it is a local function or variable, then the address of it is recorded. If it is a function or variable that is in a dependency it is recorded as "undefined". This is...