Month: April 2016

ARM Technical Learning Resources

~ hucktech ~ Leave a comment

Tom Stevens of ARM posted a blog with a new list of links for developers new to ARM. About 40 links, mostly on ARM assembly and C, Cortex-M, NEON, ARMv8/AArch64. Here’s a list of the initial 10 or so links’s titles:

Getting Started with ARM Microcontroller and Assembly Programming
How to Load Constants in Assembly for ARM Architecture
Branch and Call Sequences Explained
Building Customized Debug and Trace Solutions for Multicore SoCs
Caches and Self-Modifying Code
Code Size: A Comprehensive Comparison of MicroMIPS32 and Thumb Code Size Using Many Megabytes of Customer Code
How to Call a Function from ARM Assembler
Designing in ARM: Part One- Switching Microcontrollers
Getting Started with ARM Assembly and C Programming
Detecting Overflow from MUL

Full article:
https://community.arm.com/groups/processors/blog/2015/03/03/important-arm-technical-learning-resources

If this were done outside ARM.com, it’d probably github-hosted and called ‘awesome-arm-development.md’. (BTW, I’m slowly working on an ‘awesome firmware’ link collection, if someone doesn’t do one first…)

EopMon: EoP detector for Intel VT-x

~ hucktech ~ Leave a comment

Satoshi Tanda has created EopMon, an elevation-of-privilege detector for Windows 7/8.1/10 on Intel x86 and x64 systems which support Intel VT-x and EBT.

EopMon is based his earlier project, HyperPlatform, which is also worth checking out, along with MemoryMon and GuardMon.

EopMon is a hypervisor-based elevation of privilege (EoP) detector. It can spots a process with a stolen system token and terminate it by utilizing hypervisor’s ability to monitor process context-swiching. […] While EopMon is tested against multiple EoP exploits carried out by in the wild malware, it is rather meant to be an educational tool to demonstrate a potential use case of a hypervisor for security research and not aimed for comprehensive exploit prevention. […] EopMon is meant to be an educational tool and not robust, production quality software which is able to handle various edge cases. […] For this reason, researchers are encouraged to use this project only as a reference to examine and develop ideas of using a hypervisor.

https://github.com/tandasat/EopMon
https://github.com/tandasat/HyperPlatform
https://github.com/tandasat/MemoryMon
https://github.com/tandasat/GuardMon

Reversing Huawei router part 2: U-Boot’s CLI

~ hucktech ~ Leave a comment

Juan Carlos Jiménez has written the 2nd part of his series on reversing a Huawei router! The first part was excellent, this one is just as good.

Practical Reverse Engineering Part 2 – Scouting the Firmware

In part 1 we found a debug UART port that gave us access to a linux shell. At this point we’ve got the same access to the router that a developer would use to debug issues, control the system, etc. This first overview of the system is easy to access, doesn’t require expensive tools and will often yield very interesting results. If you want to do some hardware hacking but don’t have the time to get your hands too dirty, this is often the point where you stop digging into the hardware and start working on the higher level interfaces: network vulnerabilities, ISP configuration protocols, etc. […]

Part 2:
http://jcjc-dev.com/2016/04/29/reversing-huawei-router-2-scouting-firmware/

Part 1:

Huawei HG533 reversing, part I


http://jcjc-dev.com/2016/04/08/reversing-huawei-router-1-find-uart/

Intel ATR site updates it’s research on web site

~ hucktech ~ Leave a comment

Intel Advanced Threat Research (ATR) is home of the CHIPSEC team. They just updated their web site with more presentation archives.

http://www.intelsecurity.com/advanced-threat-research/index.html

BIOS mod lab at upcoming SecuringHardware.com training

~ hucktech ~ Leave a comment

For those who need Evil Maid skills take note: Joe Fitzpatrick has added a BIOS mod lab to his Black Hat training on x86 physical attacks.

Applied Physical Attacks on x86 Systems
Joe FitzPatrick, SecuringHardware.com
July 30-August 2

This course introduces and explores attacks on several different relatively accessible interfaces on x86 systems. Attendees will get hands-on experience implementing and deploying a number of low-cost hardware devices to enable access, privilege, and deception which is in some cases imperceptible from software. The course has several modules: USB, SPI/BIOS, I2C/SMBus, PCIe, and JTAG. Each begins with an architectural overview of an interface, and follows with a series of labs for hands-on practice understanding, observing, interacting with, and exploiting the interface, finishing with either potentially exploitable crashes or directly to root shells.

