Forgotten UEFI shims undermining Safe Boot

ESET researchers recognized 11 outdated and forgotten UEFI shim bootloaders at variations 0.9 and beneath that can be utilized to bypass UEFI Safe Boot on any UEFI-based machine that trusts Microsoft’s Microsoft Company UEFI CA 2011 third-party UEFI certificates authority (CA) certificates, whatever the put in working system (OS). Reported shims might be exploited to execute untrusted code throughout system boot, enabling attackers to deploy malicious UEFI bootkits (comparable to Bootkitty, HybridPetya, or BlackLotus) even on methods with UEFI Safe Boot enabled. We reported our findings to CERT/CC in February 2026, and the weak UEFI purposes had been revoked on Microsoft’s June 9^th, 2026 Patch Tuesday.

Whereas two CVE IDs had been assigned to this case to cowl the reported shims, CVE-2026-8863 and CVE-2026-10797, exploitation of every reported shim is not only a few single bug or two that may be present in these outdated shims immediately. The truth is, the assault floor is prolonged by the shims’ trusted, second-stage bootloaders (largely GRUB 2), which – just like the shims themselves – might embody outdated variations with recognized vulnerabilities. The found shims come from numerous instruments or software program packages, together with PC-diagnostics software program, Linux distributions, and different UEFI-based utilities. Importantly, exploitation is just not restricted to methods with the affected software program or OS put in, as attackers can carry their very own copy of the weak shims to any UEFI system with the Microsoft third-party UEFI certificates enrolled.

The total checklist of the software program merchandise counting on the reported shims together with their affected variations is accessible in CERT/CC’s Vulnerability Observe. In response to ESET researchers’ report, UEFI shim bootloaders with the next PE Authenticode hashes had been revoked within the dbx replace that was a part of Microsoft’s June 9^th Patch Tuesday:

• AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961
• 7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10
• EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A
• FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5
• A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4
• 95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06
• 236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B
• 5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B
• 8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963
• 410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373
• 96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629

Key factors of this blogpost:

• ESET researchers found 11 outdated, Microsoft-signed, UEFI purposes that permit bypassing UEFI Safe Boot on nearly all of UEFI-based methods.
• An attacker exploiting one in all these weak purposes can execute untrusted code throughout system boot, enabling deployment of malicious UEFI bootkits or different malware.
• Exploitation is just not restricted to methods with the affected software program or OS put in, as attackers can carry their very own copy of the weak binaries to any UEFI system with the Microsoft third-party UEFI certificates enrolled.
• All UEFI methods with Microsoft third-party UEFI signing enabled are affected (Home windows 11 Secured-core PCs ought to have this feature disabled by default).
• The weak binaries had been revoked by Microsoft within the June 9^th, 2026 Patch Tuesday replace.

Following is the coordinated disclosure timeline. We’d wish to thank CERT/CC for its assist in coordinating the vulnerability disclosure course of, and the affected distributors for easy and clear communication and cooperation in the course of the vulnerability disclosure and remediation course of. To guard your methods in opposition to this menace, set up the most recent Microsoft dbx updates. Directions on find out how to do that may be discovered within the Safety and detection part.

Coordinated disclosure timeline:

• 2026-02-16 – ESET reported the findings, together with a proof of idea, to CERT/CC.
• 2026-03-18 – dbx replace and public disclosure date was set to Could 19^th, 2026 (Microsoft’s Could Patch Tuesday).
• 2026-03-30 – dbx replace and public disclosure date was postponed to June 9^th, 2026 (Microsoft’s June Patch Tuesday).
• 2026-06-09 – Microsoft’s June Patch Tuesday replace, CERT/CC Vulnerability Observe revealed.
• 2026-07-14 – ESET blogpost revealed.

UEFI shim bootloader and UEFI Safe Boot

