• Embedded systems are systems that are designed for a specific function
  • They are not general purpose like our computers
• Significantly smaller in processing power, memory, and storage than general purpose computers
• Can have an operating system (generally Linux)
• Can have RTOS (real time operating systems)
• Don't have to have an operating system (baremetal)

• Medical devices
• Parts in Automotive Systems
  • Engine control units, infotainment systems
• Industrial robots
• Air conditioning systems
• Digital cameras
• etc.

• Same exact kernel as general purpose Linux, but compiled to meet certain constraints
  • Higher reliability
  • Tighter security
  • System constraints
• Many distributions support it (including Ubuntu)
• The way it operates depends on how you compile it, the distribution, and the goal of the device.

• Small operating system designed to be fast and lightweight
• Created to only have the things you need for an operating system
  • Low-overhead
• Less configurable
• Able to easily be put on microarchitectures
  • Doesn't require an memory management unit as part of the hardware

• No operating system at all!
• This means no features that operating systems bring
  • Virtual Memory - You will be coding directly to physical memory
  • File System Implementation
  • Any user space/kernel space features
• You should do this if size of the firmware and processing power really matters.

• These systems might have access to sensitive parts of a system.
  • We need to ensure that they are protected
• Botnets are a real thing! Especially with internet connected embedded systems
• You are only as strong as your weakest link!
• These devices might contain sensitive information! (Video, audio, statistics, controlling a car).

• This might be one part of the entire system.
  • The embedded device may not do anything that an attacker can do malicious, but it might give insight
  • Pivot to another device
  • Persistence
  • Entry vector

• You will not have symbols!
• While at compile time the ELF symbols are generated, the firmware will not have it on the device generally
• Controlling the device is sensitive!
  • You can break the hardware if you are not careful
• Depending on the device,  you may not be able to do much. Even if you have an exploit

• Need to update! But this is challenging
  • Might require physical access to the device
  • Updates may never happen (not worth it to the vendor)
• Add layers of abstraction
  • Insecure embedded devices shouldn't be connected to sensitive components/the internet
  • Secure Boot
  • Trusted Platform Module
  • Binary Transformations
• etc.

• Cars - The cambus is generally known to have vulnerabilities
  • Well protected through layers of abstraction
• Cheap IOT devices - Cameras, smart speakers, not from name brand
  • Even name brands have issues
• Medical devices
  • this is scary....
• Electrical grids
  • Also scary....

• We are going to be using QEMU to emulate the baremetal firmware!
• QEMU is a full system emulator
• Allows for us to run cross architecture software as well!

• Go to https://www.qemu.org/download/
• Download the latest version of QEMU
• Unzip it on your virtual machine
• Install Dependencies:

  • sudo apt-get install git libglib2.0-dev libfdt-dev libpixman-1-dev zlib1g-dev ninja-build

• ./configure
• make
• sudo make install

• sudo apt install gdb-multiarch
  • This adds ARM support (for x86 machines)
  • Nice to also have many architectural support
• Optional:
  • sudo apt install gcc-arm-none-eabi gcc-aarch64-none-eabi

• Standard: qemu-system-aarch64 -M raspi0 -kernel $(KERN).img -serial null -serial stdio [-semihosting] (be careful when using -semihosting)
• GDB: qemu-system-arm -M raspi0 -kernel kernel.img -serial null -serial stdio -S -gdb tcp::XXXX -boot c
  • To connect, run gdb[-multiarch] and then do target remote localhost:XXXX
  • If you have the ELF file, you can do gdb <kernel.elf> when launching GDB for symbols

• Radare2 or Ghidra are the best for baremetal firmware!
• You will need to figure out the base address of the firmware image
  • Bets way to determine this is by looking at the strings
• We will go through this when we demo

• https://github.com/ENPM809V/baremetal-firmware-challenges

• ARM is a RISC based architecture
  • Fewer instructions than x86
• Commonly used in smaller devices (IOT, Phones, Embedded Systems, etc.)
  • Becoming more popular in general purpose computers (Apple Silicon)

• Reduced Instruction Set Computing
  • Fewer instructions that CISC based architectures
• Instructions can be executed more quickly because it reduces clock cycles per isntructions
• Means that authors/compilers need to write efficient ARM assembler.

• ARM is a Load/Store based model
  • Move instructions can't access memory directly
• It has a mode called thumb mode
  • We will get into this
• More registers
• Multi-endianness (generally stick with little endian)
• Instructions are fixed length generally
  • ARM Mode - 4 bytes
  • Thumb mode - 2 or 4 bytes.

• Two main states of the ARM processor
• The difference between ARM and Thumb is the instruction sets
  • Not privilege level
• ARM is always 32 bits while thumb can be either 16 bit or 32 bit
  • All processors support the same ARM instruction set
  • Not all processors support the same thumb instruction set
• ARM supports conditional execution instructions
• Thumb instructions have a .w suffix
• To switch between states, use either BX or BLX and set/unset the reigster's least significant bit to/from 1.

