Technical reports / Department Informatik
- Technische Fakultät (10) (remove)
- Linux Memory Forensics: Dissecting the User Space Process Heap (2017)
- The analysis of memory during a forensic investigation is often an important step to reconstruct events. While prior work in this field has mostly concentrated on information residing in the kernel space (process lists, network connections, and so on) and in particular on the Microsoft Windows operating system, this work focuses on Linux user space processes as they might also contain valuable information for an investigation. Because a lot of process data is located in the heap, this work in the first place concentrates on the analysis of Glibc's heap implementation and on how and where heap related information is stored in the virtual memory of Linux processes that use the Glibc heap implementation. Up to now, the heap was mostly considered a large cohesive memory region from a memory forensics perspective, making it rather hard manual work to identify relevant information inside. We introduce a Python class for the memory analysis framework Rekall that is based on our analysis results and allows access to all chunks contained in the heap and their meta information. Further, based on this class, six plugins have been developed that support an investigator in analyzing user space processes: Four of these plugins provide generic analysis capabilities such as finding information/references within chunks and dumping chunks into separate files for further investigation. These plugins have been used to reverse engineer data structures within the heap for user space processes, while illustrating how such plugins ease the whole analysis process. The remaining two plugins are a result of these user space process analyses and are extracting the command history for the zsh shell and password entry information for the password manager KeePassX.
- CS 2016-06
- Inner Source Definition, Benefits, and Challenges (2016)
- Inner source (IS) is the use of open source software development practices and the establishment of an open source-like culture within organizations. The organization may still develop proprietary software but internally opens up its development. A steady stream of scientific literature and practitioner reports indicates the interest in this research area. However, the research area lacks a systematic assessment of known research work: No model exists that defines IS thoroughly. Various case studies provide insights into IS programs in the context of specific organizations but only few publications apply a broader perspective. To resolve this, we performed an extensive literature survey and analyzed 43 IS related publications plus additional background literature. Using qualitative data analysis methods, we developed a model of the elements that constitute IS. We present a classification framework for IS programs and projects and apply it to lay out a map of known IS endeavors. Further, we present qualitative models summarizing the benefits and challenges of IS adoption. The survey provides the first broad review of IS literature and systematic arrangement of IS research results.
- An Example Charter for Inner Source Programs (2016)
- Inner source software development is firm-internal software development that uses the principles of open source software development to collaborate across intra-organizational boundaries that would otherwise hinder any such collaboration. Inner source breaks down the barriers to collaboration across development silos by setting up an internal ecosystem of readily available software components. To get started with inner source, companies need to define their goals and then set up a governance structure for an inner source program and the projects within to reach those goals. This governance structure is often codified in the form of a charter document. This technical report presents an example charter for an inner source program. The goal is for companies to be able to copy and adjust this charter for their own needs. Towards this purpose, the charter leaves open the many decisions to be made, but outlines the options that any company needs to decide upon when establishing an inner source program.
- Das Uni1 Projektkonzept (2016) (2016)
- Dieses Projektkonzept schildert, wie Hochschulen mit Unternehmen Projekte mit Studierenden zu beidseitigem Gewinn durchführen können. Unternehmen profitieren durch Recruiting, Outsourcing und Innovation („ROI“), welche sich durch die Projekte ergeben. Hochschulen gewinnen neue Partner, verdienen an den Projekten und bieten attraktivere Lehre.
- Information Leakage behind the Curtain: Abusing Anti-EMI Features for Covert Communication (2016)
- We present a new class of covert channels which can be created by utilizing common hardware but that cannot be detected by such. Our idea is to abuse anti-EMI features of a processor to create a covert channel on the physical layer. Thus, the sender uses the invariants in how digital signals are encoded over analog channels to covertly transport information. This leaked data is present on the wire bound connections of the compromised device, but is also by definition present in the vicinity of the device and can be picked up by radio equipment. As the covert channel is present only on the physical layer, the data on all layers above, as well as the timing behavior on those layers is indistinguishable from uncompromised devices. We present two example implementations of such channels using RS-232 as the carrier and use a common oscilloscope to decode the resulting covert channel. Using this setup, we observed symbol rates of around 5 baud. We derive the theoretical upper bound of the covert channels bandwidth and discuss the factors by which it is influenced.
- CS 2016-01
- Using Students as a Distributed Coding Team for Validation through Intercoder Agreement (2016)
- In qualitative research, results often emerge through an analysis process called coding. A common measure of validity of theories built through qualitative research is the agreement between different people coding the same materials. High intercoder agreement indicates that the findings are derived from the data as opposed to being relative results based on the original researcher's bias. However, measuring such intercoder agreement incurs the high cost of having additional researchers perform seemingly redundant work. In this paper we present first results on a novel method of using students for validating theories. We find that intercoder agreement between a large number of students is almost as good as the intercoder agreement between two professionals working on the same materials.
- Interrupt Handling in Linux (2015)
- An interrupt is an event that alters the sequence of instructions executed by a processor and requires immediate attention. When the processor receives an interrupt signal, it may temporarily switch control to an inter- rupt service routine (ISR) and the suspended process (i.e., the previously running program) will be resumed as soon as the interrupt is being served. The generic term interrupt is oftentimes used synonymously for two terms, interrupts and exceptions. An exception is a synchronous event that occurs when the processor detects an error condition while executing an instruction. Such an error condition may be a devision by zero, a page fault, a protection violation, etc. An interrupt, on the other hand, is an asynchronous event that occurs at random times during execution of a pro- gram in response to a signal from hardware. A proper and timely handling of interrupts is critical to the performance, but also to the security of a computer system. In general, interrupts can be emitted by hardware as well as by software. Software interrupts (e.g., via the INT n instruction of the x86 instruction set architecture (ISA)) are means to change the execution context of a program to a more privileged interrupt context in order to enter the kernel and, in contrast to hardware interrupts, occur synchronously to the currently running program. Consequently, such instructions are gates to the privileged operating-system kernel (e.g., ring 0 on x86) and thus are used to request services from the kernel (i.e., system calls). A hardware-triggered interrupt indicates that some device requires attention of the processor, and hence implements a means of communication between devices and the operating system. Interrupts from hardware can greatly improve a system’s performance when devices send interrupts (e.g., a keystroke on a keyboard) instead of expensive polling of devices (e.g., periodically polling a keyboard for stroked keys). Furthermore, hardware-emitted interrupts by timers are used for timing and time measurement in general, but also for time sharing as ticks can be used to schedule another task. After arrival of an interrupt, the processor executes the interrupt ser- vice routine that is associated with this interrupt. The ISR is also referred to as the interrupt request (IRQ) handler. But as interrupts are disabled during execution of the IRQ handler, not all kinds of code can or should be executed in this IRQ context. For instance, if such routine goes to sleep with interrupts disabled, the system is likely to freeze. On the other hand, active waiting and blocking should be avoided since other interrupts with potentially urgent needs remain disabled and, hence, cannot be served. Furthermore, acquiring locks is likely to cause deadlocks. As a consequence, the Linux kernel offers various mechanisms and application programming interfaces (APIs) to implement interrupt handling in order to meet certain functional and non-functional requirements. This report focuses on how the Linux operating-system kernel handles interrupts on the software side and aims to give brief background infor- mation as well as implementation details. Detailed information about exceptions and exception handling in the x86 architecture can be found in the CPU manual ”Intel 64 and IA-32 Architectures Software Developer’s Manual”. Notice that the report does not aim for completeness, neither does it target to introduce the general concept of interrupts. It rather tries to provide information for developers, researchers and students, familiar with operating systems and operating-system concepts, how Linux handles interrupts on the software side.
- 14. GI/ITG KuVS Fachgespräch Sensornetze (2015)
- The Five Stages of Open Source Volunteering (2014)
- Today’s software systems build on open source software. Thus, we need to understand how to successfully create, nurture, and mature the software development communities of these open source projects. In this report, we review and discuss best practices of the open source volunteering and recruitment process that successful project leaders are using to lead their projects to success. We combine the perspective of the volunteer, looking at a project, with the perspective of a project leader, looking to find additional volunteers for the project. We identify a five-stage process consisting of a connecting, understanding, engaging, performing, and leading stage. The underlying best practices, when applied, significantly increase the chances for a successful open source project.
- A Framework for Interactive Physical Simulations on Remote HPC Clusters (2013)
- In this work, we introduce the framework for visualization and interactivity for physics engines in real-time, for short VIPER. It is able to execute various physical simulations, visualize the simulation results in real-time and offer computational steering. Especially interesting in this context are simulations running on remotely accessible HPC clusters. As an example, we present a particulate flow simulation consisting of a coupled rigid body and CFD simulation, the chosen visualization strategy and steering possibilities. Additionally, performance evaluations and a performance prediction model concerning the update rate for remote simulations in the context of the VIPER framework are given.