To know the influence that such weak shims can have on UEFI Safe Boot-protected methods, we have to perceive how UEFI Safe Boot works, and the way signed UEFI shim bootloaders lengthen the Safe Boot belief chain. On this part we’ll take a look at UEFI Safe Boot fundamentals, how UEFI shims lengthen the UEFI Safe Boot belief chain, and two shim-related options: Machine Proprietor Key (MOK) and Safe Boot Superior Focusing on (SBAT). For anybody already conversant in the speculation, we advocate leaping on to the part Bypassing UEFI Safe Boot utilizing outdated shims.

UEFI Safe Boot

As proven in Determine 1, when UEFI firmware masses a boot utility – like Home windows Boot Supervisor or a UEFI shim – it verifies the binary in opposition to two Safe Boot databases:

• db (allowed certificates and Authenticode hashes), and
• dbx (forbidden certificates and Authenticode hashes).

The picture have to be trusted by db and never listed in dbx – in any other case, the boot supervisor triggers a safety violation as an alternative of executing it. To make this work out of the field on newly bought gadgets with UEFI Safe Boot enabled, most OEMs enroll a set of Microsoft UEFI certificates within the db database, particularly:

• Microsoft Home windows Manufacturing PCA 2011 and Home windows UEFI CA 2023 (used to signal Microsoft’s personal UEFI boot purposes; the 2011 certificates can be added to dbx quickly because of the BlackLotus-related vulnerabilities).
• Microsoft Company UEFI CA 2011 and Microsoft UEFI CA 2023 (used to signal third-party UEFI boot software program, comparable to Linux shims, restoration instruments, and disk encryption utilities).

Which means that anybody wanting their boot-time software program to be UEFI Safe Boot-compatible by default can submit their binaries to Microsoft for signing via the Home windows {Hardware} Dev Heart, and as soon as authorized, the signed information turn out to be trusted on the overwhelming majority of UEFI methods. In consequence, Microsoft performs a central function in securing most UEFI-based gadgets, successfully deciding what’s, and what’s not, allowed to run throughout boot.

UEFI revocation (dbx)

UEFI Safe Boot’s revocation design is simple: when a beforehand trusted boot utility – one whose PE authenticode hash, or the certificates that signed it, is current in db – seems to be weak, its PE authenticode hash is added to dbx, the Microsoft-managed forbidden-signatures database (with the most recent dbx contents usually revealed in Microsoft’s GitHub repository). Certificates themselves are revoked solely often.

Whereas the unique concept of revoking particular person weak binaries by hash may need been cheap on the time Safe Boot was launched, circumstances comparable to BootHole and BlackLotus reveal that this method is way from superb. The basic difficulty is scale, and it’s effectively captured within the Purple Hat Bootloader Workforce’s SBAT proposal/specification:

As a part of the latest “BootHole” safety incident CVE-2020-10713, 3 certificates and 150 picture hashes had been added to the UEFI Safe Boot revocation database dbx on the favored x64 structure. This single revocation occasion consumes 10kB of the 32kB, or roughly one third, of revocation storage usually obtainable on UEFI platforms. As a result of approach that UEFI merges revocation lists, this plus prior revocation occasions can lead to a dbx that’s virtually 15kB in dimension, approaching 50% capability.

The identical stress on dbx capability surfaced once more with the BlackLotus-related revocations of weak Home windows Boot Supervisor binaries. Each of those prompted Microsoft, along with its companions, to introduce further, version-based revocation mechanisms, every tied to one of many two broadly deployed Safe Boot-compatible bootloaders:

• Safe Boot Superior Focusing on (SBAT) – utilized by shim, a UEFI bootloader for Linux, from model 15.3.
• Microsoft’s Safe Boot Safety Model Quantity (SVN) – utilized by Home windows Boot Supervisor (launched in April 2024) – additionally known as Revocation by way of Embedded Safe Model Info (REVISE) in Invoice Demirkapi’s Booting with Warning, p. 62; nevertheless, this identify and acronym don’t appear to be used within the official Microsoft documentation.

