开源软件名称（OpenSource Name）：

开源软件地址(OpenSource Url)：

开源编程语言(OpenSource Language)：

开源软件介绍(OpenSource Introduction)：

This guide is a collection of techniques for improving the security and privacy of a modern Apple Macintosh computer ("MacBook") running a recent version of macOS (formerly known as "OS X").

This guide is targeted to power users who wish to adopt enterprise-standard security, but is also suitable for novice users with an interest in improving their privacy and security on a Mac.

A system is only as secure as its administrator is capable of making it. There is no one single technology, software, nor technique to guarantee perfect computer security; a modern operating system and computer is very complex, and requires numerous incremental changes to meaningfully improve one's security and privacy posture.

This guide is provided on an 'as is' basis without any warranties of any kind. Only you are responsible if you break anything or get in any sort of trouble by following this guide.

To suggest an improvement, please send a pull request or open an issue.

This guide is also available in 简体中文.

• Basics
• Preparing and installing macOS
  • Verifying installation integrity
  • Creating a bootable USB installer
  • Creating an install image
    • Manual way
  • Target disk mode
  • Creating a recovery partition
  • Virtualization
• First boot
• System activation
• Admin and standard user accounts
  • Caveats
  • Setup
• Full disk encryption
• Firmware
• Firewall
  • Application layer firewall
  • Third party firewalls
  • Kernel level packet filtering
• Services
• Spotlight Suggestions
• Homebrew
• DNS
  • Hosts file
  • dnscrypt
  • Dnsmasq
    • Test DNSSEC validation
• Captive portal
• Certificate authorities
• OpenSSL
• Curl
• Web
  • Privoxy
  • Browser
    • Firefox
    • Chrome
    • Safari
    • Other Web browsers
    • Web browsers and privacy
  • Plugins
• Tor
• VPN
• PGP/GPG
• OTR
• Viruses and malware
• System Integrity Protection
• Gatekeeper and XProtect
• Metadata and artifacts
• Passwords
• Backup
• Wi-Fi
• SSH
• Physical access
• System monitoring
  • OpenBSM audit
  • DTrace
  • Execution
  • Network
• Binary Whitelisting
• Miscellaneous
• Related software
• Additional resources

Basics

Standard security best practices apply:

• Create a threat model

  • What are you trying to protect and from whom? Is your adversary a three letter agency (if so, you may want to consider using OpenBSD instead); a nosy eavesdropper on the network; or a determined apt orchestrating a campaign against you?
  • Recognize threats and how to reduce attack surface against them.

• Keep the system up to date

  • Patch the base operating system and all third party software.
  • macOS system updates can be completed using the App Store application, or the softwareupdate command-line utility - neither requires registering an Apple account. Updates can also be downloaded directly from Apple's support site.
  • Subscribe to announcement mailing lists like Apple security-announce.

• Encrypt sensitive data at rest

  • In addition to full disk encryption, consider creating one or several encrypted partitions or volumes to store passwords, cryptographic keys, personal documents, etc. at rest.
  • This will mitigate damage in case of compromise and data theft.

• Assure data availability

  • Create regular backups of your data and be ready to format and re-install the operating system in case of compromise.
  • Always encrypt locally before copying backups to external media or the "cloud".
  • Verify backups work by testing them regularly, for example by accessing certain files or performing a hash based comparison.

• Click carefully

  • Ultimately, the security of a system can be reduced to its administrator.
  • Care should be taken when installing new software. Always prefer free and open source software (which macOS is not).

Preparing and installing macOS

There are several ways to install macOS.

The simplest way is to boot into Recovery Mode by holding Command and R keys at boot. A system image can be downloaded and applied directly from Apple. However, this way exposes the serial number and other identifying information over the network in plain text, which may not be desired for privacy reasons.

Packet capture of an unencrypted HTTP conversation during macOS recovery

An alternative way to install macOS is to first download the latest version of macOS (Latest: macOS Monterey) from Apple via the App Store and create a custom installable system image.

Getting macOS

Apple's documentation provides details for getting older versions of macOS.

• macOS Monterey (12): App Store
• macOS Big Sur (11): App Store
• macOS Catalina (10.15): App Store
• macOS Mojave (10.14): App Store
• macOS High Sierra (10.13): App Store
• macOS Sierra (10.12): Direct Link (HTTP)
• OS X El Capitan (10.11): Direct Link (HTTP)
• OS X Yosemite (10.10): Direct Link (HTTP)