https://www.blackhat.com/us-16/training/applied-physical-attacks-on-x86-systems.html

new CHIPSEC changes

~ hucktech ~ Leave a comment

As I understand things, Intel has a private source tree for CHIPSEC, and makes snapshots of [a subset of] this private tree to their public github.com-hosted source tree. As a result, CHIPSEC usually doesn’t release incrementally, updates usually come in big batches. So it is a surprise to see some recent incremental changes to the CHIPSEC public code tree. Here are some commits between mid-March and today:

Merge pull request #26 from tweksteen/cmos_test_reviewed
Merge pull request #25 from tweksteen/spi_test_reviewed
Merge pull request #27 from tweksteen/x1_carbon_test_reviewed
Merge pull request #23 from tweksteen/fix_i386_linux_driver
Remove unused setUp and tearDown
Add hardware test for X1 Carbon
Add test for CMOS dump
Add test for SPI info
Merge pull request #24 from tweksteen/raise_oshelper
Merge pull request #22 from tweksteen/sort_acpi_tables
Change sys.exit to re-raise
Sort ACPI tables by name
Fix Linux driver build on i386
Merged changes from #17 pull request
removed win specific cleanup script
Merge pull request #21 from chipsec/dev
Merge pull request #11 from tweksteen/setup
Merge pull request #14 from tweksteen/uefi_clean_up
Fix ACPI RSDP resolution based on EBDA
Add tests for ACPI RSDP, RSDT and XSDT.
Add basic tests
Fix Linux helper close
Do not force kernel module loading on Linux
Use metaclass to autoload helpers

https://github.com/chipsec/chipsec
https://github.com/chipsec/chipsec/commits/master

many EFI changes in Linux 4.7 queue

~ hucktech ~ Leave a comment

Matt Fleming posted a 40-part (!) patch, with the queue of UEFI changes for Linux 4.7 kernel. Edited version of Matt’s part0 comments follow:

Folks, here’s the queue of EFI material for v4.7. This is probably the biggest EFI pull ever sent, and there quite a few different topics covered. On the plus side the majority of new features (EFI Memory Attribute tables, EFI capsules, GOP framebuffer) are basically architecture independent, and some of the existing architecture-specific code has been generalised and moved to drivers/firmware/efi.

 * Drop the unused EFI_SYSTEM_TABLES efi.flags bit and ensure the ARM/arm64 EFI System Table mapping is read-only
 * Add a comment to explain that one of the code paths in the x86/pat code is only executed for EFI boot
 * Improve Secure Boot status checks on arm64 and handle unexpected errors
 * Remove the global EFI memory map variable ‘memmap’ as the same information is already available in efi::memmap
 * EFI Memory Attribute table support for ARM/arm64
 * EFI GOP framebuffer support for ARM/arm64
 * EFI Bootloader Control driver for storing reboot(2) data in EFI variables for consumption by bootloaders
 * Core EFI capsule support
 * EFI capsule char driver
 * EFI memory map code unification for ARM and arm64
 * Add generic EFI support for detecting when firmware corrupts cpu status register bits (like IRQ flags) when performing EFI runtime service calls

Ard Biesheuvel (19):
      efi: Get rid of EFI_SYSTEM_TABLES status bit
      efi/arm*: Drop writable mapping of the UEFI System table
      efi: Check EFI_MEMORY_DESCRIPTOR version explicitly
      efi/arm*: Use memremap() to create the persistent memmap mapping
      ARM: efi: Apply strict permissons for UEFI Runtime Services regions
      arm64: efi: Apply strict permissons for UEFI Runtime Services regions
      efi: Add support for the EFI_MEMORY_ATTRIBUTES_TABLE config table
      efi: Implement generic support for the Memory Attributes table
      efi/arm*: Take the Memory Attributes table into account
      x86/efi: Prepare GOP handling code for reuse as generic code
      efi/libstub: Move Graphics Output Protocol handling to generic code
      x86/efi: efifb: Move DMI based quirks handling out of generic code
      efifb: Use builtin_platform_driver and drop unused includes
      arm64/efi: libstub: Make screen_info accessible to the UEFI stub
      efi/arm: libstub: Make screen_info accessible to the UEFI stub
      efi/arm*: libstub: Wire up GOP protocol to struct screen_info
      efi/arm*: Wire up struct screen_info to efi-framebuffer platform device
      efifb: Enable the efi-framebuffer platform driver for ARM and arm64
      efi/arm-init: Reserve rather than unmap the memory map for ARM as well