Briefly, the place dbx revokes binaries, SBAT and Microsoft’s Safe Boot SVN revoke variations. When a vulnerability is present in a UEFI utility supporting one in all these version-based revocation mechanisms, what actually must be stored out is each construct as much as and together with the damaged one – and that might be captured by a model quantity a lot simpler than by an extended checklist of hashes. We clarify extra about SBAT within the Safe Boot Superior Focusing on (SBAT) part.

UEFI shim bootloader and Safe Boot

With Linux distributions supporting UEFI Safe Boot, the above-described Safe Boot mechanism constructed round Microsoft keys introduces some challenges. Each Linux distribution generates its personal bootloader binaries, and every of them has a special hash. Getting each Linux bootloader signed immediately by Microsoft could be sluggish, bureaucratic, and impractical (if not not possible) to take care of throughout all Linux distributions.

The answer to this downside is a shim: a small, minimal first-stage bootloader that Microsoft can vet and signal as soon as, and which then creates a secondary belief anchor for the remainder of the Linux distribution-specific boot stack – often GRUB 2 and the Linux kernel. This belief anchor is one other certificates, known as a vendor certificates (managed by the distribution vendor), added to the shim binary earlier than it’s signed by Microsoft.

A simplified boot sequence on a Safe Boot-enabled Linux system utilizing a shim is depicted in Determine 2.

The UEFI firmware masses the shim and validates its signature in opposition to the Microsoft CA saved within the firmware (the db variable). The shim then takes over and validates the second-stage bootloader (usually GRUB 2) in opposition to its personal embedded vendor certificates – for instance, Debian’s UEFI key for Debian, Canonical’s UEFI key for Ubuntu, or Purple Hat’s key for RHEL and Fedora. GRUB 2, in flip, validates the kernel utilizing the identical vendor certificates earlier than handing over management. Each step is cryptographically vouched for by the step earlier than it.

This indirection implies that a Linux distribution can launch bootloader and kernel updates quickly, signing them with its personal vendor key, with no need to return to Microsoft for each replace. Solely the shim itself requires Microsoft’s signature – and it modifications sometimes.

Along with the seller certificates, the shim usually comprises one other built-in certificates related solely with the precise shim construct/binary. This certificates is sometimes called a shim certificates and is used to signal and confirm integrity of the shim’s utilities that may be generated in the course of the shim’s construct time, comparable to MokManager (used for managing MOKs and defined in additional element beneath) or the shim’s fallback.

Machine Proprietor Key (MOK)

When speaking about shims, we can’t skip one other necessary mechanism that permits a shim to make use of exterior keys managed by the person, often called Machine Proprietor Keys (MOKs). A MOK allowlist (consider it as a shim-specific “extension” of the UEFI db database) is saved in a boot-only NVRAM variable named MokList, and a forbidden checklist (the shim-specific “extension” of the UEFI dbx database) is saved in a boot-only NVRAM variable named MokListX; bodily entry is required to change each variables on a system with UEFI Safe Boot enabled (boot-only variables can solely be modified throughout boot, earlier than the OS loader calls the UEFI boot providers operate ExitBootServices). To handle the lists, the shim makes use of the MokManager UEFI utility. A information on find out how to handle MOKs might be discovered right here. Determine 3 illustrates how a MOK extends the shim’s UEFI Safe Boot belief chain.

As we described in our BlackLotus and Bootkitty discoveries, because of the non-authenticated nature of the boot-only NVRAM variables utilized by the MOK mechanism, bootkits are inclined to misuse MOKs for persistence as soon as they efficiently bypass UEFI Safe Boot.

Safe Boot Superior Focusing on (SBAT)

Every UEFI utility (part) that helps SBAT carries a small piece of metadata in a devoted .sbat part of its PE file, protected by the identical signature because the binary itself. The metadata names the part (for instance, shim or grub) and assigns it a era quantity that’s incremented each time a safety repair ships.