Verifying installation integrity

The macOS installation application is code signed, which should be verified to make sure you received a legitimate copy, using the pkgutil --check-signature or codesign -dvv commands.

To verify the code signature and integrity of macOS application bundles:

$ pkgutil --check-signature /Applications/Install\ macOS\ Monterey.app
Package "Install macOS Monterey":
   Status: signed by a certificate trusted by macOS
   Certificate Chain:
    1. Software Signing
       Expires: 2026-10-24 17:39:41 +0000
       SHA256 Fingerprint:
           D8 4D B9 6A F8 C2 E6 0A C4 C8 51 A2 1E C4 60 F6 F8 4E 02 35 BE B1
           7D 24 A7 87 12 B9 B0 21 ED 57
       ------------------------------------------------------------------------
    2. Apple Code Signing Certification Authority
       Expires: 2026-10-24 17:39:41 +0000
       SHA256 Fingerprint:
           5B DA B1 28 8F C1 68 92 FE F5 0C 65 8D B5 4F 1E 2E 19 CF 8F 71 CC
           55 F7 7D E2 B9 5E 05 1E 25 62
       ------------------------------------------------------------------------
    3. Apple Root CA
       Expires: 2035-02-09 21:40:36 +0000
       SHA256 Fingerprint:
           B0 B1 73 0E CB C7 FF 45 05 14 2C 49 F1 29 5E 6E DA 6B CA ED 7E 2C
           68 C5 BE 91 B5 A1 10 01 F0 24

Use the codesign command to examine an application's code signature:

$ codesign -dvv /Applications/Install\ macOS\ Monterey.app
Executable=/Applications/Install macOS Monterey.app/Contents/MacOS/InstallAssistant_springboard
Identifier=com.apple.InstallAssistant.macOSMonterey
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20400 size=641 flags=0x2000(library-validation) hashes=13+3 location=embedded
Platform identifier=13
Signature size=4523
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Signed Time=Dec 1, 2021 at 1:10:31 AM
Info.plist entries=32
TeamIdentifier=not set
Sealed Resources version=2 rules=2 files=0
Internal requirements count=1 size=88

Creating a bootable USB installer

Instead of booting from the network or using target disk mode, a bootable macOS installer can be made with the createinstallmedia utility included in Contents/Resources folder of the installer application bundle. See Create a bootable installer for macOS, or run the utility without arguments to see how it works.

To create a bootable USB installer, mount a USB drive, and erase and partition it, then use the createinstallmedia utility:

$ diskutil list
[Find disk matching correct size, usually the last disk, e.g. /dev/disk2]

$ diskutil unmountDisk /dev/disk2

$ diskutil partitionDisk /dev/disk2 1 JHFS+ Installer 100%

$ cd /Applications/Install\ macOS\ Monterey.app

$ sudo ./Contents/Resources/createinstallmedia --volume /Volumes/Installer --nointeraction
Erasing disk: 0%... 10%... 20%... 30%... 100%
Copying to disk: 0%... 10%... 20%... 30%... 40%... 50%... 60%... 70%... 80%... 90%... 100%
Making disk bootable...
Copying boot files...
Install media now available at "/Volumes/Install macOS Catalina"

Apple also has guide on doing this via the GUI Disk Utility

Creating an install image

Note Apple's AutoDMG installer does not appear to work across OS versions. If you want to build a 10.14 image, for example, the following steps must be performed on macOS 10.14!

To create a custom install image which can be restored to a Mac (using a USB-C cable and target disk mode, for example), use MagerValp/AutoDMG.

Manual way

Note The following instructions appear to work only on macOS versions before 10.13.

Find InstallESD.dmg which is inside the installation application. Locate it in Terminal or with Finder, right click on the application bundle, select Show Package Contents and navigate to Contents > SharedSupport to find the file InstallESD.dmg

Verify file integrity by comparing its SHA-256 hash with others found in InstallESD_Hashes.csv or notpeter/apple-installer-checksums.

To determine which macOS versions and builds originally shipped with or are available for a Mac, see HT204319.

$ shasum -a 256 InstallESD.dmg