Compostella, Jeremy (1):
      efibc: EFI Bootloader Control

Kweh, Hock Leong (1):
      efi: A misc char interface to update EFI firmware

Linn Crosetto (2):
      efi/arm64: Report unexpected errors when determining Secure Boot status
      efi/arm64: Check SetupMode when determining Secure Boot status

Mark Rutland (10):
      efi/runtime-wrappers: Add {__,}efi_call_virt templates
      arm64/efi: Move to generic {__,}efi_call_virt
      arm/efi: Move to generic {__,}efi_call_virt
      x86/efi: Move to generic {__,}efi_call_virt
      efi/runtime-wrappers: Remove redundant ifdefs
      efi/runtime-wrappers: Detect firmware irq flag corruption
      arm64/efi: Enable runtime call flag checking
      arm/efi: Enable runtime call flag checking
      x86/efi: Enable runtime call flag checking
      efi/runtime-wrappers: Remove ARCH_EFI_IRQ_FLAGS_MASK ifdef

Matt Fleming (7):
      x86/mm/pat: Document the (currently) EFI-only code path
      efi: Iterate over efi.memmap in for_each_efi_memory_desc
      efi: Remove global ‘memmap’
      x86/efi: Remove the always true EFI_DEBUG symbol
      efi: Move efi_status_to_err() to drivers/firmware/efi/
      efi: Capsule update support
      x86/efi: Force EFI reboot to process pending capsules

For the full patch, see the Linux-EFI mailing list archives:
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-next
http://vger.kernel.org/majordomo-info.html

U-Boot Verified Boot to get security improvements

~ hucktech ~ Leave a comment

Teddy Reed is proposing a change to U-Boot to support multiple levels of signing keys. Currently this is still at discussion phase, here’s Teddy’s initial post.

I’m looking to support “multiple levels” of keys within u-boot’s verified boot. I need something similar to UEFI’s key enrollment key (KEK) and db/dbx model such that I can support on-line signing of new kernels/rootfs/configurations. To make this work we need a KEK that is not online (kept in a safe), that can be used to sign expirations (revocations) of on-line signing keys in the case of compromise or private key reveals. I know Chrome’s Coreboot verified boot model supports this, wondering if there’s any staged / WIP for u-boot? Off the top of my head I’d imagine this requires extending the FIT to include sets of public keys and a blacklist of keys and expired or bad kernel/rootfs/etc hashes. Then either extending the boot code to inspect multiple FITs or extending mkimage to combine multiple sources to amalgamate a FIT containing the PK-signed set of keys + hashes and the on-line key-signed kernels/rootfs/configurations.

P.S. This may be strongly linked to the need for a TPM to prevent rollbacks. But as far as I can tell, the two features are distinct and a TPM is not completely required for a multi-level key approach to signing FITs.

Full post/thread:
http://lists.denx.de/mailman/listinfo/u-boot

AMD’s Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV)

~ hucktech ~ Leave a comment

Linux is about to get more secure on some AMD systems, it seems… Tom Lendacky of AMD submitted an 18-part patch to many of the Linux dev lists, to add support for AMD’s new Secure Memory Encryption (SME) feature, and to prepare for an upcoming Secure Encrypted Virtualization (SEV) patch.

SME can be used to mark individual pages of memory as encrypted through the page tables. A page of memory that is marked encrypted will be automatically decrypted when read from DRAM and will be automatically encrypted when written to DRAM. Details on SME can found in the links below. The SME feature is identified through a CPUID function and enabled through the SYSCFG MSR. Once enabled, page table entries will determine how the memory is accessed. If a page table entry has the memory encryption mask set, then that memory will be accessed as encrypted memory. The memory encryption mask (as well as other related information) is determined from settings returned through the same CPUID function that identifies the presence of the feature. The approach that this patch series takes is to encrypt everything possible starting early in the boot where the kernel is encrypted. Using the page table macros the encryption mask can be incorporated into all page table entries and page allocations. By updating the protection map, userspace allocations are also marked encrypted. Certain data must be accounted for as having been placed in memory before SME was enabled (EFI, initrd, etc.) and accessed accordingly.