MNEMONIC{S}{condition} {Rd}, Operand1, Operand2

• MNEMONIC     - Short name (mnemonic) of the instruction

• {S} - An optional suffix

  • If specified, the condition flag is updated based on the result of the operaiton 

• {condition} - Condition necessary to execute the instruction
• {Rd} - Destination register
• Operand1 - The first operand (either register or immediate value)
• Operand2 - Second operand (either register or immediate value with optional shift)

• Unlike x86_64, we cannot memory directly with the MOV instruction
• We have to use ldr and str instructions
  • ldr Ra, [Rb, Offset] - Ra is the destination, Rb is the base, Offset is either a register or immediate as an offset
  • ldr Ra, [Rb, Index]! - Pre-indexed value
    • Ra = Rb+Index
    • Rb = Rb+Index
  • ldr Ra, [Rb], index - Post-indexed value
    • Ra = Rb
    • Rb = Rb+index
• Note: index is still an offset, not like an array offset index

• Unlike x86_64, we cannot memory directly with the MOV instruction
• We have to use ldr and str instructions
  • ldr Ra, [Rb, Offset] - Ra is the destination, Rb is the base, Offset is either a register or immediate as an offset
  • ldr Ra, [Rb, Index]! - Pre-indexed value
    • Ra = Rb+Index
    • Rb = Rb+Index
  • ldr Ra, [Rb], index - Post-indexed value
    • Ra = Rb
    • Rb = Rb+index
• Note: index is still an offset, not like an array offset index

• Unlike x86_64, we cannot memory directly with the MOV instruction
• We have to use ldr and str instructions
  • str Ra, [Rb, Offset] - Ra is the source, Rb is the base, Offset is either a register or immediate as an offset
    • Rb is unmodified
  • str Ra, [Rb, Index]! - Pre-indexed value
    • Ra = Source
    • Memory Location = Rb+Index
    • Rb is modified to Rb+Index
• Note: index is still an offset, not like an array offset index

• Can have a shifter applied to the end as well!
  • Example: str r2, [r1, r2, LSL#2]
  • ldr r3, [r1], r2, LSL#2  
• Can load and store multiple at a time (won't go into this right now)

• We can either have ascending or descending stack!
• Yes this is a weird concept, but this will help us when trying to access values for buffer overflows/stack based attacks/vulnerabilities.
• This can be found by looking at the load/store instructions
  • Empty = Stack pointers points to the next space on the stack that is not utilized
  • Full = stack points at the last thing before an empty slot

• Three main parts: prologue, body, epilogue
• Prologue saves previous state
• Body is the main part of the code
• Epilogue cleans up the function and loads the previous state

Sounds almost exactly like x86 right?

• Three main parts: prologue, body, epilogue
• Prologue saves previous state
• Body is the main part of the code
• Epilogue cleans up the function and loads the previous state

Sounds almost exactly like x86 right?

• 32 bit ARM keeps state, parameters, return values, on the stack.
  • Stack Frame = bottom of stack, Frame Pointer = top of the stack
• 64 bit ARM (aarch64) keeps first seven parameters in x0-x7 (v0-v7 for floating point)

• Can't just use any immediate values
• After allocating bits for instruction menomic, condition codes, destination register, operand register, etc., we have 12 bits left
  • Can only have 4096 different values
• Anything greater means we have to split it up into multiple parts!

• We went through many vulnerabilities and how they can be exploited
  • ROP Chain
  • Heap
  • Sandboxing
  • Kernel
  • Embedded
• We also went over tooling for exploiting! (pwntools, GDB)

• These are all necessary to understand how to defend systems
  • Vulnerability research
  • Information Security
  • Penetration Testing
• You can't defend unless you understand how the exploits work!

• Continue on your journey!
  • The closest job that will work at this level is vulnerability research!
    • Learn how to reverse engineer
    • Learn how to use fuzzers
    • Learn how to use SMT Solvers
  • Start learning low-level software engineering!
  • Learn embedded even further
    • hardware (we did not go over)
    • firmware/software (touched the surface)
  • Develop penetration tools
•  

• To do more binary  exploitation
  • Practice CTFs/Pwn.college/Pwnable.kr
  • Work on red teams
  • Develop your own challenges!
• Gaining more experience
  • Internships/networking - talk with people within the department
  • Research - CMNS has many research opportunities
  • Cyber Security Club - Lots of sponsors!
  • Certifications
    • Not many for binary exploitation, but lots for penetration testing

• Great first semester! Challenging but fair
  • Could have made a couple of the homework easier
  • Learned a little bit on how to structure the homework
  • pwn.college infrastructure worked mostly well!
• What I would change
  • Apply a little more fundamentals and tooling into this course until the new version of ENPM691 is rolled out
  • Maybe spend some time on reverse engineering tooling?
  • Remove embedded??? - Not enough time to cover Userspace, Kernelspace, and Embedded systems
  • Figure out how to foster more collaboration on Discord

• What did all of you think?
• If you don't want to say now, send it via the course evaluation
• What would you liked? What did you want to be changed from next time?