Mount and install the operating system to a temporary image:

$ hdiutil attach -mountpoint /tmp/InstallESD ./InstallESD.dmg

$ hdiutil create -size 32g -type SPARSE -fs HFS+J -volname "macOS" -uid 0 -gid 80 -mode 1775 /tmp/macos.sparseimage

$ hdiutil attach -mountpoint /tmp/macos -owners on /tmp/macos.sparseimage

$ sudo installer -pkg /tmp/InstallESD/Packages/OSInstall.mpkg -tgt /tmp/macos -verbose
installer: OS Install started.
#############
[...]

The installation will take a while, so be patient. Use tail -F /var/log/install.log in another terminal to monitor progress and check for errors.

Once the installation is complete, detach, convert and verify the image:

$ hdiutil detach /tmp/macos
"disk4" unmounted.
"disk4" ejected.

$ hdiutil detach /tmp/InstallESD
"disk3" unmounted.
"disk3" ejected.

$ hdiutil convert -format UDZO /tmp/macos.sparseimage -o ~/sierra.dmg
Preparing imaging engine...
[...]

$ asr imagescan --source ~/sierra.dmg

The file sierra.dmg is now ready to be applied over Target Disk Mode, from a bootable USB installer, booting from the network or recovery mode. The image could be further customized to include provisioned users, installed applications, preferences, for example.

Target disk mode

To use Target Disk Mode, boot up the Mac you wish to image while holding the T key and connect it to another Mac using a USB-C, Thunderbolt or Firewire cable.

If you don't have another Mac, boot to a USB installer, with sierra.dmg and other required files copied to it, by holding the Option key at boot.

Use the command diskutil list to identify the disk of the connected Mac, usually /dev/disk2

Optionally, securely erase the disk with a single pass (if previously FileVault-encrypted, the disk must first be unlocked and mounted as /dev/disk3s2):

$ sudo diskutil secureErase freespace 1 /dev/disk3s2

Partition the disk to Journaled HFS+:

$ sudo diskutil unmountDisk /dev/disk2

$ sudo diskutil partitionDisk /dev/disk2 1 JHFS+ macOS 100%

Restore the image to the new volume, making sure /dev/disk2 is the disk being erased:

$ sudo asr restore --source ~/sierra.dmg --target /Volumes/macOS --erase --buffersize 4m
[...]
Erase contents of /dev/disk2s2 (/Volumes/macOS)? [ny]:y
[...]

The Disk Utility application may also be used to erase the connected disk and restore sierra.dmg to the newly created partition.

To transfer any files, copy them to a shared folder like /Users/Shared on the mounted disk image, e.g. cp Xcode_8.0.dmg /Volumes/macOS/Users/Shared

Finished restore install from USB recovery boot

Creating a recovery partition

Unless you have built the image with AutoDMG, or installed macOS to a second partition on the same Mac, you will need to create a recovery partition in order to use full disk encryption. You can do so using MagerValp/Create-Recovery-Partition-Installer or manually by following these steps:

Download RecoveryHDUpdate.dmg and verify its integrity:

$ shasum -a 256 RecoveryHDUpdate.dmg
f6a4f8ac25eaa6163aa33ac46d40f223f40e58ec0b6b9bf6ad96bdbfc771e12c  RecoveryHDUpdate.dmg

Attach and expand the installer, then run it - again ensuring /Volumes/macOS path is the newly created partition on the connected disk:

$ hdiutil attach RecoveryHDUpdate.dmg

$ pkgutil --expand /Volumes/Mac\ OS\ X\ Lion\ Recovery\ HD\ Update/RecoveryHDUpdate.pkg /tmp/recovery

$ hdiutil attach /tmp/recovery/RecoveryHDUpdate.pkg/RecoveryHDMeta.dmg

$ /tmp/recovery/RecoveryHDUpdate.pkg/Scripts/Tools/dmtest ensureRecoveryPartition /Volumes/macOS/ /Volumes/Recovery\ HD\ Update/BaseSystem.dmg 0 0 /Volumes/Recovery\ HD\ Update/BaseSystem.chunklist
[...]
Creating recovery partition: finished

Run diskutil list again to make sure Recovery HD now exists on /dev/disk2. Eject the disk with hdiutil unmount /Volumes/macOS and power down the target disk mode-booted Mac.