This patch series is a pre-cursor to another AMD processor feature called Secure Encrypted Virtualization (SEV). The support for SEV will build upon the SME support and will be submitted later.

AMD Memory Encryption whitepaper:

Click to access AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer’s Manual:

Click to access 24593.pdf

SME is section 7.10
SEV is section 15.34

https://lkml.org/lkml/2016/4/26/1109
https://lkml.org/lkml/2016/4/26/1114
http://www.amd.com/en-us/innovations/software-technologies/security
http://www.amd.com/en-us/solutions/pro/security-manageability

For the patch, see the Linux-kernel or Linux-EFI (or other) lists:
http://vger.kernel.org/majordomo-info.html

Configurable or Secure, pick ONE

~ hucktech ~ Leave a comment

<soapbox>

Recently I posted a comment about a vendor who is starting to sign their firmware, which is good for security. Paul points out in the comments section of that post the other side of that situation, configurability:

Schneider to sign PLC firmware

Today, Brian of Intel’s UEFI team points out a story about new Apple laptops including tamper-resistant screws:

http://gizmodo.com/apple-will-know-if-youve-tampered-with-its-new-macbooks-1773045604

As Paul mentions in his comments, Google makes a ChromeBook targetting developers with a Developer Mode, a screw to turn to let you override firmware/OS security.
https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/chromebook-pixel-2015#TOC-Developer-Mode

I hope PC/smartphone/tablet/router/IoT vendors consider the situation of the consumer in a use case when the company abandons the product and no longer offers firmware/software updates, and the only person to refurbish the flaws in the unsupported firmware is the user, and they will need the ability to bypass the security features that only permit the company’s firmware from being loaded, or else the device will be a useless brick. The model that Google ChromeBooks have: a Developer Mode, may be the best option. If you are unsure about this, do an experiment with your next device, add a similar Developer Mode it to some models, and charge a bit more for hobbyists, and see if there is a market. Abandoned products aside, advanced users can build better firmware/software than you can, look at how the camera hackers have added features the vendor never thought of? This is another way you can grow the ecosystem and popularity of your device, and generate more sales/profit. Don’t seal all devices in the name of security, please.

</soapbox>

Routersploit

~ hucktech ~ Leave a comment

Routesploit is like Metasploit, written in Python, not Ruby, taretting embedded devices.

It consists of various modules that aids penetration testing operations:
* exploits – modules that take advantage of identified vulnerabilities
* creds – modules designed to test credentials against network services
* scanners – modules that check if target is vulnerable to any exploit

https://github.com/reverse-shell/routersploit

RouterSploit – Router Exploitation Framework
byu/lucyoa innetsec

https://asciinema.org/a/8u75xcjuacnbpwz9feaixde9e?autoplay=1

LibC library musl ported to UEFI

~ hucktech ~ Leave a comment

Michael Zimmerman, one of the main developers behind EFIDroid, also has another interesting UEFI side project: uefi-musl-toolchain, a port of the LibC library musl to UEFI!

Quoting Wikipedia, musl is “a C standard library intended for operating systems based on the Linux kernel, released under the MIT License. It was developed by Rich Felker with the goal to write a clean, efficient and standards-conformant libc implementation. It is designed from scratch to allow efficient static linking and to have realtime-quality robustness by avoiding races, internal failures on resource exhaustion and various other bad worst-case behaviours present in existing implementations. The dynamic runtime is a single file with stable ABI allowing race-free updates and the static linking support allows an application to be deployed as a single portable binary without significant size overhead. It claims compatibility with the POSIX 2008 specification and the C11 standard. It also implements most of the widely used non-standard Linux, BSD, and glibc functions.

On his musl port to UEFI, Michael says:

I ported the libc alternative musl to UEFI by replacing the syscalls with simple function calls to library and wrote a GCC wrapper. The system call table is still incomplete but this way I can compile any (single-threaded) application for UEFI. This currently works on ARM only, but just because this is the platform I am interested in, not because it wouldn’t be possible.

This is fresh code, the project is only 2 days old. 🙂

https://github.com/M1cha/uefi-musl-toolchain

Example of busybox on UEFI compiled using musl: http://pastebin.com/MRXdBjyN

https://www.musl-libc.org/

 

Hyper-V Chromium bug status

~ hucktech ~ Leave a comment

Kostya Kortchinsky pointed out some Hyper-V bugs recently fixed in Chromium, all 3 are listed as being fixed 4 days ago.