What turns these numbers right into a revocation mechanism is an identical coverage on the UEFI system itself: a boot-only UEFI variable named SbatLevel that information the minimal acceptable era quantity for every recognized part. Crucially, this variable is managed and enforced by the shim, not the firmware, which permits sooner revocation updates in comparison with a dbx replace. The shim embeds the coverage, so enforcement doesn’t rely solely on the exterior variable and incorporates any newer coverage supplied by way of SbatLevel. At each boot, the shim first verifies its personal SBAT metadata in opposition to the coverage – so an outdated shim might be made to reject itself – after which applies the identical take a look at to each binary it masses, refusing something whose era quantity falls beneath the minimal that the coverage calls for.

Examples of SBAT revocations are proven in Determine 4. These are taken from the SbatLevel_Variable.txt file positioned within the shim repository, which serves as the only supply for SBAT revocations.

The enforced degree isn’t hidden from the OS – the shim publishes a read-only copy of SbatLevel in a runtime variable, SbatLevelRT. The OS can examine which revocation coverage is at present in pressure, however can’t modify it. On Home windows the identical data can also be obtainable via the registry worth HKLMSYSTEMCurrentControlSetControlSecureBootSBATSbatLevel.

Bypassing UEFI Safe Boot utilizing outdated shims

Signing and compilation timestamps of the purposes trusted by the shims we reported span from 2013 to 2025 – sufficient to verify that a good portion of those binaries had been outdated and sure affected by quite a few publicly recognized vulnerabilities, together with the already talked about BootHole within the case of GRUB 2. Whereas most of those trusted parts are sufficiently old to hold some safety threat, GRUB 2 appears to be the weakest hyperlink. It’s a complicated piece of software program, and older variations accumulate vulnerabilities accordingly.

Contemplate the shim from Oracle Linux, which is amongst these we reported. It trusts binaries signed by a certificates issued to Oracle Company (SHA‑1 thumbprint: 2E434A724B4759C981E4189AA5AD3D635096DD2F). One of many binaries signed by that certificates is a GRUB 2 binary discovered within the Oracle Linux 7.1 set up ISO (V74844-01.iso). This binary is affected by CVE-2015-5281, which – quoting the vulnerability notice – “when used on UEFI methods, permits native customers to bypass meant Safe Boot restrictions and execute non-verified code by way of a crafted (1) multiboot or (2) multiboot2 module”. Each talked about modules, multiboot and multiboot2, permit loading of unsigned code throughout system startup utilizing the identically named instructions, and needs to be forbidden in signed UEFI Safe Boot-compatible GRUB 2 binaries, as they bypass UEFI Safe Boot by design.

The exploit is easy: there are not any reminiscence corruption bugs to set off, no ROP chains to assemble, and no complicated reverse engineering required. The one prerequisite is constructing a customized, unsigned multiboot2-compliant kernel picture – in observe, little greater than an ELF binary containing the required headers and a handful of different specifics. As soon as an attacker builds this binary and copies it to the EFI System Partition (ESP) together with the weak shim and GRUB 2, a single GRUB 2 multiboot2 command can be utilized to load and execute it throughout boot, Safe Boot enabled or not. A proof of idea demonstrating exploitation of CVE-2015-5281 by way of the outdated, reported Oracle Linux shim on a system with UEFI Safe Boot enabled (with out the most recent Microsoft patches utilized) is proven within the video beneath:

Absence of newer options

Through the years, the UEFI shim bootloader has naturally advanced, with new enhancements and safety features launched in successive releases of the upstream UEFI shim repository. On the similar time, many third-party distributors have taken obtainable variations of the shim supply code to construct their very own binaries, which they subsequently submitted to Microsoft for signing. This conduct is anticipated and aligns with the unique design of shims. Nevertheless, inadequate consideration has been given to revoking outdated Microsoft-signed shims, lots of which may, by design, be leveraged to bypass newer safety mechanisms. We illustrate this hole with just a few concrete examples.

