Click to access pentium-celeron-n-series-j-series-datasheet-vol-1.pdf
Click to access pentium-celeron-n-series-j-series-datasheet-vol-2.pdf
Click to access pentium-celeron-n-series-j-series-datasheet-vols-3.pdf
Category: Uncategorized
Super Mario Bros (NES emulator) ported to UEFI
David Lee has apparently ported a NES emulator — without sound — to UEFI, but source code is not apparently available:
I used EDK II framework.
About the keyboard input, Program reads the value from 0x60 port directly because of multi-key input processing.
I measure the timer count twice(for 1sec) by using the rdtsc instruction to make game delay more accurate.
I didn’t implement the audio output.
Forensic info on exFAT timestamps: first of a series of blog posts
Cisco: Self-Encypting Drive firmware issue
“A drive firmware issue on select Self-Encrypting Drives (SEDs) might cause an operational issue for some Unified Computing System (UCS) servers and HyperFlex clusters.”
https://www.cisco.com/c/en/us/support/docs/field-notices/702/fn70234.html?emailclick=CNSemail
HP iLO: a bit more on CVE-2017-12542
Some notes on Exploiting HPE iLO4 Authentication Bypass and RCE (CVE-2017-12542)
https://support.hpe.com/hpsc/doc/public/display?docId=hpesbhf03769en_us
https://www.rapid7.com/db/modules/auxiliary/admin/hp/hp_ilo_create_admin_account
https://tools.cisco.com/security/center/viewAlert.x?alertId=54930
https://github.com/skelsec/CVE-2017-12542
Dell seeks Vulnerability Researcher
- Responsible for discovering and exploiting vulnerabilities affecting Dell software and firmware
Drop-EFI: Mac “droplet” GUI dock for EFI’s ESP
Drop EFI is a super Droplet for Mount any EFI Partition on macOS
Working for HFS+J, APFS, NTFS GPT, Core Storage volumes.
https://github.com/chris1111/Drop-EFI
efiboot-rs: efivar and efiboot UEFI tools in Rust
This repository contains the source code for:
* efivar – A Rust crate to read and write EFI variables
* efiboot – A command-line tool to manage the UEFI boot manager
SiFive: DDR controller configuration register values unleashed!
Re: https://firmwaresecurity.com/2018/06/25/risc-v-implementations-filled-with-blobs/
https://forums.sifive.com/t/ddr-controller-configuration-register-values-for-hifive-unleashed/1334/8
Comment from SiFive:
SiFive is committed to supporting the open-source community. We are pleased to report that after discussions with our IP partners, we are now able to make available all the source code required to initialize the HiFive Unleashed board. The board’s boot sequence is described in the manual. The assembly code in the initial reset ROM is listed in the manual Chapter 6.1 “Reset Vector”. The firmware in the ZSBL mask ROM is directly readable by software on the chip, and we will be making the full source code available shortly. The source code for FSBL including the DDR initialization will also be available shortly. We can attest there is no other firmware run by the system during boot.
SystemBoot: a LinuxBoot distro that works as a system firmware + bootloader, based on u-root
SystemBoot is a distribution for LinuxBoot to create a system firmware + bootloader. It is based on u-root. The provided programs are:
* netboot: a network boot client that uses DHCP and HTTP to get a boot program based on Linux, and uses kexec to run it
* localboot: a tool that finds bootable kernel configurations on the local disks and boots them
* uinit: a wrapper around netboot and localboot that just mimicks a BIOS/UEFI BDS behaviour, by looping between network booting and local booting. The name uinit is necessary to be picked up as boot program by u-root.
This work is similar to the pxeboot and boot commands that are already part of u-root, but approach and implementation are slightly different. Thanks to Chris Koch and Jean-Marie Verdun for pioneering in this area. This project started as a personal experiment under github.com/insomniacslk/systemboot but it is now an effort of a broader community and graduated to a real project for system firmwares.[…]
Tetris game for UEFI in x64 assembler
Re: https://firmwaresecurity.com/2018/02/19/uefimarkebcedition-uefi-byte-code-ebc-benchmark-utility/
GRAPHICAL TETRIS. UEFI X64 EDITION. MAIN MODULE.
SEPARATE EDITION = TETRIS WITHOUT UEFIMARK.
(C)2013-2017 IC Book Labs.
https://github.com/manusov/UEFImarkAndTetris64/blob/master/source/TETRIS.ASM
Not to be confused with the other UEFI Tetris:
Ubuntu: DKMS modules need to be configured to work with UEFI Secure Boot
I just noticed this nice document on Ubuntu security features, maybe it is new, maybe I never noticed it before:
https://wiki.ubuntu.com/Security/Features#secure-boot
I also notice this page, which I believe has recently been updated:
DKMS modules need to be configured to work with UEFI Secure Boot
Ubuntu is now checking module signing by default, on kernels 4.4.0-18.34, 4.4.0-21.37, 4.2.0-42.49, 3.19.0-65.73 and 3.13.0-92.139 onwards. You can read more details in this bug in Launchpad. Because of those changes, DKMS modules will not work on systems with Secure Boot enabled unless correctly configured. In order to make DKMS work, Secure Boot signing keys for the system must be imported in the system firmware, otherwise Secure Boot needs to be disabled. There are several methods to configure your system to properly load DKMS modules with Secure Boot enabled.
https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1566221
Apple: periodic reminder: set your firmware password
Google Android: Pixel firmware security updates
[…]To prevent attackers from replacing our firmware with a malicious version, we apply digital signatures. There are two ways for an attacker to defeat the signature checks and install a malicious replacement for firmware: find and exploit vulnerabilities in the signature-checking process or gain access to the signing key and get their malicious version signed so the device will accept it as a legitimate update. The signature-checking software is tiny, isolated, and vetted with extreme thoroughness. Defeating it is hard. The signing keys, however, must exist somewhere, and there must be people who have access to them.[…]
https://security.googleblog.com/2018/06/insider-attack-resistance.html
REcon Montreal 2018: slides uploaded
Winbagility project: simulates a debugged kernel
https://github.com/Winbagility/Winbagility
https://github.com/Winbagility/Winbagility/tree/master/bindings/python
Winbagility is a tool that gives you ability to connect WinDbg on non /DEBUG Windows x64 systems. Winbagility simulates a debugged kernel. It retrieves over the STUB for some essentials information (KDBG, KPCR…) and forward these informations to WinDbg over KD.
PyFDP is a Python extension used to communicate with the FDP (Fast Debugging Protocol) hypervisor-based debugging server used in the Winbagility project. Winbagility introduced an instrumented version of VirtualBox which can be used to implement a sthealth debugger via Virtual Machine introspection and runtime analysis. While Winbagility simply connect the FDP server to Windbg in order to debug a Windows VM as if the guest was launch with /DEBUG option activated, anyone can write a FDP client. PyFDP expose the FDP client side by wrapping the DLL’s exports via ctypes, enabling any Python program to script a VM debugging session.
Threat Detection using Windows Defender Application Control (Device Guard) in Audit Mode
https://twitter.com/mattifestation/status/1011569106347286528
https://twitter.com/subTee/status/1011318358917165057
Matt Graeber
Security Researcher, SpecterOps
Jun 26
Note: I originally scrapped this post because I didn’t like that audit events were only logged once per boot due to caching, however, Casey’s tweet reminded me that I shouldn’t let perfect be the enemy of good. This is still one of the best options that I know of (without requiring a commercial solution) to log all driver loads.[…]
RAMpage: 4 Rowhammer variants for Android (with logos and own web site)
CVE-2018-1000205: U-Boot, Verified Boot input validation
Re: https://firmwaresecurity.com/2018/06/26/cve-2018-1000205-u-boot/
and https://firmwaresecurity.com/2018/06/07/teddy-reed-on-u-boots-verified-boot/
There is now a description for the CVE. Ah, this makes sense, the Verified Boot issues that Teddy Reed brought up earlier:
U-Boot contains a CWE-20: Improper Input Validation vulnerability in Verified boot signature validation that can result in Bypass verified boot. This attack appear to be exploitable via Specially crafted FIT image and special device memory functionality.
https://nvd.nist.gov/vuln/detail/CVE-2018-1000205
https://lists.denx.de/pipermail/u-boot/2018-June/330454.html
https://lists.denx.de/pipermail/u-boot/2018-June/330898.html
Firmware Security 
You must be logged in to post a comment.