Virtualization

To install macOS as a virtual machine (VM) using VMware Fusion, follow the instructions above to create an image. You will not need to download and create a recovery partition manually.

For the Installation Method, select Install macOS from the recovery partition. Customize any memory or CPU requirements and complete setup. The guest VM should boot into Recovery Mode by default.

Note If the virtual machine does not boot due to a kernel panic, adjust the memory and process resource settings.

In Recovery Mode, select a language, then select Utilities > Terminal from the menu bar.

In the guest VM, type ifconfig | grep inet - you should see a private address like 172.16.34.129

On the host Mac, type ifconfig | grep inet - you should see a private gateway address like 172.16.34.1. From the host Mac, you should be able to ping 172.16.34.129 or the equivalent guest VM address.

From the host Mac, serve the installable image to the guest VM by editing /etc/apache2/httpd.conf and adding the following line to the top (using the gateway address assigned to the host Mac and port 80):

Listen 172.16.34.1:80

On the host Mac, link the image to the default Apache Web server directory:

$ sudo ln ~/sierra.dmg /Library/WebServer/Documents

From the host Mac, start Apache in the foreground:

$ sudo httpd -X

From the guest VM, install the disk image to the volume over the local network using asr:

-bash-3.2# asr restore --source http://172.16.34.1/sierra.dmg --target /Volumes/Macintosh\ HD/ --erase --buffersize 4m
	Validating target...done
	Validating source...done
	Erase contents of /dev/disk0s2 (/Volumes/Macintosh HD)? [ny]: y
	Retrieving scan information...done
	Validating sizes...done
	Restoring  ....10....20....30....40....50....60....70....80....90....100
	Verifying  ....10....20....30....40....50....60....70....80....90....100
	Remounting target volume...done

When it's finished, stop the Apache Web server on the host Mac by pressing Control C at the sudo httpd -X window and remove the image copy with sudo rm /Library/WebServer/Documents/sierra.dmg

In the guest VM, select Startup Disk from the menubar top-left, select the hard drive and restart. You may wish to disable the Network Adapter in VMware to configure the guest VM initially.

Take and Restore from saved guest VM snapshots before and after attempting risky browsing, for example, or use a guest VM to install and operate questionable software.

First boot

Note Before setting up macOS, consider disconnecting networking and configuring a firewall(s) first. However, late 2016 MacBooks with Touch Bar hardware require online OS activation (also see next section).

On first boot, hold Command Option P R keys to clear NVRAM.

When macOS first starts, you'll be greeted by Setup Assistant.

When creating the first account, use a strong password without a hint.

If you enter your real name at the account setup process, be aware that your computer's name and local hostname will comprise that name (e.g., John Appleseed's MacBook) and thus will appear on local networks and in various preference files.

Both should be verified and updated as needed in System Preferences > Sharing or with the following commands after installation:

$ sudo scutil --set ComputerName MacBook
$ sudo scutil --set LocalHostName MacBook

System activation

A few words on the privacy implications of activating "Touch Bar" MacBook devices from your friendly anonymous security researcher:

Apple increasingly seems (despite vague claims to the contrary) increasingly interested in merging or "unifying" the two OSes, and there are constantly rumors of fundamental changes to macOS that make it far more like iOS than the macOS of old. Apple's introduction of ARM-based coprocessors running iOS/sepOS, first with the T1 processor on the TouchBar MacBook Pros (run the TouchBar, implement NFC/ApplePay, add biometric login using sep, and verify firmware integrity) and the iMac Pro's T2 (implements/verifies embedded device firmware, implements secure boot, etc) seems to cement this concern and basically renders using macOS devices without sending metadata to Apple difficult to impossible.

iOS devices have always required "activation" on first boot and when the battery has gone dead which initializes sepOS to proceed with verified boot. First boot activation not only initializes sepOS as discussed below, but sends metadata to Apple (and carriers via Apple with cellular devices) to activate the baseband and SIM. In activation processes after first boot, just as with first boot, a long list of highly sensitive metadata are sent hashed (note hashing does not give you any privacy from Apple here since they link this exact metadata to payment information at purchase) to Apple so it can return the personalized response required for secure boot to complete. What is particularly worrying about this process is that it is a network-linked secure boot process where centralized external servers have the power to dictate what the device should boot. Equally there are significant privacy concerns with devices constantly sending metadata (both during activation and other Apple-linked/-hosted activities) and linking IP addresses very strongly with real identities based on purchase payment information and if a cellular device, metadata collected about SIM, etc unless such connections are blocked at the network level (which is only possible on self-managed infrastructure, i.e. not cellular) and doing this basically renders using the device impossible since simply installing an application requires sending device metadata to Apple.