MOK denylist enforcement

The MokList (MOK-based allowlisting) has been supported by the upstream UEFI shim since virtually the very starting (model 0.3). MOK revocations (MokListX), nevertheless, solely began to be enforced in model 0.9. Why is that an issue? Contemplate the next state of affairs…

An enterprise has enrolled its personal MOK to signal customized UEFI instruments and bootloaders that it deploys throughout its community. A vulnerability surfaces in a number of of these binaries, and in response, the directors revoke the outdated signing certificates by enrolling it into the MOK denylist (MokListX). Then, they enroll a contemporary MOK, and re-sign patched variations of the affected binaries with the brand new key. The outdated, weak binaries at the moment are rejected by the shim, whereas the newly signed ones load correctly, so the enterprise’s gadgets look safe. The outdated certificates stays current and trusted within the MokList, however is revoked in MokListX, the place it’s enforced as a higher-priority rule.

On this state of affairs, an attacker may substitute the sufferer’s up-to-date shim with an older Microsoft-signed UEFI shim from our report – for instance, model 0.8 from the Abitti 1 software program, signed by Microsoft for Finland’s Matriculation Examination Board. This shim nonetheless trusts the certificates saved within the sufferer’s MokList variable, the place the outdated MOK certificates stays legitimate, nevertheless it ignores MokListX, because it was constructed previous to the introduction of MOK denylist enforcement. In consequence, the attacker’s shim may very well be used to load weak binaries with out restriction, permitting arbitrary code execution or the set up of a malicious UEFI bootkit.

SBAT enforcement

The identical difficulty applies to SBAT. Help for it was launched upstream in shim model 15.3, so any earlier shim is unaware of the mechanism: it doesn’t learn the SbatLevel revocation coverage or examine the .sbat part of the second-stage bootloader it masses. In consequence, it ignores any later SBAT revocations meant to dam weak parts.

On this case, an assault state of affairs could be the next: an attacker takes a Microsoft-signed pre-v15.3 shim – such because the model 0.9 shim from Purple Hat Enterprise Linux 7.2 that was a part of our report – pairs it with one of many a number of GRUB 2 binaries that the shim nonetheless trusts however that SBAT has already revoked, after which copies each to the ESP. Throughout system boot, the shim validates the GRUB 2 binary in opposition to its personal embedded certificates, by no means consults SBAT, and masses the weak binary with out criticism – leaving the attacker free to take advantage of any vulnerability in that GRUB 2 binary.

Identified shim vulnerabilities

Lastly, outdated shims are merely outdated code, and far outdated code carries recognized vulnerabilities. For example this, we use an instance of an outdated difficulty affecting shims at model 0.9 and beneath. This vulnerability had no CVE ID assigned till our report – regardless that it was fastened and effectively described virtually precisely a decade in the past within the message of one of many shim repository’s upstream commits, d241bbb. It’s now tracked as CVE-2026-10797.

The problem is that an Authenticode-signed PE binary information its signature’s size in two impartial places:

• its PE header’s knowledge listing (IMAGE_DIRECTORY_ENTRY_SECURITY), and
• its WIN_CERTIFICATE construction, which encapsulates the signature itself.

Within the affected shims, the revocation verify and the signature verification capabilities diverged on which dimension worth they need to belief. The revocation verify used the worth from the signature header, whereas the signature verification operate used the worth from the PE header.

It’s thus attainable to bypass the revocation mechanism by tampering with the second-stage bootloader’s WIN_CERTIFICATE construction in order that the revocation operate compares dbx and MokListX in opposition to bogus knowledge as an alternative of the bootloader’s precise signature.

Merely put, even when the second-stage bootloader’s certificates had been revoked in dbx or MokListX, the shim wouldn’t discover out. Two necessary feedback right here:

