DOCSLIB.ORG

Memory Forensics of Insecure Android Inter-App Communications

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Memory Forensics of Insecure Android Inter-App Communications Memory Forensics of Insecure Android Inter-app Communications Mark Vella and Rachel Cilia Department of Computer Science, University of Malta, Msida, Malta mark.vella, rachel.cilia.13 @um.edu.mt { } Keywords: Mobile Systems Security, Android Memory Forensics, Capability Leaks. Abstract: Android is designed in a way to promote the implementation of user task flows among multiple applications inside mobile devices. Consequently, app permissions may be leaked to malicious apps without users noticing any compromise to their devices’ security. In this work we explore the possibility of detecting insecure inter- app communications inside memory dumps, with forensic analysis results indicating the possibility of doing so across the various layers of Android’s architecture. Yet, for the detailed evidence reconstruction that could be required during digital investigation, current capabilities have to be complemented with evidence collected through live forensics. We propose that this process should still be based on carving forensic artifacts directly from memory. 1 INTRODUCTION live forensics approach would be necessary. There- fore we conclude this work (section 6) with a propo- sition that relies on collecting evidence directly from Android, the most popular mobile device operating live memory on-demand, using runtime patching. system, is designed in a way to both isolate poten- tially security-critical apps from each other as well as to have apps seamlessly delegate their functional- ity to third-parties (Elenkov, 2014). Clearly these two 2 ANDROID INTER-APP design objectives are at odds, leading to various in- COMMUNICATION secure inter-app communication links such as when vulnerable apps leak their legitimately granted privi- Android apps are composed of classes that extend leges to malicious ones, known as capability leaks. In framework components, namely: activities (app win- this work we begin to explore how to expose inter-app dows), services (long running, mostly background, links directly from physical memory; which is a tech- code), broadcast receivers (handlers of device-wide nique that does not have to rely on possibly tampered events) and content providers (shared data reposito- code, and which successfully executing malware can- ries); eventually fleshed out with application logic not evade. The value proposition is that of increased that makes use of Android system services, e.g. mes- systems security of Android-powered mobile devices. saging, telephony, Internet-access, location services Android’s Binder is the inter-process communica- and so on (Gargenta, 2012). The first three of these tion mechanism through which all inter-app links are components are activated through intents whilst the established (section 2). Code comprehension is uti- latter through content resolvers. lized to predict the relevant forensic artifacts across Intents are application framework constructs rep- Android’s architectural layers (section 3). Our pri- resenting the ‘intent’ion of an application component mary contribution lies in proposing a memory dump to provide some functionality. Intent-servicing com- parsing algorithm for each layer (section 4) and sub- ponents can even be exported for use by external ap- sequently used to verify artifact suitability through plications, thereby constituting a primary IPC con- forensic analysis (section 5). Results show that by struct. Explicit intents identify specifically the target combining artifacts identified within different sec- apps hosting the activities/services to be activated in tions of memory, all types of inter-app links can be correspondence to the specified intent action (listing disclosed from memory dumps despite varying de- 1). On the other hand, implicit intents only identify grees of reliability. However for the level of detail the action and possibly some other attributes (listing that may be required during digital investigation, a 2). In this case Android takes care of routing them to 481 Vella, M. and Cilia, R. Memory Forensics of Insecure Android Inter-app Communications. DOI: 10.5220/0006215504810486 In Proceedings of the 3rd International Conference on Information Systems Security and Privacy (ICISSP 2017), pages 481-486 ISBN: 978-989-758-209-7 Copyright c 2017 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved ICISSP 2017 - 3rd International Conference on Information Systems Security and Privacy those apps that would have declared interest in servic- missions, also have the sufficient privilege level ing them during install time, also possibly asking the to access the device’s contacts (e.g. by calling user to choose between multiple such candidate apps. Context.checkCallingPermission()). Otherwise On the other hand, content resolvers provide access to a capability leak is said to occur whenever an unpriv- external content providers. ileged app obtains contacts through it (Zhang et al., 2016). In this work we focus specifically on Intent- Listing 1: Explicit intents are used to launch activities or derived leaks, given that content resolvers should nor- services inside external applications. mally be used to directly access system/external data //Starting an external activity: repositories only, rather than potentially permission- PackageManager pm = t h i s .getPackageManager() ; leaking code. t r y { Listing 3: Vulnerable app’s AndroidMainfest.xml. Intent it = pm.getLaunchIntentForPackage(” com.example.mvella. eiserver”); 1 i f ( n u l l != i t ) t h i s .startActivity(it); .. 2 <package name=”com.example. mvella .vulnapp” SNIP . codePath =”...SNIP... 3 <uses permission android:name=”android. − //Starting an external service: permission .READ CONTACTS”/> 4 <uses permission android:name=”android. Intent intent = new Intent (”com.example.mvella. − e i s e r v e r . ACTION START” ) ; permission .WRITE CONTACTS”/> intent .setComponent( new ComponentName(”com. 5 ...SNIP... example.mvella. eiserver”, ”com.example. 6 <service android:name=”com.example. mvella. eiserver .DiffAppStartService”)); mvella.vulnapp. updateContacts”> 7 <i n t e n t f i l t e r > startService(intent); − 8 <action android:name=”. Listing 2: Implicit intents only specify actions along with ACTION START”/> 9 </ i n t e n t f i l t e r > various possible qualifiers. − 10 startActivity( Intent ( Intent .ACTION VIEW , Uri . new 11 </ s e r v i c e > parse(”http ://www.google.com”))); 12 . SNIP . 2.1 Capability Leaks 2.2 Related Work Intents and content resolvers are core Android appli- While preventable both from secure coding and per- cation development constructs encouraging inter-app mission enforcement hardening stances (Zhang et al., functionality and data sharing, providing the required 2016), capability leaks are still bound to happen in support for user task flow implementation across mul- existing devices due to the difficulty concerned with tiple apps. A number of system intents are in fact complete eradication of vulnerabilities. We focus made available by the Android framework itself and on the provision of graceful recovery using memory are expected to be serviced by pre-installed/default forensics. Robust memory acquisition from Android apps e.g. picture viewers, instant messaging, and tele- devices has been explored extensively (Sylve et al., phony. The transition from one app to another can 2012). This body of knowledge underpins the LiME be so seamless that it may not be even noticed by acquisition tool utilized in this work. Memory ac- the device user. Since Android makes sure to iso- quisition differs from disk image acquisition since late Android apps from each other as well as from the address bus space in typical microprocessor ar- sensitive device services (e.g. telephony and net- chitectures is not exclusive to physical RAM, but is working), a permissions system is used to relax the rather shared with all memory-mapped hardware de- level of isolation in a controlled manner (Elenkov, vices. Erroneously reading from non-RAM addresses 2014). System permission requests are declared in- compromises system integrity. This same issue could side manifest files (app package meta-data) through however be leveraged by malware to evade memory the uses-permission tag. acquisition (Stuttgen¨ and Cohen, 2013). Mobile de- Listing 3 (lines 3-4), for example, requests vice forensics is challenging even at secondary stor- read/write access to the device’s contacts. Yet, it age level due to the variety of available custom hard- is the responsibility of the app developer to check ware (Kong, 2015). However, the wide-spread adop- that external apps activating the updateContacts tion of Android creates an opportunity for a common service (line 6) through the ACTION START in- source of in-memory forensic evidence. In this work tent (line 8) and that makes use of these per- we focus specifically on Android Binder and which 482 Memory Forensics of Insecure Android Inter-app Communications security-criticality has already been targeted by offen- (core/java/android/os/IMessenger.aidl). sive security studies (Artenstein and Revivo, 2014). Specifically, using the Android Runtime (ART)’s (libart.so) Java-Native Interface (JNI) media- tion, the proxy creates a serialized represen- tation of aMsg inside the middleware layer 3 ANDROID BINDER (libs/binder/Parcel.cpp), across a Java- native link registered by libandroid runtime.so All IPC constructs available to Android app devel- (core/jni/android util Binder.cpp). Sub- opers (Gargenta, 2012) are implemented as Remote sequently it is passed onto
Load more