https://bugs.chromium.org/p/project-zero/issues/detail?id=688
Hyper-V vmswitch.sys VmsMpCommonPvtHandleMulticastOids Guest to Host Kernel-Pool Overflow

https://bugs.chromium.org/p/project-zero/issues/detail?id=689
Hyper-V vmswitch.sys VmsVmNicHandleRssParametersChange OOBR Guest to Host BugChecks

https://bugs.chromium.org/p/project-zero/issues/detail?id=690
Hyper-V vmswitch.sys VmsPtpIpsecTranslateAddv2toAddv2Ex OOBR Guest to Host BugCheck

CANtoolz: diff moded to mod_stats

~ hucktech ~ Leave a comment

Version 1.5.5 of Alexey Sintsov’s car hacking tool CANToolz has a new feature for analyzing CAN traffic:

 CANToolz: mod_stat – diff mode

Small updates in CANToolz in version 1.5-0: Have added DIFF mode to mod_stats module. This can be useful if you want to find what frames are new in the traffic. For example you have traffic dump, then you enable diff mode and do some action, like door unlock. Just after that you can press “print diff” and see all CAN frames that were found in the CAN BUS after enabling  DIFF mode but not before. Of course there will be a lot of unneeded traffic as well, but  anyway it should help to reduce amount of traffic for manual analysis. If you press “print DIFF (ID only)” then you will see only those CAN frames that have not known (in original dump, before diff mode enabled) arbitration ID. When you disable DIFF mode, all CAN frames will me merged to original mod_stat buffer, so you can repeat this action again and again… Finally you can DUMP diff frames and replay. This hould work faster then “binary search”.

Full post:
http://asintsov.blogspot.de/2016/04/cantoolz-modstat-diff-mode.html

OSR on Windows IoT on Rasberry PI 3

~ hucktech ~ Leave a comment

Peter at OSR has a new blog post about using Embedded Windows — now called Windows IoT — on a Rasberry PI3, with a lot of advice for embedded Windows developer using this beta platform.

[…] You can’t connect WinDbg to the RPI 3 via the network.  You have to use the serial port.  To be successful in this endeavor, you’ll need a super-secret TTL to USB Serial Port cable (this one from Adafruit works just dandy).  […]

Secrets of Using Win10 IoT Core on the RPI 3 (and staying sane)

If you do Windows, and have not looked at OSR’s online resources, it is worth a look, they have some tools that beat SysInternals, and the NTDev mailing list is probably the best public source of NT experienced developers, and one of the few places outside MSDN blogs that Microsoft developers publicly post technically useful information:
http://www.osronline.com/section.cfm?section=27
http://www.osronline.com/cf.cfm?PageURL=showlists.cfm?list=NTDEV

LibIPT – Intel Processor Trace Decoder Library

~ hucktech ~ Leave a comment

libipt – an Intel(R) Processor Trace decoder library

The Intel Processor Trace (Intel PT) Decoder Library is Intel’s reference implementation for decoding Intel PT.  It can be used as a standalone library or it can be partially or fully integrated into your tool. The library comes with a set of sample tools built on top of it and a test system built on top of the sample tools.  The samples demonstrate how to use the library and may serve as a starting point for integrating the library into your tool.

Processor Trace を使ってデバッグ時に詳細なトレースを取得する


https://github.com/01org/processor-trace
https://software.intel.com/en-us/intel-platform-analysis-library

Kansa: incident response framework for Windows Powershell

~ hucktech ~ Leave a comment

I saw one of the speakers of Kansa recently, speaking about their project. Bryan tweeted about that talk:

[…] Kansa is a modular incident response framework in Powershell. It uses Powershell Remoting to run user contributed, ahem, user contributed modules across hosts in an enterprise to collect data for use during incident response, breach hunts, or for building an environmental baseline. […]

Kansa kindof reminds me of a Windows-centric, PowerShell-centric version of OSquery. 🙂 It runs a remote powershell with various scripts on all the remote systems, and gathers the data into CSVs for analysis. It has multiple plugins. IMO, it needs many new firmware-related plugins (eg, one for the x-UEFI Configuration Database, etc.).

More info:
https://github.com/davehull/Kansa
http://trustedsignal.blogspot.com/search/label/Kansa
http://www.powershellmagazine.com/2014/07/18/kansa-a-powershell-based-incident-response-framework/