• this bypass works solely with certificate-based revocations (not hash-based revocations), and
• the second-stage bootloader must be signed by a certificates embedded within the shim (whether or not it’s the shim’s built-in certificates generated in the course of the shim’s construct course of or the seller certificates).

These limitations come from the truth that hash-based revocations and non-embedded certificates (from MokList and db) are checked elsewhere within the code and should not affected by this difficulty.

Received’t expiring Microsoft UEFI certificates resolve this?

With the present Microsoft UEFI certificates expirations in thoughts (as proven in Determine 5, Microsoft Company UEFI CA 2011 expired on June 27^th 2026), one would possibly wonder if reporting weak UEFI purposes signed by this expired certificates is simply inflicting pointless noise.

The reality is that the UEFI certificates’s expiration date has no impact on the Safe Boot verification course of. If the Microsoft Company UEFI CA 2011 certificates stays in db, and isn’t revoked in dbx, all bootloaders validly signed with this expired certificates keep trusted if not explicitly revoked by hash. That is the explanation why Microsoft stored signing new submissions with the outdated certificates up till its expiration date.

Safety and detection

$hashes="AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961",
'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',
'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',
'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',
'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',
'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',
'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',
'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',
'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',
'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',
'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629' 
$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'
$notRevoked = $hashes | The place-Object { $dbx -notmatch $_ }
if ($notRevoked) {
    $notRevoked | ForEach-Object { "Hash not revoked: $_" }
} else {
    "All hashes revoked in dbx!"
}

For Linux methods, updates needs to be obtainable via the Linux Vendor Firmware Service, and the revocation standing might be checked utilizing the uefi-dbx-audit script.

For extra common suggestions concerning find out how to shield in opposition to (or not less than detect) exploitation of unknown weak signed UEFI bootloaders and deployment of UEFI bootkits, see our blogpost Beneath the cloak of UEFI Safe Boot: Introducing CVE-2024-7344.

Conclusion

What makes these outdated shims harmful is just not a novel vulnerability, it’s that no new vulnerability is required to bypass UEFI Safe Boot. An attacker wants no sophisticated exploitation primitives – solely a duplicate of an outdated, still-trusted, however unrevoked shim binary and a primary understanding of how UEFI shims work. That is sufficient to bypass such a necessary safety function as UEFI Safe Boot.

Whereas revoking these 11 shims addressed the instant difficulty, a deeper difficulty stays: visibility. The shim signing course of grew to become considerably extra clear in 2017 with the introduction of the shim-review repository, the place vendor submissions are vetted by maintainers earlier than Microsoft indicators them. Each shim authorized since then is documented – however these signed earlier should not, and nobody can reliably say what number of of these outdated, still-trusted shims stay. What has not been totally and transparently catalogued can’t be successfully retired.

On a optimistic notice, we consider that the development is shifting in the proper course. Every disclosure like this one shrinks the pool of forgotten shims, and with improved shim-signing transparency and mechanisms comparable to SBAT, preserving monitor of what must be revoked, and successfully revoking it, might be dealt with much more effectively than prior to now. The following step is to increase this degree of transparency in Microsoft’s third-party UEFI signing ecosystem to non-shim third-party UEFI purposes, which, as repeatedly demonstrated (e.g., CVE-2022-34302, CVE-2023-28005, CVE-2024-7344, CVE-2026-25250, …), may function an easy supply of UEFI Safe Boot bypasses.

IoCs

Because the weak shims are a part of professional software program packages which might be probably current on 1000’s of methods which have by no means been compromised by way of these loaders, we’re not offering indicators of compromise to keep away from large misidentification. As an alternative, defenders ought to observe the recommendation within the Safety and detection part.

For any inquiries about our analysis revealed on WeLiveSecurity, please contact us at threatintel@eset.com. 

ESET Analysis affords personal APT intelligence studies and knowledge feeds. For any inquiries about this service, go to the ESET Menace Intelligence web page.