UEFITool is useful, so I was looking into OZMTool, a fork of UEFITool, and was wondering what new features it has, what Ozmosis BIOSes were, and how I might be able to use this tool. Unfortunately, it looks like the PNWFHW (Pacific NorthWest FirmWare Hackers) stickers likely won’t arrive in time, probably next week, so no stickers this time, sorry. One potential direction for the lab is to look at Intel’s analysis of the Hacking Team’s UEFI malware, and how to use CHIPSEC and UEFITool, using the GUIDs and strings from the below analysis to see if you have Hacking Team bootkit. For Linux, no binaries provided, you must build from source. If you don’t want to install Qt on your system, you can download pre-built binaries of UEFITool for Windows and Mac OSX. UEFITool builds on most platforms pretty painlessly. You need to get Qt Creator installed, open Qt Creator, open the UEFI Tools’s. Most of these tools are Python-based, but UEFITool is a C++-based Qt GUI app. Install any of the below tools if you want to use these to examine ROMs: CHIPSEC and most of the below tools are Python-based, so install CPython 2.7x on your system. If you are willing to share some ROMs with the rest of the lab attendees, please try to bring a system with a CD-R/DVD-R burner. The lab will be fairly free-form, people trying to use CHIPSEC on their system, hopefully to save a ROM and share with others, and to some analysis of the ROM using CHIPSEC, UEFITool, UEFI Firmware Parser. Regardless, please don’t use your primary laptop, backup anything important, in case you brick the box. Or, instead of running CHIPSEC from w/i your installed OS, make your own LUV-live thumbdrive and see if it works on your system: if so, use CHIPSEC there. Watch the Youtube video of DEFCON22 talk on CHIPSEC to see when/why to use some of it’s commands. Only load it when you are using CHIPSEC.) I’ll bring some scripts to make it easier to use CHIPSEC on Linux systems. (The CHIPSEC kernel driver is not a safe thing to keep loaded, see their warning.txt. So please bring a Intel UEFI-based laptop running Windows or Linux, where you can install CHIPSEC on it. So let’s use CHIPSEC installed natively on your laptop. One change of plans for the lab: I’ve been having problems getting LUV-live to boot on various machines, so don’t want to tie the lab to booting thumbdrives to use CHIPSEC. This Sunday we’re having a class on using CHIPSEC and related firmware security tools: Then, we could focus on reliability of the open source codebase and the handful of closed-source firmware drivers, instead of relying on the IBV/OEM to give us black-box fimware updates when they feel like it. Windows OEMs generally screw up Windows with various bloatware unlike with OS software, you cannot undo firmware bloatware, the OEM won’t permit you to rebuilt the firmware image (unless you have a Tunnel Mountain or MinnowBoard), and the OEM doesn’t provide standalone UEFI drivers/services so that you could rebuilt your firmware from and/or plus the delta of blobs (OEM/IHV drivers). Malware authors can take advantage of these remote control features, like Hacking Team is doing. Many firmware solutions target enterprise sales, so they’re happy to have phone-home style technology in their systems, to track their assets. Hacking Tool should remind people that they don’t have a clue what modules are burned into their firmware. Study this Intel blog post for a very topical example of how to use CHIPSEC to protect your system from bootkits. They used CHIPSEC and UEFItool to analyse this malware, two excellent tools for UEFI forensic analysis. Unlike other news stories on Hacking Team, this blog shows you how to check if your system is infected. It’s analysis of the malware is excellent, and worth reading. I just found out about this blog entry by the Intel Advanced Threat Research (ATR) team: There’s been a lot of mainstream coverage on this news. A quick follow-up to the Hacking Team UEFI malware story.
0 Comments
Leave a Reply. |