 good evening everyone well more people than I thought would fit in here okay for now we have Mimoya she will talk about everything and the kitchen sink and what to find in firmware images this this are her findings from one year of research she had the idea last year at GPN and now let's hear what she has to say hey thank you all for coming it's awesome to be speaking and sat in front of such a large crowd so let's talk about firmware small disclaimer that my knowledge is about is from reverse engineering I do not work somewhere where I built firmware every day so please take it with a bit of result I want to teach you some knowledge which you could use if you would look at the hex stamp of a firmware image so not going too deep in to death into the actual logic of a firmware more about the headers the structures and the data you can find in there as stated last year last year on Saturday I crashed IFT tool and instead of fixing my bug I started a rewrite and go and from there I did parse quite some data structures you usually found finding images this is going to be dense I'm sorry I have almost 70 slides for the upcoming 60 minutes and they contain code the slides are published of course so you can look them up if you want to build parse or whatever do your by yourself so the first thing you might want to know about firmware is where you does my CPU I start executing when you boot your firmware this is for example the end of a firmware image the only interesting thing is in the last line you see here because your CPU jumps to minus 16 and it is in 16 bit mode so we are only looking at this instruction you see there in the second line and as we are in 16 bit mode the last two bytes are discarded they are not in part of the actual instruction it's a short jump backwards in this particular case so it will jump backwards into the image which is mapped to the end of the of the RAM and will load all the UFI specifics from there so we can't talk about firmware without talking about UFI if you want to know something about UFI the UFI in your image you're looking at there is an awesome tool which has an awesome graphical user interface it's the UFI tool it's a Q tool you can use it and it will give you a nice overview of the things that are in there you can click around and get a tree view if you are a more bare bone on your way you can use Google Fiano which is part of the Linux boot project which gives you a go wrapper around all the UFI data structures or if you listen to me now let's pass them by ourselves what exactly is UFI UFI is an image or the UFI region is a file system it's separated into three three structures those are volumes regions and files volumes and regions are specified files can contain some free-flowing information and the header of a UFI structure a volume a region or a file contains a identical GUID with the respected information on what we are looking at so if we took take a look at our volume header we see okay we have 16 bytes of zero then we have our volume GUID we have our firmware lengths and we have a signature we have some attributes header lengths check sums and so on things that are nice to know but you usually don't need so much so we can take a look at this we can see this you you can usually usually see your 16 zeros by I what you else want to take a look at is the underscore FVH signature that's the EFI object signature and if you are looking at the volume then your last two entries in the header the block map and the entry map the block map is an array of run length encoded entries and is determined terminated by an entry of zero and zero and your map entry gives you an overview about the number of blocks and the length of the blocks so you can now know okay my volume contains this amount of blocks after the header and how big is each block so you can extract your information from a volume but you can read volumes you can read regions in the same way but but what does it give a of an advantage well if your CPU does this backward jumps it this backward jump it starts in the SEC stage of UEFI well it the rem minute and CPU in it are done and some very basic devices are initialized from there it will continue in the PEI stage where the pre EFI and the platform initialization will take place and then it will prepare for the DXI phase which is the driver stage of UEFI which mounts drives does UEFI run times and interfaces prepares those to be able to communicate with the operating system later on it does interface configuration for example determines where you want to boot from and then it loads your operating system but we all know somehow how we deal with UEFI the thing the thing we are not used to see are updates so if our vendor gives us updates what are the formats UEFI specified to us to use well those are in update capsules those are capsules or those volumes have special geo IDs which determine the type of update capsule this is just an example of those I found and the most common ones and let's take a look at two of those because they are quite complex the EFI file system structure after the geo ID contains and header size the same flex we saw with the volume the capsule image size and the sequence number because those capsules can be sequenced and second partitioned into several parts and you've got your instance ID the number in this sequence and then you've got a lot of offsets for pausing it if you want to and you can take whatever you need the split split information where you where it was split but those are bit fields and I will not talk about them now the most common one I saw when I looked at images was the ev2 file system capsule and it was quite nice because you've got your header size you've got your flex you've got the size of your image which is to be copied what perfectly bit for bit into your flash chip on your main board the image offset and some OEM offset where the OEM can configure stuff so if you have this type of capsule you can just look at it find your offset and go to the offset extract your flash image from there quite nice so what does it look in hex dump if we take a look at this we've had we have ours 16 bytes of zero at the beginning then we have our efi to efi to GUID we have our encoded size we know okay this is 432 bits 432 bit coming from here and then you have your offset so yeah that's a directly followed by the actual data that's something you can see by the eye if you know what you're looking at so we talked about CPUs and how CPUs are initialized and I think most of you know before you get the control over this flow of your CPU Intel and your vendor have already started like five other CPUs and five other code for paths so let's talk about the Intel specifics you can find in an in a modern firmware image an Intel image is partitioned into the Intel flash descriptor the IFD the BIOS region the management engine region gigabit ethernet and platform data sometimes in even your images you will also find embedded controller images the IFD is the big Intel header in your flash image it's located at the beginning of the flash image either at zero or at 0x10 it contains about info information about the segments and the of the flash image it contains information about the configuration you want to run this image in and all the other stuff the CPU needs to know your tools of choice if you don't want to posit yourself is IFD tool you will find it in the corporate tree address bits that are found in these headers are to be shifted for to the left so all your address addresses have to be aligned the IFD itself starts with the 5a a5 fof fof signature and let's take a look at the IFD header that follows up after the signature it's mainly compact mainly built from for interesting values and an M E value so we first have our signature then come for mappings we can use those are bit fields then some OEM reserve areas where all the rest of the data usually is stored not all the time but most of the time and then we have some M E configuration map which does not necessarily have to be there the first map the chip and region config FL map 0 we have 8 bits of component base address and if we take out this 8 bits and shift them to the to the left we get our configurations for the different chips that this image could be burnt on to at this offset we will find an array of objects contained of this structure so we have 32 bits of FL comp 32 bits of FL IL comp and some other data so let's just take those apart shortly the FL comp gives basic informations about what you can do with this chip it's does this chip allow dual output fast read support our can it read for read or write certain instructions and also the identity the density of the actual components so if you have a computer with more than one flash chip this would be a place where you could find your component density the FL IL structure contains four illegal instructions I have basically no clue what they're doing but they are printed all the time if someone takes apart the IFT header so maybe someone of you knows I would be lucky to know it the rest of the bits from the original FL map 0 are the number of flash chips six reserved bits the region base address which is where we can find our region configurations which are in seven to nine entries in an array which you can shift to the left and skip the end or shift to the right get the start address of your region you have a number of regions field in three bits encoded which is the was the basically the only way to determine the flash descriptor version before you before Coffee Lake and some reserved bits the second FL map so the second 32 byte a 32 bit after your IFT signature is the SPI and PCH so the chips that configuration it has the master base address in the first eight bits where all the region access rights are stored and the number of masters so let's take a look at those sections here this basically determines as a bit field what your what the access rights to your flash are so is your your baby your main operating system for example allowed to read or write the flash descriptor allowed to read or write the bios region ME region and so on this is stored several times for the several requests that could be sent to the system and we have some more reserved six bits after the FL map one the PCH strap base where the PCH straps are stored and the number of PCH straps are stored here and we have the FL map to entry which links to the CPU strap so same thing eight bits of CPU strikes a strap space and the number of CPUs straps and the new thing from since Coffee Lake the FL map three this is where we can now read the descriptor version so we can we do no longer have to guess how many regions our image will contain and this undocumented or not so good documented ME configuration this contains ME VCC so ME power configuration and ME general configuration addresses to be used by the ME talking of the ME how is the ME image stored we can now read it from from our flash because we know the region limits and it is in organized into part partitions and of course as everything with Intel it starts with an header we have 16 bytes of reserved space most of the times they are zero then we have our dollar FTF PT signature then the number of entries a version a type a length check sums and so on general data and following that we have our partition informations with the number of entries in it a partition header has a name it has an owner it has an offset and a length and some other configuration stuff you usually don't need if you just want to read it from in firmware image if you now have a partition a partition can contain containers a container can contain modules so the containers you want to take a look at and start those starting with the mcp name those are usually configuration containers dollar mrm man and dollar mn2 modules contain compressed code usually Huffman encoded so this is something that is too complex I think for one hours I will skip it here another thing you will encounter when talking about Intel images and Intel blobs and things we don't trust is the SFSP it's the Intel firmware support package it's an Intel specific binary blob that's used to start the platform for example do ram in it and you start start initializing things like cash sram and so on it's distributed as most of the times three ufi volumes and they are easily recognizable because the first file in the first volume has a very specific specific to you ID you don't see in other files okay we talked about Intel so on the AMD side what's there well AMD doesn't directly have a IFT at the beginning of the image but they have something similar it's the firmware entry table the PSP the security processor of the AMD CPUs will look for this and will initialize the CPU accordingly and it will look at the 0x 20,000 offset in the flash image for example if you have a 16 megabyte image all added addresses will have a mapping of 0x ff this depends on your image because your image is mapped to the end of the flash and based on your length all offsets will shift so your PSP will find this firmware entry table at this offset you first have a signature then you have a ICM ROM base a GEC ROM base which is gigabit ethernet you have X HCI which is USB the PSP where the PSP firmware lies a new PSP firmware and some other configurations so let's start at the top signature similar to Intel but not the same it's 55AA 55AA that's kind of easy to find you just look at your image and if it has a signature at this specific offset you are quite sure you have a modern AMD image in front of you so what do we find at the ICM ROM base what's there if we take a look at this offset we find another magic the AMD IMCC magic so what is an IMC? IMC is AMD's embedded controller implementation it's rarely used but almost all CPUs have it some newer CPUs seem to ditch it so if you have it okay you can just take a look at it it's barely documented but the core boot wiki is your way to start here the next thing gigabit ethernet yeah okay we all know what that is it's hardware specific let's not take a look at that because we don't want to take a look at bytecode right now X HCI so there are two versions of X HCI from where I found when taking a look at some images both run on the 800 chipsets from Renazis and the core boot wiki documented the old structure at least if we take a look here according to the core boot wiki the X HCI offset if you take a look there you find a signature you find an offset to your firmware and from there you can find another header which gives you the firmware version and then the firmware data okay two in directions but you can find your firmware if you want to take a look at that the new X HCI firmware starts with this and I have only found this one version there might be others but I haven't seen those in the wild and if you take a look at this there is a big block of zeros to the right what might that be let's put it into our disassembler and realize yeah that's those are jumps what we are looking here that's it's a reset weight vector this is the firmware it starts with the firmware and there's no header around that so we have our entry factor if you want to take a look at this maybe in a really recently released reverse engineering tool go for it it's kind of easy to do but how are those things really propagated to us users because Intel have this has this fsp which is lying in a github repository as binary blobs well MD has this a geyser thing binary blobs are shipped to my understanding as an a geyser bundle we you can only get with an NDA the format in which this bundle is distributed is known there is a specification and a geyser is quite a short name for a long word it's an interface interface and they have it forever I don't have it I don't know how it looks like but we can take a look at the version of our a geyser in jara syntax there are several markers we can look at in our image if we want to take a take knowledge about our a geyser there are always this AMD something something or the a geyser strings in there so just a small sample of things we are looking at those are several versions for several several PI several CPU in iterations AMD distributes the a geyser for they have changed the format quite sometimes and usually having an higher a geyser version doesn't mean it's newer because when they release a new CPU and often the a geyser is backwards compatible then the version number will start with zero point something again or one point something based on where you are in the release cycle but not only the PSP not only the actual boot code is contained in the a geyser but also the PSP firmware I already talked about the PSP as stated is AMD security code processor and it was in front of the main system unless you have a really old system and it's required to boot unless you have a really old system and it only runs sine code unless you have a exploit quite a nice thing I kindly kindly asked and the author of PSP to release his tool to take a look like the UFI tool into PSP firmware he released it two or three days ago awesome please take a look at it if you are interested you can find it with a github search just using the search query PSP tool but if you have a modern system how does it boot well it's pretty straightforward it's as you think the PSP on chip boot run was bootstrap the PSP the PSP will do these signature verification of your flash image and your PSP firmware it will read and load its own bootloader jump in there and the bootloader will run the PSP operating system from there your main CPU operating system will be loaded and your CPU will be started where your CPU can now take off and load all the UFI stuff we already talked about so where does this firmware lie if we take a look at our UFI code well there you have two paddings usually it's stored in the second padding because AMD doesn't distribute it as UFI volumes it's just binary with offsets so you usually find it in your padding if you want to play around with your firmware image on AMD don't touch the padding or it will no longer boot other things we talked about the when you look take a look at the firmware entry table there were the PSP headers the firm PSP base addresses so what do we find if we take a look at those well there are three entries here the PSP directory base the new PSP directory base for new versions of the PSP and the BDH directory the BDH directory is very similar to the PSP if you want to pass it with different magic values so I will ignore it for now the PSP directory base if you take a look over at this space address you will find the PSP cookie it's either dollar PSP or two PSP and it will be the cookie a check some the number of entries following and some reserved field for padding if you are in the situation to find a two PSP header here or two PSP signature this means the next two addresses you will take a look at aren't aren't entries but those are additional offsets to where your directories lie well then hopefully you find your dollar PSP entries so how does an entry look that follows this header it has a type it has a size it has a location and reserved field pretty straight forward the type it's the type of the of the entry you're looking at this table is incredibly long if you take a look at it it's also I took it from PSP tool there are over thousand entries AMD uses as far as I know but if you now have your type your offset and you know your numbers then you can build your night yourself quite the nice table of your directory and your entries and what you find in there and usually your PSP image starts with the AMD public key the AMD boot loader and the recovery boot loader so we have a public key and we only want to run signed code where does it this security come from well the directory starts with the public key so the boot loader reads the public key it uses a public key to verify the boot loader and jumps in there the PSP boot loader the on wrong boot loader but we have a problem end of a 2018 AMD started to encrypt the boot loader okay now we have a new type it's the encrypted key which is used to decrypt the boot loader before we jump into that and it's using a yes and it's for now it's looking quite good so how does this work image property of CTS I took their images your on chip your PSP on chip has a key and it's using the type 0x 21 encrypted key to receive the AES uses the module key it starts takes from the inside to decrypt the boot loader and then be able to run it in an image the boot ROM on the PSP goes to the encryption key takes the encryption key to decrypt the boot loader okay but we for now know those was were able AMD was able to do this in a software update so if you are able to put your operating system with an older image you can still debug your boot loader because this appears to be a logic that was already available but not used before that and there is a very special type of entries those are data entries data entries contain 0x 100 bytes of undocumented header which is signed and of course as everything verified if we take a look at it we have our ID we have a sign size we have a signature fingerprint we have a bit to know if it is compressed and if it is compressed we get the size further down in the header we also get to know our version in BCD code because AMD uses BCD code everywhere don't ask me why and the headers verified but we had the problem that several images contained entries where the sign size was 0 so the data wasn't verified this was the rise and fall vulnerability he heard maybe last year about and jumping sprinting through this talk way too fast I'm coming to my end talking about what I'm not looking at microcode because microcode doesn't have an header there is no real magic okay there is an header but there is no magic you can look for and it is very specific to AMD or Intel and detecting microcode in your image is quite hard you can only do statistics and statistics about the bytes you are looking at and maybe find something that is microcode related because the microcode is loaded by your firmware and it is not as an fixed offset you know your Linux is able to run microcode updates on your CPU so you just put it to an address and tell the CPU to go look there but if you know you are looking at a microcode update there is an extractor tool which is by Platomov the guy who also wrote the excellent ME extractor tool if you want to take a look at those things yeah and I'm sorry for running through this talk way too fast but I'm coming to my end I'm guessing you have a million of questions now so first thank you for your really deep dive into firmwares and if you have questions please raise your hands I will come over to you and hand you the microphone for the IFT you mentioned that the offset is either 0 or 10 do you have any information on well what information this is based on or is it do you have any guesses it's mainly about the age of the firmware image very old Intel CPUs had it at 0 and at some point it appeared to my knowledge at 16 bytes into the image it was quite some time so I think it is somewhere in the core to do times around I'm not perfectly sure here yeah so when you say very old you talking 2006 2008 I'm not quite sure I'm sorry thank you okay more questions okay I don't see any more questions then directly in front of me sorry so yeah you mentioned that they're in the AMD image there's this public key for that's used to basically verify the firmware contents so how exactly at boot up is this public key verified then if it's just open the flash the public key is also distributed by MD freely and it's verified against the internal fingerprint of the fsp of the PSP it has an internal fingerprint to check it against we cannot really exchange it sorry could use the microphone okay for someone who draws transistors and doesn't really can't really follow this all in real time if I want to find the information that you've been talking about somewhere on the web where would I do that I thought about this like five minutes before before the talk what do you prefer I think I would just tweet it and give it a shout it out to the internet if you if you just yeah I have a website Google me more yeah and I will put it online in like five minutes or something like that that's maybe the easiest version okay more questions otherwise thank you very much so you already did a lot of work even before the release of the PSP extraction tool how did you analyze the images before did you just go through them by hand and I kindly ask the person who wrote PSP to it we talked we were in conversation so I had a rough look corporate documented like the very basic of the firmware entry table the first four feet were documented other fields we just found by taking a look at and then it was just parsing parsing and breaking my own pauses until I had a rough image of what I was going on so you started with mentioning your IFD tool rewrite do you have any plans for contributing your changes back to the core boot project or maybe even including your rewrite rewrite or incorporate the fixes that you wanted to avoid in the first place the IFD tool was fixed by ages ago so I just it was my stupidity I it wasn't working the way I wanted it my go rewrite is online on my github and if the tool is actively programmed on and they are there are more very good people taking a look at that I really do not have lot to offer I might do it does Jason output that's everything different so you can take a look in general I will try to continue adding the PSP parsing to the fiano project the Linux boot fiano parser in the next time don't know when I have time and motivation yeah sounds great I mean you gave the talk here so you already gave quite a few bits back that's nice thanks okay then thank you and have a nice evening