That the activation verification mechanism is designed specifically to rely on unique device identifiers that are associated with payment information at purchase and actively associated on a continuing basis by Apple for every Apple-hosted service that the device interacts with (Apple ID-based services, softwareupdate, iMessage, FaceTime, etc.) the ability (and invitation) for Apple to silently send targeted malicious updates to devices matching specific unique ID criteria is a valid concern, and something that should not be dismissed as unlikely, especially given Apple's full compliance with recently implemented Chinese (and other authoritarian and "non-authoritarian" countries') national security laws.

iOS has from the start been designed with very little end-user control with no way for end-users to configure devices according to their wishes while maintaining security and relies heavily on new, closed source code. While macOS has for most of its history been designed on the surface in a similar fashion, power and enterprise users can (for the moment) still configure their devices relatively securely while maintaining basically zero network interaction with Apple and with the installation of third party software/kernel extensions, completely control the network stack and intercept filesystem events on a per-process basis. macOS, despite having a good deal of closed source code, was designed at a very different period in Apple's history and was designed more in line with open source standards, and designed to be configurable and controllable by enterprise/power users.

The introduction of these coprocessors to Mac devices, while increasing security in many ways, brings with it all the issues with iOS discussed above, and means that running mac devices securely with complete user control, and without forced network interaction with the Apple mothership in highly sensitive corporate and other environments problematic and risky. Given this author is unaware of the exact hardware configuration of the coprocessors, the following may be inaccurate. However, given the low-level nature of these coprocessors, it would not surprise the author if these coprocessors, if not already, will eventually have separate network access of their own, independent of the Intel CPU (indications suggest not currently the case for T1; unclear on T2), which leads to concerns similar to those that many have raised around Intel ME/AMT (and of course mac devices also have ME in the Intel CPU...). One could argue that these coprocessors increase security, and in many ways that is the case, but not the user's security against a malicious Apple.

The lack of configurability is the key issue. Apple could have introduced secure boot and firmware protection without making it require network access, without making verification linked to device-unique IDs and without introducing an enormous amount of potentially exploitable code to protect against a much smaller, but highly exploitable codebase, while running on a coprocessor with a highly privileged position on the board which gives immense power to an adversary with manufacturer compliance for targeted attacks.

This is an ongoing concern and in the worst case scenario could potentially represent the end of macs as independent, end-user controllable and relatively secure systems appropriate for sensitive environments with strict network and security policies.

From iOS, The Future Of macOS, Freedom, Security And Privacy In An Increasingly Hostile Global Environment.

Admin and standard user accounts

The first user account is always an admin account. Admin accounts are members of the admin group and have access to sudo, which allows them to usurp other accounts, in particular root, and gives them effective control over the system. Any program that the admin executes can potentially obtain the same access, making this a security risk.

Utilities like sudo have weaknesses that can be exploited by concurrently running programs and many panes in System Preferences are unlocked by default (pdf) (p. 61–62) for admin accounts.

It is considered a best practice by Apple and others (pdf) (p. 41–42) to use a separate standard account for day-to-day work and use the admin account for installations and system configuration.

It is not strictly required to ever log into the admin account via the macOS login screen. The system will prompt for authentication when required and Terminal can do the rest. To that end, Apple provides some recommendations for hiding the admin account and its home directory. This can be an elegant solution to avoid having a visible 'ghost' account. The admin account can also be removed from FileVault for additional hardening.

Caveats

