{"id":28072973,"url":"https://github.com/pbatard/Mosby","last_synced_at":"2025-05-12T22:01:31.173Z","repository":{"id":245462526,"uuid":"818317148","full_name":"pbatard/Mosby","owner":"pbatard","description":"Mosby – More Secure Secure Boot","archived":false,"fork":false,"pushed_at":"2024-09-30T12:01:25.000Z","size":444,"stargazers_count":20,"open_issues_count":0,"forks_count":2,"subscribers_count":2,"default_branch":"main","last_synced_at":"2024-10-12T02:06:58.984Z","etag":null,"topics":["arm64","edk2","ia32","secure-boot","secureboot","uefi","uefi-secureboot","uefi-shell","x64"],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/pbatard.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-06-21T15:17:33.000Z","updated_at":"2024-10-06T01:20:52.000Z","dependencies_parsed_at":"2024-06-22T08:09:55.636Z","dependency_job_id":"0cbde5f1-19c7-4daa-8b21-035d999a1619","html_url":"https://github.com/pbatard/Mosby","commit_stats":null,"previous_names":["pbatard/turnkey","pbatard/sbkick","pbatard/mosby"],"tags_count":5,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pbatard%2FMosby","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pbatard%2FMosby/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pbatard%2FMosby/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pbatard%2FMosby/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/pbatard","download_url":"https://codeload.github.com/pbatard/Mosby/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253830925,"owners_count":21971001,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["arm64","edk2","ia32","secure-boot","secureboot","uefi","uefi-secureboot","uefi-shell","x64"],"created_at":"2025-05-12T22:00:40.111Z","updated_at":"2025-05-12T22:01:31.107Z","avatar_url":"https://github.com/pbatard.png","language":"C","readme":"[![Build Status](https://img.shields.io/github/actions/workflow/status/pbatard/Mosby/Linux.yml?style=flat-square\u0026label=Linux/EDK2%20Build)](https://github.com/pbatard/Mosby/actions/workflows/Linux.yml)\n[![Release](https://img.shields.io/github/release/pbatard/Mosby.svg?style=flat-square\u0026label=Release)](https://github.com/pbatard/Mosby/releases)\n[![Licence](https://img.shields.io/badge/license-GPLv3-blue.svg?style=flat-square\u0026label=License)](https://www.gnu.org/licenses/gpl-3.0)\n[![Downloads](https://img.shields.io/github/downloads/pbatard/Mosby/total.svg?label=Downloads\u0026style=flat-square)](https://github.com/pbatard/Mosby/releases)\n\nMosby - More Secure Secure Boot\n===============================\n\n## Description\n\n**Mosby** (*mos⸱bee*), which stands for *More Secure Secure Boot, for **You***, is a UEFI\nShell application designed to easily create and install a more secure (and more up to date)\ndefault set of UEFI Secure Boot keys that includes your own Secure Boot signing credentials,\nas well as a **unique**, non-exploitable, machine Primary Key (PK).\n\nThe motivations behind this are as follows:\n\n1. Two of the Secure Boot whitelisting (*DB*) certificates, commonly used for Secure Boot\n   validation (`Microsoft Windows Production PCA 2011` and `Microsoft Corporation UEFI CA 2011`)\n   as well as Microsoft's main Key Exchange Key (*KEK*) certificate\n   (`Microsoft Corporation KEK CA 2011`) **are set to expire in the second half of 2026**.  \n   Whereas, in itself, this will not prevent **existing** Secure Boot signed bootloaders from\n   validating (as long as they haven't been revoked through other means) it will however\n   prevent any **newer** UEFI bootloader from doing so which basically means that, if your OS\n   or OS installater was produced after those DB certificates expire, and you don't have the\n   additional 2023 DB certificates installed (see below), then, come the second half of 2026,\n   you will not be able to boot or even install a Secure Boot compatible OS in a Secure Boot\n   enabled environment!  \n   This application can remedy that.\n2. In 2023, because of the expiration of the certificates listed above, Microsoft introduced\n   one new *KEK* and two new *DB* certificates, that are therefore not be commonly found in\n   your system manufacturer's default key (especially if your system has not received any\n   firmware update since 2024) and that (because a *KEK* can **only** be installed through\n   [updates that are signed by the platform manufacturer](https://uefi.org/specs/UEFI/2.9_A/32_Secure_Boot_and_Driver_Signing.html#enrolling-key-exchange-keys))\n   cannot be fully updated from the OS itself, even if the OS is Secure Boot compatible or\n   comes from Micosoft.  \n   This application can remedy that.\n3. As of the second half of 2024, and due to\n   [many](https://arstechnica.com/information-technology/2023/03/unkillable-uefi-malware-bypassing-secure-boot-enabled-by-unpatchable-windows-flaw/),\n   [many](https://wack0.github.io/dubiousdisk/) vulnerabilities uncovered in the UEFI Windows\n   bootloaders, Microsoft is in the process of **completely removing** one of the base DB\n   certificates (The `Microsoft Windows Production PCA 2011` certificate mentioned above).  \n   **Once Microsoft produces installation media that no longer users this certificate**,\n   this application will make sure that this DB certificate is properly removed (as opposed\n   to what would happen if you use the native Secure Boot key restoration from your UEFI\n   firmware).\n4. In 2024, it was disovered that some PC manufacturers [played fast and loose with the\n   Primary Key (*PK*) shipped with their hardware](https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/),\n   basically meaning that malicious actors could gain access to the secret key, and therefore\n   gain full trusted access of the affected machines. It is also very likely (though of\n   course it is in their interest not to reveal it) that, PC manufacturers have had more *PK*\n   private key exfiltered into the hand of malicious actors (or, if you are living under an\n   authoritative regime, have been forced to hand them over to said regime), leading to the\n   same very real risk of a third parties exploiting this data to install UEFI rootkits on\n   users' computers.  \n   With its default settings, this application can fully remedy that.\n5. OS manufacturers, such as Microsoft, have long taken a very user-adverse stance against\n   the ability of individuals to ultimately be in control the UEFI boot signing process, by,\n   to name just a few instances, using fake rethoric against some software licenses in order\n   to arbitrarily deny common Linux bootloaders such as GRUB from being Secure Boot signed,\n   trying to lock down hardware so that Secure Boot could not ever been disabled by the user,\n   making a two-tier version of Secure Boot signatures with one exclusive tier for Windows\n   and a lower tier for other OSes and application or, up until recently, even trying to\n   prevent anybody that wasn't an OS or hardware manufacturer from being allowed to\n   redistribute UEFI revocation lists...  \n   The end result is that it has become a lot more convoluted and daunting than it should\n   really be for end-users, to make Secure Boot work in their favour.  \n   This application can also remedy that.\n6. Figuring out SBAT, SkuSiPolicy as well as Microsoft's new SVN DBX based revocation updates\n   is currrently a mess, as you need to wade through many different sources to try to ensure\n   that your system is actually up to date with them (because if they aren't, an attacker can\n   easily bypass Secure Boot on your system).  \n   This application can remedy that.\n\nIn short, while making sure that all the Secure Boot keys used by your platform are up to\ndate, the whole point of this application is to give control of the whole Secure Boot process\nback to **YOU**, like it should always have been, instead of leaving it in control of a\nselect few, who may not have your interests in mind, and, over and over, have demonstrated\nbehaviour that should not warrant your blind trust.\n\nAnd it does so by making incredibly **easy** to install your own set of Secure Boot keys.\n\n## Usage\n\n1. Create a UEFI Shell bootable media.  \n   If you don't have such a media, you can *easily*  create one on Windows through\n   [Rufus](https://rufus.ie) by using the SELECT/DOWNLOAD split button and then choosing\n   *UEFI Shell* in the download selection:  \n   https://raw.githubusercontent.com/wiki/pbatard/rufus/images/download.gif\n\n2. Extract all the content from the latest Mosby download archive at the top level of the\n   boot media you created in the previous step.\n\n3. Boot the computer where you want to install the keys into the UEFI firmware settings and\n   make sure that your platform is in *Setup Mode*. Please refer to your manufacturer's\n   documentation if you don't know how to enable *Setup Mode*.\n\n4. Boot into the UEFI Shell media you created and type: `Mosby` (without any extension). The\n   executable relevant to your platform will automatically launch and will guide you through\n   the installation of the UEFI Secure Boot keys.\n\n5. Once the installation is complete, reboot into UEFI firmware settings, and make sure that\n   Secure Boot is enabled.\n\nIf needed, you can also provide your own DB/DBX/DBT/KEK/PK/MOK binaries in DER, PEM, ESL or\nsigned ESL format, by using something like `-db canonical_ca.cer` to point a Secure Boot\nvariable to the data you want to install for it.\n\n## Parameters\n\n* `-h`: Display the application parameters and exit.\n* `-v`: Display the application version and exit.\n* `-i`: Display information about the embedded data installable by the application, as well\n        as the current SBAT data from the system (if SBAT is set).\n* `-s`: Silent option (Removes some of the early and late prompts).\n* `-u`: Update only: Only update the revocation databases, SBAT, and SSPV/SSPU as needed.\n* `-t`: Test mode. Disables some checks and wnables the internal **low security** Random\n        Number Generator, if no other Random Number Generator can be found.\n* `-x`: Install the Microsoft update that invalidates `Microsoft Windows Production PCA 2011`.\n        You should only use this if you know what you are doing, as you you may not be able\n        to boot or reinstall Windows otherwise. **You have been warned!**\n\nYou can also point to files using the `-pk`, `-kek`, `-db`, `-dbx`, `-mok`, `-dbt`, `-sbat`,\n`-sspv` and `-sspu` parameters.\n\n## Compilation\n\nBecause Mosby depends on OpenSSL to provide the various cryptography function it needs, and\nOpenSSL is integrated by default into [EDK2](https://github.com/tianocore/edk2), only EDK2 is\nsupported for compilation.\n\nAdditionally, some very limited patching of EDK2 is required to enable some of the standard\nOpenSSL providers, that take care of the importing/exporting of keys and certificates, and\nthat are not currently enabled by EDK2.\nSo you should first apply `Add-extra-PKCS-encoding-and-decoding-to-OpensslLibFull.patch` to\nthe EDK2 submodule.\n\nIf compiling for ARM or RISCV-64 some additional patching of OpenSSL is required, that can be\nfound in `OpenSSL-submodule-fixes-for-\u003cPLATFORM\u003e-compilation.patch`.\n\nOnce that is done, you can compile Mosby as you would any regular EDK2 module, by issuing\nsomething like:\n\n```\ncd \u003cdirectory where you cloned Mosby\u003e\ngit submodule update --init\nexport WORKSPACE=$PWD\nexport PACKAGES_PATH=$WORKSPACE:$WORKSPACE/edk2\nsource edk2/edksetup.sh\nbuild -a X64 -b RELEASE -t GCC5 -p MosbyPkg.dsc\n```\n\nNote that, if you have `bash` with `curl`, `OpenSSL` and `sed` installed, you can recreate\n`data.c` by running the following command in the `src/` directory:\n```\n./gen_data.sh \u003e data.c\n```\n\n## Mini FAQ\n\n### ERROR: This platform does not meet the minimum security requirements\n\nIf you are getting the error above, it usually means that your system is lacking a proper\nrandom number generator, which is essential for the generation of a Secure Boot signing key\nthat can't be easily cracked by an attacker.\n\nMosby first attempts to use the OpenSSL provided random number generator or, if that is not\navailable, it falls back to using the UEFI platform's random number generator both of which\nare considered safe for the generation of signing keys.\n\nIf none of the above are available, then Mosby can also use its own internal random number\ngenerator, however because of the algorithm being used, this generator should be considered\n**unsafe** and therefore can only be used when running Mosby with the \"test\" (`-t`) option.\n\n### How do I use the generated Secure Boot key to sign a UEFI bootloader?\n\n* On Windows, use `signtool.exe` with the `.pfx`. For example, to sign `bootx64.efi`:\n```\nsigntool sign /f MosbyKey.pfx /fd SHA256 bootx64.efi\n```\n\nNote that you can download `signtool.exe` with the command:\n```\ncurl.exe -L -A \"Microsoft-Symbol-Server/10.0.0.0\" https://msdl.microsoft.com/download/symbols/signtool.exe/910D667173000/signtool.exe -o signtool.exe\n```\n\n* On Linux, use `sbsign` from the `sbsigntool` package with the `.pem` and `.crt`.\n  For example, to sign `bootx64.efi`:\n\n```\nsbsign --key MosbyKey.pem --cert MosbyKey.crt bootx64.efi --output bootx64.efi\n```\n\nIf asked for a passphrase, just press \u003ckbd\u003eEnter\u003c/kbd\u003e.\n\n### How can you state that your application makes Secure Boot more Secure?\n\nEasy. If you had used `Mosby` then even on a PC where the default UEFI keys were subject to\n[this vulnerability](https://it.slashdot.org/story/24/07/25/2028258/secure-boot-is-completely-broken-on-200-models-from-5-big-device-makers),\nthe vulnerability would have been fully closed and rendered inexploitable.\n\n### Why isn't the Secure Boot private key generated by this application password protected?\n\nBecause the key is unique, and, in most usage scenarios (individuals securing a very limited\nnumber of machines) unlikely to be easy to exploit (since the attacker would already need to\nhave found a vulnerability to locate and access the key from where it is stored). On the\nother hand, we want to make it easy for people to be able to sign their UEFI bootloaders as\nthey need it, because vetting bootloaders for Secure Boot should not be a daunting prospect.\n\nAt any rate, if you do want a Secure Boot signing key that is protected by a password, you\ncan easily generated one with OpenSSL, and then point to its matching certificate when\nrunning `Mosby`.\n\n### How can I trust that Mosby is not doing something malicious behind the scenes?\n\n1. It's public source, using a license that **explicitly prevents** the inclusion of anything\n   in the final binary for which you cannot access the source.\n2. It's built in a transparent manner through GitHub Actions, and binary validation can be\n   enacted in a similar way as\n   [what applies to our UEFI-Shell binaries](https://github.com/pbatard/UEFI-Shell?tab=readme-ov-file#binary-validation).\n3. It's published by the same developer as the person behind [Rufus](https://rufus.ie), which\n   is a rather popular and **trusted** application, that, for more than 10 years now, has\n   helped countless people install bootloaders and run privileged code on their computer. In\n   short if the ultimate goal of the developer of Mosby was to gain the ability to exploit\n   your computer, they would have had plenty of other opportunities to do so over the last\n   decade, and, more importantly, would long have been reported if they ever did so.\n","funding_links":[],"categories":["C"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpbatard%2FMosby","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpbatard%2FMosby","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpbatard%2FMosby/lists"}