Christian Ludloff’s sandpile has existed for a while, yet I was talking to someone yesterday who never heard of it. Nice site for x86 information:
Similarly, Thomas’s ChipDB is another great source of information for various chips:
Category: Uncategorized
iOS App Reverse Engineering book
This is my gift to the jailbreak community as a 5-year n00b, enjoy! iOS App Reverse Engineering is the world’s 1st book of very detailed iOS App reverse engineering skills, targeting 4 kinds of readers:
* iOS enthusiasts;
* Senior iOS developers, who have good command of App development and have the desire to understand iOS better;
* Architects. During the process of reverse engineering, they can learn architectures of those excellent Apps so that they can improve their ability of architecture design;
* Reverse engineers in other systems who’re also interested in iOS.
The book consists of 4 parts, i.e. concepts, tools, theories and practices. The book follows an “abstraction, concrete, abstraction, concrete” structure, starting from basic concepts like iOS filesystem hierarchy and iOS file types that Apple didn’t expose to App developers but iOS (jailbreak) researchers should know, then goes through the most commonly used tools like class-dump, Theos, Cycript, Reveal, IDA and LLDB to introduce what to do in iOS reverse engineering. After that, iOS reverse engineering theories based on Objective-C and ARM assembly are explained in a methodological way, pointing out the core of this book. Last but not least, 4 originally elaborated practices are there to cover all previous contents of the book and give you the most intuitive perception of iOS reverse engineering. Happy hacking!
tool: Subzero
Teddy Reed, author of UEFI Firmware Parser, and UEFI Spider, also has a related project called Subzero. Excerpting the readme:
The project includes both a web interface and a set of importing and map/reduction scripts used for vulnerability analysis on Firmware Updates (specifically those parsed by uefi-firmware-parser.) The import of firmware is complimented with the descriptions and metadata mined from uefi-spider in JSON form. This web interface will eventually include a submission form used to detect/match unknown updates against the corpus of imported data.
Requirements:
* RethinkDB (python rethinkdb)
* ssdeep (pydeep)
* python-magic
* Ruby/Rails (and the associated gems)
* uefi-spider
* uefi-firmware-parser.
Firmware import: The importing process uses 4 steps, and assumes you have downloaded or crawled firmware update either from vendors or an enterprise: (1) Importing metadata about the updates; (2) Parsing and importing a hierarchy of components within a single firmware update; (3) Comparing product updates and vendor statistics; (4) Scheduling map/reductions to generate statistics on the firmware corpus. Step 2 is quite involved and uses multiple scripts specific to each vendor supported by Subzero. Since each vendor distributes their firmware uniquely, these scripts must preprocess and extract firmware components such as flash descriptors, UEFI Volumes, or other non-monolithic blobs for import. Once this data is isolated Subzero can use specifications and standards (and a lot of python) to parse each subcomponent and store the binary content and hierarchy of relations (a tree).
Features:
* WebUI display of UEFI, Flash, and other firmware formats.
* Graph-views of vendor update frequency, metadata, and firmware changes.
* Vulnerability analysis through a variety of techniques.
* Export and download of firmware components.
Supported Vendors: ASRock, Dell, Gigabyte, Intel, Lenovo, HP, MSI, VMware
https://github.com/theopolis/subzero
Intel 01.org Thunderbolt project
I just noticed a Thunderbolt software project on 01.org, the Intel Open Source project site:
https://01.org/thunderbolt-sw/blogs/mjamet/2015/thunberbolt-software-15.32
The last release was a few months ago. However, this is not a normal open source project. It is “restricted open source”, only only for Thunderbolt vendors, not the public.
The code can be accessed from the restricted Git Hub at: https://github.com/01org/thunderbolt-software
An access can requested at thunderbolt-linux@intel.com only for manufacturers having a valid Thunderbolt technology license.
https://01.org/thunderbolt-sw/
https://github.com/01org/thunderbolt-software
https://lists.01.org/mailman/listinfo/thunderbolt-software
https://thunderbolttechnology.net/
https://thunderbolttechnology.net/news/press
x86 Bare Metal Examples project
The x86-bare-metal-examples project:
https://github.com/cirosantilli/x86-bare-metal-examples
This is a new collection of of “Hello world programs that run without an operating system. Keywords: bare bones, boot sector, MBR, BIOS, UEFI, VGA, Multiboot, QEMU.”
It is a new project, but there’s already multiple programs. The readme has links to multiple information sources.
650 Mini Maker Faires in November at Barnes and Noble
Make has partnered with Barnes & Noble to bring the The Barnes & Noble Mini Maker Faire”, to 650 of their stores domestic stores for the weekend of November 6 to 8. The application deadline is Friday, October 2, 2015. Each store will have:
* The Make Workspace: An area to experience the latest technologies in 3D printing, robotics, coding, programming, and more.
* Meet the Makers: A special area will be set up in each store for Makers to showcase their projects. You’ll also be able to apply to get more deeply involved with the Maker community.
* Make & Collaborate: Get hands-on with Making, sharing, and collaborating.
More Info:
http://www.barnesandnoble.com/blog/announcing-the-barnes-noble-mini-maker-faire-november-6-8-2015/
Barnes & Noble aside, there are multiple Maker Faires, and many Mini Maker Faires in multiple cities:
http://makerfaire.com/map/
VZ on Intel STM
Vincent Zimmer of Intel wrote a blog on recent Intel UEFI activities relating to open source. He talks about a few things, including “SMI Transfer Monitor (STM)”, recently announced at Intel Developer Forum. I briefly posted on STM, but barely mentioned any details, better points to information are in Vincent’s current post. I hope to see vendors using this powerful technology in the future.
https://firmware.intel.com/blog/developing-best-class-security-principles-open-source-firmware
Hardware Hacking Tools from OSBridge
Joe Grand of Grand Idea Studios gave a presentation at OSBridge the other week, video is now online:
Open Source Tools of the Hardware Hacking Trade
Joe Grand
Many embedded systems contain design flaws that could lead to exploitable vulnerabilities. In order to discover such flaws, hackers and engineers use a specific set of tools. In this session, Joe will discuss his favorite open source hardware hacking and reverse engineering tools, including those that monitor/decode digital communications, extract firmware, inject/spoof data, and identify/connect to debug interfaces.
More Info:
http://confreaks.tv/videos/osbridge2015-open-source-tools-of-the-hardware-hacking-trade
http://opensourcebridge.org/events/2015/schedule
http://www.grandideastudio.com/
AMD Secure Processor
AMD recently posted on Twitter about giving answers to IT security pros:
It points to a video on the AMD Secure Processor:
More Information on AMD’s security plans:
http://www.amd.com/en-us/innovations/software-technologies/security
https://community.amd.com/community/amd-corporate/blog/2015/05/11/amd-s-security-strategy-decreasing-digital-dangers
https://community.amd.com/community/amd-business/blog/2015/09/11/securing-the-data-center-from-the-silicon-up
(I hope part of AMD’s security plans also include provide us a tool like — or a port of — CHIPSEC, to help their partners ship secure systems, and for owners to verify the systems’ firmware vulnerabilities, initially, and over time. Personally, I’ve found that once you have a tool like that to help you with HW/FW verification, you get nervous running a system with a CPU that doesn’t have without similar tools to verify that system. Dealing with security at design-time is nice, but having a run-time tool to test things is also very nice.)
GDB Dashboard: Python visual UI
Modular visual interface for GDB in Python. This comes as a standalone single-file .gdbinit which, among the other things, enables a configurable dashboard showing the most relevant information during the program execution. Its main goal is to reduce the number of GDB commands issued to inspect the current program status allowing the programmer to focus on the control flow instead.
UEFI DMA attack research and code
Dmytro Oleksiuk (@d_olex) just wrote up some very interesting UEFI security blog post, with CHIPSEC-based sample code!
Breaking UEFI security with software DMA attacks
Hi everyone! In this article I’d like to tell you more about UEFI vulnerabilities exploitation. Last time, in “Exploiting UEFI boot script table vulnerability” blog post I shown how to execute arbitrary shellcode during early PEI phase which allows to bypass security mechanisms that protects System Management Mode memory (SMRAM) from DMA attacks. Now we will perform such DMA attack on SMRAM to disable BIOS_CNTL flash write protection — it will give us the ability to write infected firmware to ROM chip on the motherboard. This attack can be used for installation of my SMM backdoor without having physical access to the target machine (in previous blog post I explained how it works and how to install it using hardware programmer). My software DMA attack approach for Linux operating system hijacks physical address of DMA buffer used by disk driver, concept of such attack originally was presented in BH US 2008 talk by Rafal Wojtczuk “Subverting the Xen hypervisor”.
http://blog.cr4.sh/2015/09/breaking-uefi-security-with-software.html
sysadmin slides from last night
As mentioned earlier:
http://www.sasag.org/2015/08/14/sept-10th-mtg-defending-intel-uefi-systems-from-firmware-attackers/
Last night I gave a talk on UEFI firmware security for a sysadmin POV. This presentation was my first attempt at trying to gather the various hardware lifecycle models into one place, and start adding NIST firmware-centric platform lifecycle as well as currently-available firmware vulnerability assessment an forensic tools to accomplish these new tasks. The models are not well integrated yet. I’ll be giving an improved version of this talk next month at SeaGL.org, and will try to have the model section more clearly written.
On the QEMU/OVMF slide, I say “no danger of bricking hardware”. …I should clarify that. 🙂 By that I meant using fully virtualized environment, there’s no hardware to break. However, you can also use QEMU/OVMF to debug actual hardware (eg, USB devices, PCI cards, etc.), since QEMU can proxy some requests to direct hardware. ….so, you could potentially ‘brick’ some hardware (eg, USB devices, PCI cards, etc.) with QEMU/OVMF, if you’re doing tricky things, and not careful.
NISTs 147 has basic guidance, as well as some ‘extra’ guidance for organizations that want to do more, like keeping a ‘golden image’ of the firmware. (When I first read the 147 spec, I thought the Provisioning stage was a stage for the OEM/IBV and their CAs, not for an enterprise sysadmin…) As I understand it, any ‘golden image’ would be source code, not precompiled firmware ROM binaries. I presume NIST spec was written in to an abstract model, where firwmware sourcecode is fully-available. I presume some governments and large companies would be able to obtain the full source of their firmware from the ISA/OEM/IHV vendors, and do a ‘golden image’. For the rest of world, we have nearly 100% closed-source IBV code, so you can’t do this ‘golden image’-based extra level of guidance.
On Intel systems, the Intel Firmware Support Package (FSP) contains binary-only code (‘blobs’) that UEFI and coreboot use to work on modern Intel systems; unless you have the FSP source, I don’t think an org could do the NIST 147 ‘golden image’ stuff. Some ARM systems, and perhaps AMD with it’s AGESA firmware package, might have more chance at fewer blobs. Fully Open Source Hardware/Firmware/Software-based stacks would enable ‘golden image’, so FOSS has one advantage at NIST 147 support than closed source HW/FW/SW. So Novena and any Libreboot-based system would be good, any modern Intel-based system (including Purism) will not be able to do ‘golden image’ provisioning. Pragmatically, I think the best most of us can do today for the NIST 147 Provisioning stage is run CHIPSEC/FWTS tests against it, and use CHIPSEC or other tools to capture the ROM, and that ROM.bin will be as close as you can get to a ‘golden image’.
Similarly, in the Recovery phase, I’m not sure that most orgs would be able to restore a system with a ROM dump today, without more tool documentation. Instead, I presume any ROM updates are going to be coming from your vendor, using the UEFI update mechanism. If your vendor’s update tools has the ability to ‘roll-back’ to an old image, you’re lucky.
I’d love to get feedback from sysadmins and other vendors about errors in the presentation, hopefully before SeaGL.org, for next revision.
Beyond this talk, LegbaCore has great advise for sysadmins using MITRE Copernicus for Windows enterprises. Copernicus, unlike CHIPSEC, scales, see the LegbaCore talk from RSA 2015.
IC3 on IoT device security
Via US CERT, the Internet Crime Complaint Center (IC3) has a new document on embedded device security risks:
IC3 Issues Alert on IoT Devices: The Internet Crime Complaint Center (IC3) has issued an alert to individuals and businesses about the security risks involved with the Internet of Things (IoT). IoT refers to the emerging network of devices (e.g., smart TVs, home automation systems) that connect to one another via the Internet, often automatically sending and receiving data. US-CERT encourages individuals and businesses to review the IC3 Alert for more information regarding IoT vulnerabilities and mitigation techniques.
Excerpt:
What are the IoT Risks? Deficient security capabilities and difficulties for patching vulnerabilities in these devices, as well as a lack of consumer security awareness, provide cyber actors with opportunities to exploit these devices. Criminals can use these opportunities to remotely facilitate attacks on other systems, send malicious and spam e-mails, steal personal information, or interfere with physical safety. The main IoT risks include:
* An exploitation of the UPnP protocol to gain access to many IoT devices. The UPnP describes the process when a device remotely connects and communicates on a network automatically without authentication. UPnP is designed to self-configure when attached to an IP address, making it vulnerable to exploitation. Cyber actors can change the configuration, and run commands on the devices, potentially enabling the devices to harvest sensitive information or conduct attacks against homes and businesses, or engage in digital eavesdropping;
* An exploitation of default passwords to send malicious and spam e-mails, or steal personally identifiable or credit card information;
* Compromising the IoT device to cause physical harm;
* Overloading the devices to render the device inoperable;
* Interfering with business transactions.
Full announcement:
https://www.us-cert.gov/ncas/current-activity/2015/09/11/IC3-Issues-Alert-IoT-Devices-0
KVM Forum 2015 materials available
[[ UPDATE: WordPress mangles the below URL to Pauolo’s SMM talk. Download the PDF from the linux-kvm.org link below instead. ]]
The KVM Forum recently finished, and their post-conference materials are available, including videos of some of the presentations. There are multiple interesting talks on QEMU and KVM for security researchers. Two talks that jump out to me are:
Securing secure boot: system management mode in KVM and Tiano Core
by Paolo Bonzini
Click to access 03×06-Aspen-Paolo_Bonzini-Securing_secure_boot.pdf
Using IPMI in QEMU
by Corey Minyard
Click to access 03×08-Juniper-Corey_Minyard-UsingIPMIinQEMU.ods.pdf
More Information:
http://www.linux-kvm.org/page/KVM_Forum_2015
Hospitals barred from warning of embedded device flaws
Darius Tahir posted this story on Politico today.
Doctors barred from discussing safety glitches in U.S.-funded software
Excerpt:
A POLITICO investigation found that some of the biggest firms marketing electronic record systems inserted “gag clauses” in their taxpayer-subsidized contracts, effectively forbidding health care providers from talking about glitches that slow their work and potentially jeopardize patients. POLITICO obtained 11 contracts through public record requests from hospitals and health systems in New York City, California, and Florida that use six of the biggest vendors of digital record systems. With one exception, each of the contracts contains a clause protecting potentially large swaths of information from public exposure. This is the first time the existence of the gag clauses has been conclusively documented. Vendors say such restrictions target only breaches of intellectual property and are invoked rarely. But doctors, researchers and members of Congress contend they stifle important discussions, including disclosures that problems exist. In some cases, they say, the software’s faults can have lethal results, misleading doctors and nurses who rely upon it for critical information in life-or-death situations.
Full story:
http://www.politico.com/story/2015/09/doctors-barred-from-discussing-safety-glitches-in-us-funded-software-213553
‘Machines that go bing’ sound less trustworthy every day…
Secure Boot for USBArmory
[[ UPDATE: Earlier I called this “UEFI Secure Boot”. Vincent Zimmer of Intel read their blog article more closely than I did, read the comment he just made: click on the “Comment” link on the left side of the blog, At the moment, I am not sure what flavor(s) of “Secure Boot” InversePath is using for the USB Armory. ]]
InversePath has updated the USB Armory to support Secure Boot (unclear what kind of “Secure Boot” this is..
Interesting read to see what is involved in getting Secure Boot to work, even if you don’t have one of these devices. I like the disclaimer:
IMPORTANT: enabling Secure Boot functionality on the USB armory SoC, unlike similar features on modern PCs, is an irreversible action that permanenty fuses verification keys hashes on the device. This means that any errors in the process or loss of the signing PKI will result in a bricked device uncapable of executing unsigned code. This is a security feature, not a bug. The activation and use of the Secure Boot functionality is therefore at your own risk and must be approached with care.
Intel XED
Intel has a library to help encode/decode instructions, called the Intel(R) XED (X86 Encoder Decoder). I’ve yet to determine if it its PE image support also includes supports UEFI’s TE image format.
Intel XED is a software library (and associated headers) for encoding and decoding X86 (IA32 and Intel64) instructions. It is widely used inside and outside of Intel. The decoder takes sequences of 1-15 bytes along with machine mode information and produces a data structure describing the opcode and operands, and flags. The encoder takes a similar data structure and produces a sequence of 1 to 15 bytes. Disassembly is essentially printing pass on the data structure produced by the decoder. The examples also include binary image readers for Windows PECOFF, ELF, and Mac OSX MACHO binary file formats (32b and 64b). These allow Intel XED to be used as a simple disassembler. The Intel XED disassembler supports 3 output formats: Intel (dest on left), ATT SYSV (dest on right), and a more detailed internal format describing all resources read and written. Intel XED compiles with all major compilers and O/Ses and was designed for portability. If required, Intel XED can be built without the encoder or without the decoder to reduce the code/data footprint. The code in the Intel XED library is written in C and is partially generated from tables using python scripts at build time. Intel XED is designed for embedding and has a minimal set of simple external dependencies. It makes no system calls and allocates no memory. It is multithread-safe after one-time initialization of the tables. Both the 32b and 64b versions of the library can decode or encode 32b and 64b instructions. The machine mode for decoding the instructions is specified in a data structure that is input to the encoding and decoding APIs.
https://software.intel.com/en-us/articles/xed-x86-encoder-decoder-software-library
https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool
https://software.intel.com/sites/landingpage/xed/ref-manual/html/index.html
Securifi Almond routers contains multiple vulnerabilities
CERT has issues Vulnerability Note VU#906576 on Securifi Almond routers.
Excerpt of VU#906576:
CWE-330: Use of Insufficiently Random Values – CVE-2015-2914
CWE-319: Cleartext Transmission of Sensitive Information
CWE-255: Credentials Management – CVE-2015-2915
CWE-352: Cross-Site Request Forgery (CSRF) – CVE-2015-2916
CWE-20: Improper Input Validation – CVE-2015-2917
Securifi Almond, firmware version AL1-R200-L302-W33 and earlier, and Securifi Almond 2015, firmware version AL2-R088 and earlier, contain multiple vulnerabilities. A remote, unauthenticated attacker may be able to spoof DNS responses to cause Almond LAN clients to contact attacker-controlled hosts or induce an authenticated user into making an unintentional request to the web server that will be treated as an authentic request. Securifi has released firmware versions to address these vulnerabilities. Almond users should upgrade to AL1-R201EXP10-L304-W34 or later. Almond 2015 users should upgrade to AL2-R088M or later. Note that the firmware updates mitigate the CSRF and clickjacking vulnerabilities by disabling the web management interface. Users may still enable web management from the Almond touch screen controls, but doing so will render their devices vulnerable. The CERT/CC is currently unaware of a practical solution to this problem and recommends the following workaround.
http://www.kb.cert.org/vuls/id/906576
https://firmware.securifi.com/AL1/AL1-R201EXP10-L304-W34
https://firmware.securifi.com/AL2/AL2-R088m
44con presentations available
44con just finished. I didn’t mention this event earlier, but it included a few interesting presentations and workshops:
Is there an EFI monster inside your apple?
Pedro Vilaça
Hands-on JTAG for fun and root shells
Joe FitzPatrick
Pen Test Partners IoT Workshop
Dave Lodge
http://www.slideshare.net/44Con
Hacking Team analysis
Ethan Heilman has written a nice document researching the core-packer that the Hacking Team’s malware uses.
We investigate how Italian malware vendor Hacking Team obfuscated
their malware, specifically the custom software they developed for
this task called core-packer. This analysis was a joint project
between Will Cummings (@dubbelyew) and Ethan Heilman (@Ethan_Heilman).
Core-packer’s first commit is Oct 2012, nine days after Citizen Lab
released a report “Backdoors are Forever: Hacking Team and the
Targeting of Dissent?” on Hacking Team’s malware. It seems likely that
core-packer was developed to prevent future disclosures by increasing
the stealth of Hacking Team’s malware. In fact in response to the
Citizen Lab they wrote talking points to assure their clients that
malware was safe to use. One of these talking points was that they
were implementing “technical measures”, perhaps referring to
core-packer.
Hmm, WordPress embeds the entire article if I use the URL as-is, so I’ll split the URL in half, you’ll have to recombine it, sorry.
http://ethanheilman.tumblr
.com/post/128708937890/a-brief-examination-of-hacking-teams-crypter
Firmware Security 
You must be logged in to post a comment.