• Only administrators can install applications in /Applications (local directory). Finder and Installer will prompt a standard user with an authentication dialog. Many applications can be installed in ~/Applications instead (the directory can be created manually). As a rule of thumb: applications that do not require admin access – or do not complain about not being installed in /Applications – should be installed in the user directory, the rest in the local directory. Mac App Store applications are still installed in /Applications and require no additional authentication.
• sudo is not available in shells of the standard user, which requires using su or login to enter a shell of the admin account. This can make some maneuvers trickier and requires some basic experience with command-line interfaces.
• System Preferences and several system utilities (e.g. Wi-Fi Diagnostics) will require root privileges for full functionality. Many panels in System Preferences are locked and need to be unlocked separately by clicking on the lock icon. Some applications will simply prompt for authentication upon opening, others must be opened by an admin account directly to get access to all functions (e.g. Console).
• There are third-party applications that will not work correctly because they assume that the user account is an admin. These programs may have to be executed by logging into the admin account, or by using the open utility.
• See additional discussion in issue #167.

Setup

Accounts can be created and managed in System Preferences. On settled systems, it is generally easier to create a second admin account and then demote the first account. This avoids data migration. Newly installed systems can also just add a standard account.

Demoting an account can be done either from the the new admin account in System Preferences – the other account must be logged out – or by executing these commands (it may not be necessary to execute both, see issue #179):

$ sudo dscl . -delete /Groups/admin GroupMembership <username>
$ sudo dscl . -delete /Groups/admin GroupMembers <GeneratedUID>

To find the “GeneratedUID” of an account:

$ dscl . -read /Users/<username> GeneratedUID

See also this post for more information about how macOS determines group membership.

Full disk encryption

FileVault provides full disk (technically, full volume) encryption on macOS.

FileVault encryption protects data at rest and hardens (but not always prevents) someone with physical access from stealing data or tampering with your Mac.

With much of the cryptographic operations happening efficiently in hardware, the performance penalty for FileVault is not noticeable.

Like all cryptosystems, the security of FileVault greatly depends on the quality of the pseudo random number generator (PRNG).

The random device implements the Yarrow pseudo random number generator algorithm and maintains its entropy pool. Additional entropy is fed to the generator regularly by the SecurityServer daemon from random jitter measurements of the kernel.

See man 4 random for more information.

Turning on FileVault in System Preferences after installing macOS, rather than creating an encrypted partition for the installation first, is more secure, because more PRNG entropy is available then.

Additionally, the PRNG can be manually seeded with entropy by writing to /dev/random before enabling FileVault. This can be done by simply using the Mac for a little while before activating FileVault.

It may also be possible to increase entropy with an external source, like OneRNG. See Entropy and Random Number Generators and Fun with encryption and randomness for more information.

Enable FileVault with sudo fdesetup enable or through System Preferences > Security & Privacy and reboot.

If you can remember the password, there's no reason to save the recovery key. However, all encrypted data will be lost forever if without either the password or recovery key.

To learn about how FileVault works, see the paper Infiltrate the Vault: Security Analysis and Decryption of Lion Full Disk Encryption (pdf) and related presentation (pdf). Also see IEEE Std 1619-2007: The XTS-AES Tweakable Block Cipher (pdf).

Optional Enforce system hibernation and evict FileVault keys from memory instead of traditional sleep to memory:

$ sudo pmset -a destroyfvkeyonstandby 1
$ sudo pmset -a hibernatemode 25

All computers have firmware of some type - EFI, BIOS - to help in the discovery of hardware components and ultimately to properly bootstrap the computer using the desired OS instance. In the case of Apple hardware and the use of EFI, Apple stores relevant information within EFI to aid in the functionality of macOS. For example, the FileVault key is stored in EFI to transparently come out of standby mode.

Organizations especially sensitive to a high-attack environment, or potentially exposed to full device access when the device is in standby mode, should mitigate this risk by destroying the FileVault key in firmware. Doing so doesn't destroy the use of FileVault, but simply requires the user to enter the password in order for the system to come out of standby mode.

If you choose to evict FileVault keys in standby mode, you should also modify your standby and power nap settings. Otherwise, your machine may wake while in standby mode and then power off due to the absence of the FileVault key. See issue #124 for more information. These settings can be changed with:

$ sudo pmset -a powernap 0
$ sudo pmset -a standby 0
$ sudo pmset -a standbydelay 0
$ sudo pmset -a autopoweroff 0

For more information, see Best Practices for Deploying FileVault 2 (pdf) and paper Lest We Remember: Cold Boot Attacks on Encryption Keys (pdf)

Note APFS may make evicting FileVault keys redundant - see discussion and links in issue #283.

Firmware

Setting a firmware password p