673 research outputs found

    Strategies for protecting intellectual property when using CUDA applications on graphics processing units

    Get PDF
    Recent advances in the massively parallel computational abilities of graphical processing units (GPUs) have increased their use for general purpose computation, as companies look to take advantage of big data processing techniques. This has given rise to the potential for malicious software targeting GPUs, which is of interest to forensic investigators examining the operation of software. The ability to carry out reverse-engineering of software is of great importance within the security and forensics elds, particularly when investigating malicious software or carrying out forensic analysis following a successful security breach. Due to the complexity of the Nvidia CUDA (Compute Uni ed Device Architecture) framework, it is not clear how best to approach the reverse engineering of a piece of CUDA software. We carry out a review of the di erent binary output formats which may be encountered from the CUDA compiler, and their implications on reverse engineering. We then demonstrate the process of carrying out disassembly of an example CUDA application, to establish the various techniques available to forensic investigators carrying out black-box disassembly and reverse engineering of CUDA binaries. We show that the Nvidia compiler, using default settings, leaks useful information. Finally, we demonstrate techniques to better protect intellectual property in CUDA algorithm implementations from reverse engineering

    Android application forensics: A survey of obfuscation, obfuscation detection and deobfuscation techniques and their impact on investigations

    Get PDF
    Android obfuscation techniques include not only classic code obfuscation techniques that were adapted to Android, but also obfuscation methods that target the Android platform specifically. This work examines the status-quo of Android obfuscation, obfuscation detection and deobfuscation. Specifically, it first summarizes obfuscation approaches that are commonly used by app developers for code optimization, to protect their software against code theft and code tampering but are also frequently misused by malware developers to circumvent anti-malware products. Secondly, the article focuses on obfuscation detection techniques and presents various available tools and current research. Thirdly, deobfuscation (which aims at reinstating the original state before obfuscation) is discussed followed by a brief discussion how this impacts forensic investigation. We conclude that although obfuscation is widely used in Android app development (benign and malicious), available tools and the practices on how to deal with obfuscation are not standardized, and so are inherently lacking from a forensic standpoint

    DexPro:A Bytecode Level Code Protection System for Android Applications

    Get PDF
    Unauthorized code modification through reverse engineering is a major concern for Android application developers. Code reverse engineering is often used by adversaries to remove the copyright protection or advertisements from the app, or to inject malicious code into the program. By making the program difficult to analyze, code obfuscation is a potential solution to the problem. However, there is currently little work on applying code obfuscation to compiled Android bytecode. This paper presents DexPro, a novel bytecode level code obfuscation system for Android applications. Unlike prior approaches, our method performs on the Android Dex bytecode and does not require access to high-level program source or modification of the compiler or the VM. Our approach leverages the fact all except floating operands in Dex are stored in a 32-bit register to pack two 32-bit operands into a 64-bit operand. In this way, any attempt to decompile the bytecode will result in incorrect information. Meanwhile, our approach obfuscates the program control flow by inserting opaque predicates before the return instruction of a function call, which makes it harder for the attacker to trace calls to protected functions. Experimental results show that our approach can deter sophisticate reverse engineering and code analysis tools, and the overhead of runtime and memory footprint is comparable to existing code obfuscation methods

    A Safety-First Approach to Memory Models.

    Full text link
    Sequential consistency (SC) is arguably the most intuitive behavior for a shared-memory multithreaded program. It is widely accepted that language-level SC could significantly improve programmability of a multiprocessor system. However, efficiently supporting end-to-end SC remains a challenge as it requires that both compiler and hardware optimizations preserve SC semantics. Current concurrent languages support a relaxed memory model that requires programmers to explicitly annotate all memory accesses that can participate in a data-race ("unsafe" accesses). This requirement allows compiler and hardware to aggressively optimize unannotated accesses, which are assumed to be data-race-free ("safe" accesses), while still preserving SC semantics. However, unannotated data races are easy for programmers to accidentally introduce and are difficult to detect, and in such cases the safety and correctness of programs are significantly compromised. This dissertation argues instead for a safety-first approach, whereby every memory operation is treated as potentially unsafe by the compiler and hardware unless it is proven otherwise. The first solution, DRFx memory model, allows many common compiler and hardware optimizations (potentially SC-violating) on unsafe accesses and uses a runtime support to detect potential SC violations arising from reordering of unsafe accesses. On detecting a potential SC violation, execution is halted before the safety property is compromised. The second solution takes a different approach and preserves SC in both compiler and hardware. Both SC-preserving compiler and hardware are also built on the safety-first approach. All memory accesses are treated as potentially unsafe by the compiler and hardware. SC-preserving hardware relies on different static and dynamic techniques to identify safe accesses. Our results indicate that supporting SC at the language level is not expensive in terms of performance and hardware complexity. The dissertation also explores an extension of this safety-first approach for data-parallel accelerators such as Graphics Processing Units (GPUs). Significant microarchitectural differences between CPU and GPU require rethinking of efficient solutions for preserving SC in GPUs. The proposed solution based on our SC-preserving approach performs nearly on par with the baseline GPU that implements a data-race-free-0 memory model.PhDComputer Science and EngineeringUniversity of Michigan, Horace H. Rackham School of Graduate Studieshttp://deepblue.lib.umich.edu/bitstream/2027.42/120794/1/ansingh_1.pd

    Beyond Good and Evil: Formalizing the Security Guarantees of Compartmentalizing Compilation

    Full text link
    Compartmentalization is good security-engineering practice. By breaking a large software system into mutually distrustful components that run with minimal privileges, restricting their interactions to conform to well-defined interfaces, we can limit the damage caused by low-level attacks such as control-flow hijacking. When used to defend against such attacks, compartmentalization is often implemented cooperatively by a compiler and a low-level compartmentalization mechanism. However, the formal guarantees provided by such compartmentalizing compilation have seen surprisingly little investigation. We propose a new security property, secure compartmentalizing compilation (SCC), that formally characterizes the guarantees provided by compartmentalizing compilation and clarifies its attacker model. We reconstruct our property by starting from the well-established notion of fully abstract compilation, then identifying and lifting three important limitations that make standard full abstraction unsuitable for compartmentalization. The connection to full abstraction allows us to prove SCC by adapting established proof techniques; we illustrate this with a compiler from a simple unsafe imperative language with procedures to a compartmentalized abstract machine.Comment: Nit
    corecore