Recommended publications
  • D-Bus, the Message Bus System Training Material
    Maemo Diablo D-Bus, The Message Bus System Training Material February 9, 2009 Contents 1 D-Bus, The Message Bus System 2 1.1 Introduction to D-Bus ......................... 2 1.2 D-Bus architecture and terminology ................ 3 1.3 Addressing and names in D-Bus .................. 4 1.4 Role of D-Bus in maemo ....................... 6 1.5 Programming directly with libdbus ................. 9 1 Chapter 1 D-Bus, The Message Bus System 1.1 Introduction to D-Bus D-Bus (the D originally stood for "Desktop") is a relatively new inter process communication (IPC) mechanism designed to be used as a unified middleware layer in free desktop environments. Some example projects where D-Bus is used are GNOME and Hildon. Compared to other middleware layers for IPC, D-Bus lacks many of the more refined (and complicated) features and for that reason, is faster and simpler. D-Bus does not directly compete with low level IPC mechanisms like sock- ets, shared memory or message queues. Each of these mechanisms have their uses, which normally do not overlap the ones in D-Bus. Instead, D-Bus aims to provide higher level functionality, like: Structured name spaces • Architecture independent data formatting • Support for the most common data elements in messages • A generic remote call interface with support for exceptions (errors) • A generic signalling interface to support "broadcast" type communication • Clear separation of per-user and system-wide scopes, which is important • when dealing with multi-user systems Not bound to any specific programming language (while providing a • design that readily maps to most higher level languages, via language specific bindings) The design of D-Bus benefits from the long experience of using other mid- dleware IPC solutions in the desktop arena and this has allowed the design to be optimised.
    [Show full text]
  • Retrofitting Privacy Controls to Stock Android
    Saarland University Faculty of Mathematics and Computer Science Department of Computer Science Retrofitting Privacy Controls to Stock Android Dissertation zur Erlangung des Grades des Doktors der Ingenieurwissenschaften der Fakultät für Mathematik und Informatik der Universität des Saarlandes von Philipp von Styp-Rekowsky Saarbrücken, Dezember 2019 Tag des Kolloquiums: 18. Januar 2021 Dekan: Prof. Dr. Thomas Schuster Prüfungsausschuss: Vorsitzender: Prof. Dr. Thorsten Herfet Berichterstattende: Prof. Dr. Michael Backes Prof. Dr. Andreas Zeller Akademischer Mitarbeiter: Dr. Michael Schilling Zusammenfassung Android ist nicht nur das beliebteste Betriebssystem für mobile Endgeräte, sondern auch ein ein attraktives Ziel für Angreifer. Um diesen zu begegnen, nutzt Androids Sicher- heitskonzept App-Isolation und Zugangskontrolle zu kritischen Systemressourcen. Nutzer haben dabei aber nur wenige Optionen, App-Berechtigungen gemäß ihrer Bedürfnisse einzuschränken, sondern die Entwickler entscheiden über zu gewährende Berechtigungen. Androids Sicherheitsmodell kann zudem nicht durch Dritte angepasst werden, so dass Nutzer zum Schutz ihrer Privatsphäre auf die Gerätehersteller angewiesen sind. Diese Dissertation präsentiert einen Ansatz, Android mit umfassenden Privatsphäreeinstellun- gen nachzurüsten. Dabei geht es konkret um Techniken, die ohne Modifikationen des Betriebssystems oder Zugriff auf Root-Rechte auf regulären Android-Geräten eingesetzt werden können. Der erste Teil dieser Arbeit etabliert Techniken zur Durchsetzung von Sicherheitsrichtlinien
    [Show full text]
  • Beej's Guide to Unix IPC
    Beej's Guide to Unix IPC Brian “Beej Jorgensen” Hall [email protected] Version 1.1.3 December 1, 2015 Copyright © 2015 Brian “Beej Jorgensen” Hall This guide is written in XML using the vim editor on a Slackware Linux box loaded with GNU tools. The cover “art” and diagrams are produced with Inkscape. The XML is converted into HTML and XSL-FO by custom Python scripts. The XSL-FO output is then munged by Apache FOP to produce PDF documents, using Liberation fonts. The toolchain is composed of 100% Free and Open Source Software. Unless otherwise mutually agreed by the parties in writing, the author offers the work as-is and makes no representations or warranties of any kind concerning the work, express, implied, statutory or otherwise, including, without limitation, warranties of title, merchantibility, fitness for a particular purpose, noninfringement, or the absence of latent or other defects, accuracy, or the presence of absence of errors, whether or not discoverable. Except to the extent required by applicable law, in no event will the author be liable to you on any legal theory for any special, incidental, consequential, punitive or exemplary damages arising out of the use of the work, even if the author has been advised of the possibility of such damages. This document is freely distributable under the terms of the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License. See the Copyright and Distribution section for details. Copyright © 2015 Brian “Beej Jorgensen” Hall Contents 1. Intro................................................................................................................................................................1 1.1. Audience 1 1.2. Platform and Compiler 1 1.3.
    [Show full text]
  • Mmap and Dma
    CHAPTER THIRTEEN MMAP AND DMA This chapter delves into the area of Linux memory management, with an emphasis on techniques that are useful to the device driver writer. The material in this chap- ter is somewhat advanced, and not everybody will need a grasp of it. Nonetheless, many tasks can only be done through digging more deeply into the memory man- agement subsystem; it also provides an interesting look into how an important part of the kernel works. The material in this chapter is divided into three sections. The first covers the implementation of the mmap system call, which allows the mapping of device memory directly into a user process’s address space. We then cover the kernel kiobuf mechanism, which provides direct access to user memory from kernel space. The kiobuf system may be used to implement ‘‘raw I/O’’ for certain kinds of devices. The final section covers direct memory access (DMA) I/O operations, which essentially provide peripherals with direct access to system memory. Of course, all of these techniques requir e an understanding of how Linux memory management works, so we start with an overview of that subsystem. Memor y Management in Linux Rather than describing the theory of memory management in operating systems, this section tries to pinpoint the main features of the Linux implementation of the theory. Although you do not need to be a Linux virtual memory guru to imple- ment mmap, a basic overview of how things work is useful. What follows is a fairly lengthy description of the data structures used by the kernel to manage memory.
    [Show full text]
  • An Introduction to Linux IPC
    An introduction to Linux IPC Michael Kerrisk © 2013 linux.conf.au 2013 http://man7.org/ Canberra, Australia [email protected] 2013-01-30 http://lwn.net/ [email protected] man7 .org 1 Goal ● Limited time! ● Get a flavor of main IPC methods man7 .org 2 Me ● Programming on UNIX & Linux since 1987 ● Linux man-pages maintainer ● http://www.kernel.org/doc/man-pages/ ● Kernel + glibc API ● Author of: Further info: http://man7.org/tlpi/ man7 .org 3 You ● Can read a bit of C ● Have a passing familiarity with common syscalls ● fork(), open(), read(), write() man7 .org 4 There’s a lot of IPC ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memory attach ● Pseudoterminals ● proc_vm_readv() / proc_vm_writev() ● Sockets ● Signals ● Stream vs Datagram (vs Seq. packet) ● Standard, Realtime ● UNIX vs Internet domain ● Eventfd ● POSIX message queues ● Futexes ● POSIX shared memory ● Record locks ● ● POSIX semaphores File locks ● ● Named, Unnamed Mutexes ● System V message queues ● Condition variables ● System V shared memory ● Barriers ● ● System V semaphores Read-write locks man7 .org 5 It helps to classify ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memory attach ● Pseudoterminals ● proc_vm_readv() / proc_vm_writev() ● Sockets ● Signals ● Stream vs Datagram (vs Seq. packet) ● Standard, Realtime ● UNIX vs Internet domain ● Eventfd ● POSIX message queues ● Futexes ● POSIX shared memory ● Record locks ● ● POSIX semaphores File locks ● ● Named, Unnamed Mutexes ● System V message queues ● Condition variables ● System V shared memory ● Barriers ● ● System V semaphores Read-write locks man7 .org 6 It helps to classify ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memoryn attach ● Pseudoterminals tio a ● proc_vm_readv() / proc_vm_writev() ● Sockets ic n ● Signals ● Stream vs Datagram (vs uSeq.
    [Show full text]
  • Table of Contents
    TABLE OF CONTENTS Chapter 1 Introduction ............................................................................................. 3 Chapter 2 Examples for FPGA ................................................................................. 4 2.1 Factory Default Code ................................................................................................................................. 4 2.2 Nios II Control for Programmable PLL/ Temperature/ Power/ 9-axis ....................................................... 6 2.3 Nios DDR4 SDRAM Test ........................................................................................................................ 12 2.4 RTL DDR4 SDRAM Test ......................................................................................................................... 14 2.5 USB Type-C DisplayPort Alternate Mode ............................................................................................... 15 2.6 USB Type-C FX3 Loopback .................................................................................................................... 17 2.7 HDMI TX and RX in 4K Resolution ........................................................................................................ 21 2.8 HDMI TX in 4K Resolution ..................................................................................................................... 26 2.9 Low Latency Ethernet 10G MAC Demo .................................................................................................. 29 2.10 Socket
    [Show full text]
  • This Is the Architecture of Android. Android Runs on Top of a Vanilla Kernel with Little Modifications, Which Are Called Androidisms
    4. This is the architecture of Android. Android runs on top of a vanilla kernel with little modifications, which are called Androidisms. The native userspace, includes the init process, a couple of native daemons, hundreds of native libraries and the Hardware Abstraction Layer (HAL). The native libraries are implemented in C/C++ and their functionality is exposed to applications through Java framework APIs. A large part of Android is implemented in Java and until Android version 5.0 the default runtime was Dalvik. Recently a new, more performant runtime, called ART has been integrated in Android (first made available as an option in version 4.4, default runtime from version 5.0). Java runtime libraries are defined in java.* and javax.* packages, and are derived from Apache Harmony project (not Oracle/SUN, in order to avoid copyright and distribution issues.), but several components have been replaced, others extended and improved. Native code can be called from Java through the Java Native Interface (JNI). A large part of the fundamental features of Android are implemented in the system services: display, touch screen, telephony, network connectivity, and so on. A part of these services are implemented in native code and the rest in Java. Each service provides an interface which can be called from other components. Android Framework libraries (also called “the framework API”) include classes for building Android applications. On top, we have the stock applications, that come with the phone. And other applications that are installed by the user. 6. ● Most Linux distributions take the vanilla kernel (from Linux Kernel Archives) and apply their own patches in order to solve bugs, add specific features and improve performance.
    [Show full text]
  • Open Message Queue Technical Overview Release 5.0
    Open Message Queue Technical Overview Release 5.0 May 2013 This book provides an introduction to the technology, concepts, architecture, capabilities, and features of the Message Queue messaging service. Open Message Queue Technical Overview, Release 5.0 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).
    [Show full text]
  • IPC: Mmap and Pipes
    Interprocess Communication: Memory mapped files and pipes CS 241 April 4, 2014 University of Illinois 1 Shared Memory Private Private address OS address address space space space Shared Process A segment Process B Processes request the segment OS maintains the segment Processes can attach/detach the segment 2 Shared Memory Private Private Private address address space OS address address space space space Shared Process A segment Process B Can mark segment for deletion on last detach 3 Shared Memory example /* make the key: */ if ((key = ftok(”shmdemo.c", 'R')) == -1) { perror("ftok"); exit(1); } /* connect to (and possibly create) the segment: */ if ((shmid = shmget(key, SHM_SIZE, 0644 | IPC_CREAT)) == -1) { perror("shmget"); exit(1); } /* attach to the segment to get a pointer to it: */ data = shmat(shmid, (void *)0, 0); if (data == (char *)(-1)) { perror("shmat"); exit(1); } 4 Shared Memory example /* read or modify the segment, based on the command line: */ if (argc == 2) { printf("writing to segment: \"%s\"\n", argv[1]); strncpy(data, argv[1], SHM_SIZE); } else printf("segment contains: \"%s\"\n", data); /* detach from the segment: */ if (shmdt(data) == -1) { perror("shmdt"); exit(1); } return 0; } Run demo 5 Memory Mapped Files Memory-mapped file I/O • Map a disk block to a page in memory • Allows file I/O to be treated as routine memory access Use • File is initially read using demand paging ! i.e., loaded from disk to memory only at the moment it’s needed • When needed, a page-sized portion of the file is read from the file system
    [Show full text]
  • A Machine-Independent DMA Framework for Netbsd
    AMachine-Independent DMA Framework for NetBSD Jason R. Thorpe1 Numerical Aerospace Simulation Facility NASA Ames Research Center Abstract 1.1. Host platform details One of the challenges in implementing a portable In the example platforms listed above,there are at kernel is finding good abstractions for semantically- least three different mechanisms used to perform DMA. similar operations which often have very machine- The first is used by the i386 platform. This mechanism dependent implementations. This is especially impor- can be described as "what you see is what you get": the tant on modern machines which share common archi- address that the device uses to perform the DMA trans- tectural features, e.g. the PCI bus. fer is the same address that the host CPU uses to access This paper describes whyamachine-independent the memory location in question. DMA mapping abstraction is needed, the design consid- DMA address Host address erations for such an abstraction, and the implementation of this abstraction in the NetBSD/alpha and NetBSD/i386 kernels. 1. Introduction NetBSD is a portable, modern UNIX-likeoperat- ing system which currently runs on eighteen platforms covering nine processor architectures. Some of these platforms, including the Alpha and i3862,share the PCI busasacommon architectural feature. In order to share device drivers for PCI devices between different platforms, abstractions that hide the details of bus access must be invented. The details that must be hid- den can be broken down into twoclasses: CPU access Figure 1 - WYSIWYG DMA to devices on the bus (bus_space)and device access to host memory (bus_dma). Here we will discuss the lat- The second mechanism, employed by the Alpha, ter; bus_space is a complicated topic in and of itself, is very similar to the first; the address the host CPU and is beyond the scope of this paper.
    [Show full text]
  • Interprocess Communication
    06 0430 CH05 5/22/01 10:22 AM Page 95 5 Interprocess Communication CHAPTER 3,“PROCESSES,” DISCUSSED THE CREATION OF PROCESSES and showed how one process can obtain the exit status of a child process.That’s the simplest form of communication between two processes, but it’s by no means the most powerful.The mechanisms of Chapter 3 don’t provide any way for the parent to communicate with the child except via command-line arguments and environment variables, nor any way for the child to communicate with the parent except via the child’s exit status. None of these mechanisms provides any means for communicating with the child process while it is actually running, nor do these mechanisms allow communication with a process outside the parent-child relationship. This chapter describes means for interprocess communication that circumvent these limitations.We will present various ways for communicating between parents and chil- dren, between “unrelated” processes, and even between processes on different machines. Interprocess communication (IPC) is the transfer of data among processes. For example, a Web browser may request a Web page from a Web server, which then sends HTML data.This transfer of data usually uses sockets in a telephone-like connection. In another example, you may want to print the filenames in a directory using a command such as ls | lpr.The shell creates an ls process and a separate lpr process, connecting 06 0430 CH05 5/22/01 10:22 AM Page 96 96 Chapter 5 Interprocess Communication the two with a pipe, represented by the “|” symbol.A pipe permits one-way commu- nication between two related processes.The ls process writes data into the pipe, and the lpr process reads data from the pipe.
    [Show full text]
  • Real-Time Streaming Video and Image Processing on Inexpensive Hardware with Low Latency
    University of Nebraska - Lincoln DigitalCommons@University of Nebraska - Lincoln Theses, Dissertations, and Student Research Electrical & Computer Engineering, Department from Electrical & Computer Engineering of Spring 5-2018 Real-Time Streaming Video and Image Processing on Inexpensive Hardware with Low Latency Richard L. Gregg University of Nebraska - Lincoln, [email protected] Follow this and additional works at: https://digitalcommons.unl.edu/elecengtheses Part of the Computer Engineering Commons, and the Other Electrical and Computer Engineering Commons Gregg, Richard L., "Real-Time Streaming Video and Image Processing on Inexpensive Hardware with Low Latency" (2018). Theses, Dissertations, and Student Research from Electrical & Computer Engineering. 93. https://digitalcommons.unl.edu/elecengtheses/93 This Article is brought to you for free and open access by the Electrical & Computer Engineering, Department of at DigitalCommons@University of Nebraska - Lincoln. It has been accepted for inclusion in Theses, Dissertations, and Student Research from Electrical & Computer Engineering by an authorized administrator of DigitalCommons@University of Nebraska - Lincoln. Real-Time Streaming Video And Image Processing On Inexpensive Hardware With Low Latency by Richard L. Gregg A THESIS Presented to the Faculty of The Graduate College at the University of Nebraska In Partial Fulfillment of Requirements For the Degree of Master of Science Major: Telecommunications Engineering Under the Supervision of Professor Dongming Peng Lincoln, Nebraska May 2018 REAL-TIME STREAMING VIDEO AND IMAGE PROCESSING ON INEXPENSIVE HARDWARE WITH LOW LATENCY Richard L. Gregg, M.S. University of Nebraska, 2018 Advisor: Dongming Peng The use of resource constrained inexpensive hardware places restrictions on the design of streaming video and image processing system performance.
    [Show full text]