The Byte Architect

Apple Defences - APFS and the SSV

2026-05-11T00:00:00+02:00

Skip the usual preamble: most of mine add no value anyway. This one’s different though.

Not the usual “It took me time to write…” - although it’s true. I took some days off, and days off imply no laptop.

Second - one of my previous posts (Filesystem Wars: Why Your Choice of Storage is Actually a Security Move) has been heavily criticised by trolls on Reddit. Therefore the linuxFanboysSuck or TrollTurd prompts. They wanted some visibility, here they go! Who am I to deny them the pleasure to embarrass themselves?

Third - the elephant in the room: I am not a native speaker. My English is what it is, and yes, I do use LLMs. Mainly to polish my English, and to soften my bluntness. The damn content is mine! If you want to understand the “LLM policy”, please have a read: Memento, deinde loquere To keep it short: LLMs are what saves people from sentences like “if you don’t like it, you can s** my mot* d** you a** * * ** *** *** **** ***** ….” (hope you recognised the Fibonacci sequence. If not, try the Fibonacci Soup. It’s the soup of yesterday mixed with the soup of the day before).

Introduction

So, what is this post about? Originally, I wanted to prepare something that showed how Apple uses APFS to build a strong defence for macOS. Then while writing the raw contents I realised that there’s a deeper strategy. I will try to describe it, but this is a broad topic, so I expect follow-up notes, corrections, and possibly a few errata corrigenda. TL;DR: if you find this article interesting, you may want to come back. So, we will see the filesystem and some other security controls interacting as a great example of Defence in depth.

I would also ask the readers to highlight aspects I forgot, and if you can link these concepts to others (even in other OSes), please feel free to get in touch with me. I am @gbiondo on the Mastodon instance infosec.exchange. Kudos, mentions, and toasts will be reciprocated!

How it all begins

You’re on Facebook/Reddit/OnlyFans/Instagram/../dirTransv/../Tinder/X and you see the usual newbie post:

I just installed Kali Linux on my machine. 
Now what?

Chances are that 97% of the answers are like

remove the french language support with

sudo rm -rf / --no-preserve-root

A touching example of community spirit, but the joke is so worn out by now that if you still type it, please stop reading me.

That command is meant to nuke the system. On modern Linux boxes, plain rm -rf / should be stopped by the default --preserve-root failsafe, but --no-preserve-root is literally there to bypass it. I haven’t bothered testing it on Linux for this post: the macOS side is what we care about, and the contrast with Linux is enough as a thought experiment.

But before applying the same prank to a macOS box — and seeing why it doesn’t quite work the same way — let’s look at how Apple has organised the filesystem.

Notice the philosophy: Unix tells you ‘I think you’re about to do something stupid, but I’ll let you’. macOS, as we’ll see, is going to tell you ‘you’re being stupid, and I won’t let you’ — which is either a feature or a bug depending on which side of the kernel you sit on.

The filesystem

Let’s take a quick step back to the structure of the filesystem. The APFS structure and operating philosophy have been already described in the aforementioned post, but just to refresh the ideas:

a disk is subdivided into partitions
in the normal case, a partition hosts an APFS container
the container hosts one or more APFS volumes
the free space inside the container is shared among those volumes, which can grow or shrink independently

This taxonomy is evident when using diskutil. From the man page:

**DESCRIPTION**

     **diskutil** manipulates the structure of local disks. It provides 
     information about, and allows the administration of, partitioning schemes, 
     layouts, and formats of disks. This includes hard disks, solid state disks, 
     optical discs, disk images, APFS volumes, CoreStorage volumes, and 
     AppleRAID sets.  It generally manipulates whole volumes instead of 
     individual files and directories.

Although the man page is quite useful, sometimes you just want the quick reference. Run diskutil without arguments and it will dump its help.

Let’s launch diskutil list to obtain:

gabriel@virtosaurus-erectus ~ % diskutil list

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *68.7 GB    disk0
   1:             Apple_APFS_ISC Container disk2         524.3 MB   disk0s1
   2:                 Apple_APFS Container disk4         62.8 GB    disk0s2
   3:        Apple_APFS_Recovery Container disk3         5.4 GB     disk0s3

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *13.6 MB    disk1
   1:                  Apple_HFS Guest                   13.6 MB    disk1s1
  

/dev/disk4 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +62.8 GB    disk4

                                 Physical Store disk0s2

   1:                APFS Volume Macintosh HD            12.6 GB    disk4s1
   2:              APFS Snapshot com.apple.os.update-... 12.6 GB    disk4s1s1
   3:                APFS Volume Preboot                 7.2 GB     disk4s2
   4:                APFS Volume Recovery                1.3 GB     disk4s3
   5:                APFS Volume Data                    2.8 GB     disk4s5
   6:                APFS Volume VM                      20.5 KB    disk4s6

This output is per se a small pedagogical masterpiece that shows the organisation/layering of APFS.

First: the output tracks three top-level disk devices, but one is synthesized. The (further!) abstraction layer introduced by APFS is made explicit by diskutil.

disk0 is the physical disk using a GUID Partition Table (yep - GPT. The tradition of acronyms is reaching its theoretical collision limits). It has three partitions:

Apple_APFS_ISC: the iBoot System Container (ISC). Contains system-critical boot material used by iBoot on Apple Silicon machines.
Apple_APFS_Recovery - the recovery container, hosting an independent recoveryOS.
Apple_APFS - the “real” APFS partition.

disk4 is the “materialisation” of disk0s2. In detail:

Disk	Label	Purpose
`disk4s1`	`Macintosh HD`	System volume
`disk4s1s1`	`com.apple.os.update-...`	Snapshot of `disk4s1`
`disk4s2`	`Preboot`	Kernel cache, boot policies, and boot support material
`disk4s3`	`Recovery`	recoveryOS. Local.
`disk4s5`	`Data`	Writable volume - more on this later
`disk4s6`	`VM`	Swap/Sleepimage. Isolated to ease wiping.

Why this organisation - it looks redundant and cumbersome! Hah, you puny penguin preacher, you don’t see the structure which I hide on purpose :). Look at the disk4s1 + disk4s1s1 combo: volume + snapshot. The system boots from the sealed snapshot, not from the writable volume. The snapshot is cryptographically sealed, and changing this would imply breaking a Merkle-tree-like chain of hashes that reaches up to Secure Boot. Therefore, attackers with root privileges can’t persistently write in /usr/bin because they’re not writing there at all. They’re writing to a volume that nobody reads at the next boot.

But actually this mechanism - cryptographically sealed volumes, which we are only glancing at now - probably grants one of the strongest forms of system integrity. Yeah, root cannot do everything (well… not really. But there are caveats.), but - do you really think that having a user who can do anything on a machine improves its security? Take your time, think about it…

Lately I think that root (both as user and privileges) is the toy of late-90s/beginning-2000s sysadmins. Great thing, sure… but the world has changed. Already the introduction of doas instead of su is a strong indicator. Personal opinion. But this blog is opinionated.

Snapshots

Now, look at this simple output:

gabriel@virtosaurus-erectus ~ % diskutil apfs list
APFS Containers (3 found)
|
+-- Container disk4 5531F5C3-04B2-45E4-84FE-72296C71CD67
    ====================================================
    APFS Container Reference:     disk4
    Size (Capacity Ceiling):      62826479616 B (62.8 GB)
    Capacity In Use By Volumes:   25124798464 B (25.1 GB) (40.0% used)
    Capacity Not Allocated:       37701681152 B (37.7 GB) (60.0% free)
    |
    +-< Physical Store disk0s2 0488C2FD-8C78-46F6-BB6A-D4215930C0EB
    |   -----------------------------------------------------------
    |   APFS Physical Store Disk:   disk0s2
    |   Size:                       62826479616 B (62.8 GB)
    |
    +-> Volume disk4s1 C806F908-958F-4945-ADB7-29B5646526E9
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk4s1 (System)
    |   Name:                      Macintosh HD (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         12551831552 B (12.6 GB)
    |   Sealed:                    Yes
    |   FileVault:                 No
    |   |
    |   Snapshot:                  7CF13368-3CF2-480F-8518-6626E86ACCFE
    |   Snapshot Disk:             disk4s1s1
    |   Snapshot Mount Point:      /
    |   Snapshot Sealed:           Yes
    |
    +-> Volume disk4s2 15FD3EDD-17B5-4855-8D8A-C76AA5EC5D18
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk4s2 (Preboot)
    |   Name:                      Preboot (Case-insensitive)
    |   Mount Point:               /System/Volumes/Preboot
    |   Capacity Consumed:         7238791168 B (7.2 GB)
    |   Sealed:                    No
    |   FileVault:                 No
    |
    +-> Volume disk4s3 AD1D82CF-E831-48FE-9A59-06E74FFEAA27
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk4s3 (Recovery)
    |   Name:                      Recovery (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         1251835904 B (1.3 GB)
    |   Sealed:                    No
    |   FileVault:                 No
    |
    +-> Volume disk4s5 D71D56D7-3D99-4793-A1B0-05E96D1B76E9
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk4s5 (Data)
    |   Name:                      Data (Case-insensitive)
    |   Mount Point:               /System/Volumes/Data
    |   Capacity Consumed:         3961692160 B (4.0 GB)
    |   Sealed:                    No
    |   FileVault:                 No
    |
    +-> Volume disk4s6 8E3E0F26-CE48-43AA-8D63-A59DC1A151FB
        ---------------------------------------------------
        APFS Volume Disk (Role):   disk4s6 (VM)
        Name:                      VM (Case-insensitive)
        Mount Point:               /System/Volumes/VM
        Capacity Consumed:         20480 B (20.5 KB)
        Sealed:                    No
        FileVault:                 No

(With the apfs list verb, diskutil gives us the APFS-native view: containers, physical stores, volumes, roles, snapshots, UUIDs, and space accounting.)

Focus on this detail:

    +-> Volume disk4s1 C806F908-958F-4945-ADB7-29B5646526E9
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk4s1 (System)
    |   Name:                      Macintosh HD (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         12551831552 B (12.6 GB)
    |   Sealed:                    Yes
    |   FileVault:                 No
    |   |
    |   Snapshot:                  7CF13368-3CF2-480F-8518-6626E86ACCFE
    |   Snapshot Disk:             disk4s1s1
    |   Snapshot Mount Point:      /
    |   Snapshot Sealed:           Yes

which actually shows how the mechanism works. The system volume is not mounted. But it has a snapshot, whose UUID is 7CF13368-3CF2-480F-8518-6626E86ACCFE, the snapshot disk is disk4s1s1. The OS runs from that snapshot.

Usually, under Linux and BSD, the filesystem is mounted at /. The neat result is that the user perceives “the system” and the root filesystem as the same thing. On modern macOS, this is not true. Macintosh HD - or better, disk4s1 is there, it exists. It occupies roughly 12.6 GB of space. But it isn’t mounted anywhere. What is really mounted on / is disk4s1s1, the snapshot.

Let’s explicitly observe something. Snapshots and seals are not “marketing-named defences”, such as “Gatekeeper” or “System Integrity Protection”. They’re just technical primitive features of APFS that Apple has also used to build some defences. For instance, most users first met APFS snapshots through Time Machine.

In fact - an APFS snapshot is a

point-in-time
read only
immutable version of a volume. It’s not a “real” copy, from this perspective; but since APFS is copy-on-write the snapshot shares blocks with the live volume until the user or an agent changes something. In that case, new blocks are allocated, but only for the delta. Initial cost: near zero. Time cost: O(delta). Plus the usual metadata tax.

This observation shows some technical properties that enforce the defensive character of the snapshot mechanism:

read-only. You cannot write to it. Not even with mount -uw. To modify a system running from a snapshot, one must modify the underlying System volume, create a new bootable snapshot, and make the system boot from it. With SSV, this also means dealing with the seal (we’ll get there, hold your horses).
atomic. The snapshot either exists or doesn’t exist: it sees a consistent point-in-time state, not a half-mutated filesystem. If you take a snapshot while you’re writing a file, the snapshot itself sees either the status before or after the writing operation. This results in integrity enforcement.
cheap to revert. Rolling back to a snapshot comes almost for free. It’s one of the mechanisms behind the “Restore to previous version” functionality we see on many backup systems.

Sealing

A snapshot is immutable by construction, we saw. Sealing adds a cryptographic verification of its integrity.

Apple builds a Merkle-tree over the contents of the sealed System snapshot. Each block is hashed, the hashes are grouped in nodes, up to a root (of the tree… too many roots here.)

The root hash — the seal — is then signed/trusted as part of Apple’s boot chain.

That Sealed: Yes displayed by diskutil is APFS telling you: this object is not merely read-only; it has a cryptographic seal.

At boot time, depending on the Mac generation, iBoot or the boot chain verifies the seal before the snapshot becomes /. If the hash does not match, the seal is considered invalid and the normal boot process aborts. This is the main difference with “read-only mounting” a volume. A read-only volume can be written, provided one has the right privileges to do so. A sealed volume cannot - even if someone could write on it, the seal would be invalid at the next boot.

Putting it all together: SSV

If:

the volume is sealed (Sealed: Yes)
the snapshot is sealed (Snapshot Sealed: Yes)
andSnapshot Mount Point: / …then we have the so called Signed System Volume (SSV). It is not a different volume, but the configuration of a system volume and its snapshot, properly sealed. Apple calls it SSV.

The boot sequence becomes:

iBoot (or the boot chain) verifies the kernelcache signature
iBoot verifies the snapshot seal against Apple’s signing keys (the root of the Merkle tree)
If the seal is valid, then
- kernel mounts the snapshot as /
otherwise, it rejects it.

When it comes to updating, the flow (very simplified, here) becomes:

Apple signs a new system volume
the updater writes on the “live” volume (i.e. disk4s1), which is unmounted
a new snapshot is created
its seal is verified
if verification passes, the new snapshot becomes the boot snapshot and the system reboots into it. The old snapshot stays as fallback: if something goes wrong, you can still boot the previous OS state.

Some important observations are required, here.

First, to remove all ambiguities: it is important to state clearly that this is not SIP. Here two filesystem primitives (snapshot and seal) and an architectural choice (booting from the snapshot) have been assembled together to build another layer of defence, independent from SIP. SIP deals with the enforcement of kernel policies at runtime, whilst SSV is a structural property of the filesystem. They strengthen each other, but they are independent.

Second: the seal is not “every single file is signed by the OS”. The seal is just a hash, namely the root of the Merkle tree, that covers the entire volume. There is only one signature — well, Fibonacci and Recursion would probably object, but I trust the common sense of the reader. What changes is the underlying tree. This is important because it has impacts on performance. In fact, to check the seal at boot time it is sufficient to check the root against Apple’s signature. If something has been tampered with, the hashes don’t match. It’s not even important understanding where and why the hashes don’t match: the system does not boot anyway. Furthermore, APFS can verify subtrees on demand when it reads blocks. This means that even at runtime, reading a file from the system volume implies a cryptographic check from the path of the file up to the root. Therefore, a runtime tampering is immediately detected. Finally, if Apple had to sign every single file, each update would require a tremendous amount of signatures and a gigantic trust structure in place. With Merkle trees, only one item is signed.

Third, a security observation. During the years we saw several SIP bypasses (Shrootless CVE-2021-30892, “migraine” CVE-2023-32369, …). Breaking the SSV is a different thing. It would require breaking the underlying cryptographic algorithms, not “finding an entitlement that breaks policies”.

The canonical tool to observe the status of SSV is csrutil. By the way, it is also used to investigate the SIP status - which is probably what justifies some of the common misunderstandings about the two technologies.

Launched without arguments, as usual, it gives a short help page:

gabriel@LinuxFanboysSuck ~ % csrutil
usage: csrutil <command>
Modify the System Integrity Protection configuration.
Available commands:

    clear
        Clear the existing configuration.
    disable
        Disable the protection of the OS installation. Only available in 
        Recovery OS.
    enable
        Enable the protection of the OS installation. Only available in Recovery 
        OS.
    status
        In Recovery OS, displays the configuration for each OS installation.
        In macOS, displays the configuration of the running OS.

    allow-research-guests
        status
            Show the current allow research guests setting.
        disable
            Disallow research guests. Only available in Recovery OS.
        enable
            Allow research guests. Only available in Recovery OS.

    authenticated-root
        status
            Show the current authenticated root setting.
        disable
            Allow booting from non-sealed system snapshots. Only available in 
            Recovery OS.
        enable
            Only allow booting from sealed system snapshots. Only available in 
            Recovery OS.

Observe how the most important features require booting in Recovery OS (keeping the power button pressed for a while during restart on Apple Silicon machines). In other words, the user must lower the security level to change these values.

On a fresh system, like the one I am using now:

gabriel@LinuxFanboysSuck ~ % csrutil authenticated-root 
Authenticated Root status: enabled

(it looks like status is not required, actually).

However: Authenticated Root is the csrutil name for the SSV-related control. It is important also to read between the lines: the “authenticated” framing is stricter than “signed”, from a logical perspective. Actually, authenticated here means that the root — both the filesystem root and the Merkle-tree root; yes, enjoy the pun — is checked before being trusted. It is an active authentication, not a passive property.

Conclusions

If you were wondering: what happens if you ran sudo rm -fr / --no-preserve-root on a Mac? Well — not much, at least where the sealed system is concerned.

System applications remain mostly there:

gabriel@virtosaurus-erectus ~ % ls /System/Applications 
App Store.app		Font Book.app		Music.app		Siri.app
Apps.app		Freeform.app		News.app		Stickies.app
Automator.app		Games.app		Notes.app		Stocks.app
Books.app		Home.app		Passwords.app		System Settings.app
Calculator.app		Image Capture.app	Phone.app		TextEdit.app
Calendar.app		Image Playground.app	Photo Booth.app		Time Machine.app
Chess.app		iPhone Mirroring.app	Photos.app		Tips.app
Clock.app		Journal.app		Podcasts.app		TV.app
Contacts.app		Mail.app		Preview.app		Utilities
Dictionary.app		Maps.app		QuickTime Player.app	VoiceMemos.app
FaceTime.app		Messages.app		Reminders.app		Weather.app
FindMy.app		Mission Control.app	Shortcuts.app

/Applications takes some damage, nevertheless: the Utilities subdirectory is gone.

gabriel@virtosaurus-erectus ~ % ls /Applications 
Safari.app

Unsurprisingly, the structure of the home folder does not change:

gabriel@virtosaurus-erectus ~ % ls ~/
Desktop Downloads Movies Pictures
Documents Library Music Public

This is just to give you the idea. However, I ran that rm on a machine with no SIP/SSV changes. The next time, I promise, I’ll bring you the results on a tweaked machine.

We’ll catch up in a week or so, with some more tests and a discussion on SIP. Or on the Fibonacci Soup. You’re welcome to cook it.

Stay paranoid, and have fun. Cook some Soup.

Memento, deinde loquere

2026-04-24T00:00:00+02:00

Memento, deinde loquere is the latin equivalent of “Think first, then speak”.

This post is meant to bring some clarity on my approach to LLMs and the way this technology is used within all my websites.

I am a non-native English speaker and this shows in my communications. My sentences tend to be quite long, with several “relative clauses” or “subordinate clauses” (this latter aspect depends on the specific region I come from. For those who do not know - and I expect them to be the majority of my readers, a relative clause is one introduced by that, which and similar particles). Don’t misunderstand me: being Italian, I have a very good English - at least this is what native speakers say. How do I rate myself? I know that I am not at the “It’s a me, it’s a Mario”/”the cat is on the table” level - but I also appreciate the fact that the real English is something else.

With that being said: I use LLMs only to polish my English. Ah, yeah, and also to flatten somehow my tone - because I am the guy who loves to send people where they belong. Content is mine, nevertheless.

It’s just a matter of respect for the readers - I don’t want to force anyone to waste their time rebuilding my sentences. Sic et simpliciter.

My personal opinion on LLM? It’s a great technology. It could be even better if access to it were regulated differently. However, this would be a long discussion — too long for this blog.

And this brings us to another point - why I wrote this post.

A few days ago I published a post on this blog, and I cross-posted it on Reddit and Mastodon. Usual way to harvest a few readers. It’s a great post, in my opinion: it is conceptually very dense, and this reverberates through its length (7k words). On r/linuxadmin several people attacked me with accusations like “you used LLM”, “LLM Slop”, “LLM Hallucination”.

Then I went through their profiles: very high karma subdivided as:

high comment karma
low post karma I scanned their posts and comments and found the posts quite boring (really, nothing to learn there); while a lot of comments were like:

bash

postgres

or even - and this is the pinnacle of their reasoning

💩

You can have fun with math and realise that the ratio of comment karma to post karma could be a good metric to detect trolls. In that case, be my guest - find the right parameters yourself. A trivial formula could be:

\[TI = \frac{K_c}{K_p + 1}\]

$TI$ troll index; $K_c$ Karma comments; $K_p$ Karma post.

If $TI>100$ and comments are one-liners or emojis, here you go: a troll in sight!

Dealing with trolls is a waste of time. Nevertheless, this post is also for them - I’m not sure they’ll understand, but at least no one can question my good will.

I am not here to teach people how to live, and I really don’t care what people do for a living. I am not here to teach people the difference between constructive criticism and some random rant, either

One thing is for sure: I profoundly pity people who identify with a given technology, making it a religion (and well, many Linux fanboys don’t know how to do any better), or worse: an extension of their persona.

The bottom line is extremely simple.

Dear Troll - you’re surely entitled to your opinion. I am entitled not to give a fuck about it. But please, don’t show what a thermal waste you are in public - that’s revolting, and you’re embarrassing yourself. Your miserable existence is not our fault.

I won’t be posting to r/linuxadmin anymore. It’s a toxic environment, pretty much like Facebook. Ad futuram rei memoriam…

Filesystem Wars: Why Your Choice of Storage is Actually a Security Move

2026-04-20T00:00:00+02:00

While this post isn’t part of my ‘Canonical Series,’ it serves to lay the groundwork for an upcoming instalment in my ‘Apple Defenses’ series.

We’ll be exploring file systems from a high-level perspective, skipping disk geometry and low-level parameters in order to focus on the core concepts behind the most widely used systems, their overall design, and their respective strengths and weaknesses.

Enter the arena

We will be focusing on the following filesystems.

Filesystem	Role
FFS / FFS2 (Fast File System)	The noble ancestor
BFS (Be File System)	The forgotten innovator
NTFS (New Technology File System)	An industrial standard
ext4 (Fourth Extended Filesystem)	Linux’s reliable workhorse
ZFS (Zettabyte File System)	The champion of data integrity
APFS (Apple File System)	Our main character

In memoriam - ReiserFS

I used this one extensively back in my “Linux fanboy era”—a phase that, fortunately, is long behind me. The community has essentially deprecated it, and for reasons that have nothing to do with code.

Among sysadmins, there’s a grim, recurring mantra: “ReiserFS is the only filesystem capable of making files disappear without a trace… just like its author did with his wife.”

Sic transit gloria mundi — Ford Transit Gloria Guida.

THE FUNDAMENTAL PROBLEM: Crash Consistency

Filesystem operations are not atomic at the hardware level. Creating a file involves multiple disk writes: allocate blocks, write data, create inode, update directory entry.

If the system crashes mid-operation, you can end up with orphaned blocks (space leak), dangling pointers (corruption), or directory entries pointing to garbage.

Every filesystem must solve this. Two classic solutions:

Journaling (NTFS, ext3/ext4): Write-ahead logging. Write intended changes to a journal first, then apply them to the filesystem. If a crash occurs, replay the journal. The cost: metadata is written twice (journal + final location).

Soft updates (FFS/FreeBSD): Track metadata dependencies and enforce write ordering. Never write a pointer before the thing it points to exists on disk. If a crash occurs, the filesystem is always consistent; worst case is a space leak, which background fsck reclaims. The cost: none (single writes).

We will see both approaches in action below.

FFS/FFS2

UFS, the old Unix filesystem, kept metadata and data far too far apart. Inodes lived near the beginning of the disk, while data blocks were pushed toward the end. The result was obvious: read inode, seek; read data, seek again; repeat. On spinning rust, this was performance hell.

FFS solved that problem with one of the most important ideas in filesystem history: cylinder groups. Instead of treating the disk as one monolithic space, it split it into smaller regions and gave each of them its own local inode table, local data blocks, and a backup copy of the superblock. In plain English: keep related things physically close. Put files near their metadata, keep related files near each other, and replicate critical metadata so recovery remains possible if one copy gets corrupted.

That alone was a huge step forward. It reduced seek times dramatically, improved locality, and established a pattern that influenced basically every serious Unix filesystem that came after it. ext4, ZFS, APFS: different worlds, different philosophies, but all of them live downstream of ideas that FFS helped define back in 1984.

So, if I had to compress its philosophy into one sentence, it would be this:

Simple, reliable, UNIX-native fundamentals — no feature bloat, just solid engineering.

Key architecture

The heart of FFS is still cylinder groups: metadata and data are kept close to each other, related files are often placed in the same region, and superblock redundancy gives the filesystem a chance to recover even when part of the disk goes bad.

Where things get particularly elegant is with soft updates, a major FreeBSD innovation. Instead of journaling every metadata operation, FFS tracks metadata dependencies and enforces the only rule that really matters: never write a pointer before the thing it points to exists on disk.

When creating a file, the dependency chain looks like this:

Creating a file is not one operation but a dependency chain: first the blocks must exist and be marked as allocated; then the inode may point to them; only after that may the directory entry link the filename to that inode.

This ordering matters because it determines what happens if the system crashes halfway through the operation.

If the crash occurs after blocks have been allocated, but before anything points to them, the result is simple: some blocks are marked as used, but no inode references them. That is a space leak, not corruption, and fsck can reclaim the leaked space later.

If the crash occurs after blocks have been allocated and data has been written, but before the inode exists, the situation is still the same in practical terms: leaked space, no structural corruption.

If the crash occurs after the inode has been created, then the inode points to valid data blocks, but no directory entry references it yet. In other words, the file exists, but it is orphaned. fsck can recover it by linking it into lost+found/, or remove it if needed.

If the crash occurs after the directory entry has been updated, then the operation is complete and the file is fully visible. No recovery is needed.

That is the beauty of soft updates: no journal, no double writes, no need to replay intent logs just to get back to a sane state. The filesystem remains consistent because write ordering prevents invalid references from ever reaching disk.

The tradeoff is equally clear: recovery is not as immediate as with journaling. You may still need fsck in the background to reclaim leaked space or clean up orphaned objects. But the key point is that the filesystem does not collapse into corruption.

UFS2 extends this design without betraying it: 64-bit support, larger filesystems, larger files, extended attributes, POSIX.1e ACLs, and larger inodes. Evolution, not reinvention.

Then there are the flags, which remain one of the nicest BSD touches: chflags immutable can prevent modification even by root, while chflags sappnd gives you append-only semantics that are still genuinely useful for logs and operational hardening. Nothing magical, nothing cryptographic, just simple kernel-enforced constraints that still matter.

Security model

The security model is classic BSD pragmatism.

POSIX permissions provide the standard user/group/world (rwx) access model.

ACLs, in UFS2, add finer-grained control through POSIX.1e semantics.

Flags such as immutable, append-only, and nodump go beyond plain POSIX permissions and give the administrator a few extra levers that are small, simple, and surprisingly effective.

What FFS/UFS2 does not provide is native encryption. On BSD systems, encryption is handled below the filesystem layer: on FreeBSD, that typically means GELI or, historically, GBDE.

Operational assumptions

FFS/UFS2 was designed for BSD systems: FreeBSD, OpenBSD, NetBSD.

Its assumptions are old-school and very clear: reliability matters more than flashy features, and consistency matters more than novelty. Soft updates give it crash safety without the overhead of full journaling, which is exactly the kind of engineering tradeoff BSD people tend to appreciate.

Portability, on the other hand, is not really its game. Outside the BSD world, UFS support exists mostly as a compatibility story, not as something people seriously build modern systems around.

Weaknesses

Its weaknesses are exactly what you would expect from a design with roots in 1984.

There is no native encryption.

There is no CoW model, so fragmentation remains a fact of life, even if the layout is smarter than old UFS.

Snapshots exist only as bolt-ons in specific BSD environments; they are not a native, first-class mechanism in the ZFS or APFS sense.

And, of course, portability is limited: this is fundamentally a BSD filesystem, not a cross-platform citizen.

Overall commentary

FFS is 42 years old. It predates Linux. It predates ext2. And yet, it still matters, because it defined what a serious Unix filesystem was supposed to look like.

Cylinder groups, soft updates, file flags: these are not random features. They are design patterns. Later filesystems either inherited them, adapted them, or reacted against them.

Is it cutting-edge? Obviously not. Does it offer ZFS-level integrity guarantees or APFS-style OS integration? No.

But it is still trusted by FreeBSD and OpenBSD for core system roles, and that tells you a lot. FFS did not win by being flashy. It won by being disciplined.

It taught filesystems how to be faster through locality. It taught them how to stay consistent without drowning in complexity. And it did that without turning itself into a monster.

Respect the ancestor.

ZFS (Zettabyte File System) — Sun Microsystems / OpenZFS

We can formalise the philosophy of this filesystem as:

The filesystem IS the volume manager IS the RAID controller.

Key architecture

Pooled Storage: In ZFS, partitions are a thing of the past. You create a storage pool (zpool) and then “carve” datasets or volumes out of it as needed.

Copy-on-Write (CoW): This is the core engine. The file system never overwrites data in place; it writes new blocks and updates pointers atomically, ensuring consistency.

End-to-End Checksums: Every block is checksummed, and that checksum is stored in the metadata that references the block rather than inside the block itself. Every read operation can therefore be verified independently.

Snapshots & Clones: Thanks to CoW, snapshots are nearly “free” (low overhead). You can keep them indefinitely, and cloning is as simple as creating a writable branch from a snapshot.

Self-Healing: If configured with RAID-Z or mirrors, ZFS automatically detects bit rot via checksums and repairs the corrupted data using a healthy copy.

Security model

Data Integrity: This includes protection against silent corruption, integrity verification through end-to-end checksums, and near-instant recovery through snapshots and rollback.

In more detail, ZFS stores block checksums in the metadata that points to those blocks, creating a hierarchical chain of verification across the tree. This is not a substitute for a formal digital signature, but it provides a robust mechanism for detecting corruption and certain forms of unauthorized modification.

Encryption: Added later in the development cycle (notably in OpenZFS), encryption was not part of the original Sun Microsystems design. It operates as block-level encryption with external key management, allowing for encrypted datasets that can be replicated even without the host knowing the key (blind replication).

Access Control: ZFS provides no granular access control at the filesystem layer itself; it relies entirely on standard POSIX permissions (or ACLs depending on the OS implementation).

Operational assumptions

Designed for servers/NAS with large storage pools, ECC RAM (recommended), and multiple disks.
Expects you to care about data integrity over decades.
Not plug-and-play: you do not just format a random disk and mount it elsewhere. Pool metadata is complex.

Weaknesses

RAM-hungry (ARC cache).
Linux support = third-party (licensing issues with kernel).
Overkill for single-disk laptops.

Overall commentary

It’s my default choice on FreeBSD. I am not a FOSS crusader, and I couldn’t be arsed with all that licensing rubbish; therefore in my case the pros outweigh the cons. Whilst I think it’s overkill for laptops, my FreeBSD laptop still uses it :)

BFS (Be File System) — BeOS / Haiku

The philosophy of this file system was simple yet revolutionary:

Metadata isn’t just storage overhead. It’s queryable data.

Let’s address the elephant in the room: when I first saw BeOS back in 1997, I immediately fell in love with it. I still miss it—not in a misty-eyed, nostalgic way, but in a “they solved problems in 1997 that everyone else ignored for 20 years” kind of way.

BFS treated metadata as first-class citizens. You didn’t just grep filenames or rely on fragile directory hierarchies. You queried the file system like a database:

“Show me all MP3s where Artist contains ‘Sabbath’ and Bitrate > 256kbps.”

The file system answered instantly. No heavy indexing daemons, no Spotlight-style background crawlers eating your CPU. The file system WAS the index.

Key architecture

Journaling: Metadata journaling for crash recovery (relatively novel for 1997).

Attributes: Arbitrary key-value metadata on files (not just POSIX extended attributes: BFS could actually query them).

Live Queries: Real-time FS queries updated automatically as files changed.

B+ Trees: Core structures relied on B+ trees, which helped BFS scale efficiently and suited the media-heavy workloads BeOS cared about.

Here some further notes deserve their own space:

Live queries (the magic touch): If you had a folder (read - a saved query) that showed all incoming mails from James and a new mail from James came in, it would appear in the folder automatically. No refresh, no lag. The “dynamic folder” concept done well. 30 years ahead of its time.
B+ Trees: interestingly, BFS used B+ trees for attributes, not only for files. That’s why queries were almost instantaneous: the system was not scanning a disk - it was an efficient visit on a balanced, pre-indexed tree.
A note: relation with APFS - Dominic Giampaolo, the author of BFS, joined Apple after Be closed their doors. He’s been one of Spotlight’s lead engineers and worked extensively on APFS.

Security Model

Sadly, the security model of BFS was minimal:

POSIX permissions (user/group/world), nothing more.
No encryption.
No ACLs.
No advanced security features.

This is understandable: BeOS was designed for multimedia performance, not enterprise security. And we are talking about the late 1990s, when security was rarely front and centre.

Operational Assumptions

BFS was designed for BeOS/Haiku (desktop OS, multimedia-focused), and optimized for low-latency media access (video editing, audio production).

Journalists at trade shows would boot BeOS on a BeBox and play eight simultaneous video streams. Jaws dropped.

Weaknesses

Let’s be clear: this should be seen as a research-ish filesystem. If you approach it from that angle and focus on its strengths, it becomes a great source of ideas.

The truth of the matter is that BeOS died in 2001. Palm bought the corpse for a while. Haiku keeps BFS alive, but it’s a hobbyist OS.

The lack of modern security and portability already makes this filesystem an interesting case study, but not a viable alternative.

Overall Commentary

Be, Inc. had it right: filesystems aren’t just block allocators; they’re application platforms.

BFS proved that metadata queries could be fast, intuitive, and part of the user experience rather than bolted-on search tools.

Apple didn’t copy BFS (they barely acknowledged it existed), but they learned the same lesson 20 years later: the filesystem is part of the OS identity, not just infrastructure.

I still miss BeOS. But APFS is the closest thing to a spiritual successor—not in features, but in philosophy.

NTFS

I am not a Windows guy, but NTFS still deserves its tribute. It has been carrying most of the personal computing world for more than thirty years. It predates the web browser. It was designed when 1 GB hard drives were cutting-edge and Windows NT still ran on RISC workstations. And yet, in 2026, it is still the default filesystem on ordinary Windows systems. Microsoft tried to push ReFS as the future, but NTFS is still what normal Windows machines actually run. Some technologies age gracefully. NTFS just refuses to retire.

Its philosophy is something like:

Enterprise filesystem built for IT departments that need ACLs, audit trails, and endless backward compatibility.

Or, less politely:

What happens when you design a filesystem to satisfy legal compliance and still run software from 1993.

Whatever. Let’s pay respect to NTFS anyway.

Key Architecture

MFT (Master File Table): Everything is represented as a file, including metadata. The MFT is effectively a giant database of file records.

Journaling: Logs metadata changes for crash recovery.

Not CoW: NTFS overwrites in place; the journal records intent and metadata updates.

Alternate Data Streams: Files can contain multiple streams beyond the main unnamed one. Legitimate feature, excellent hiding place, and therefore catnip for malware.

ACLs: Fine-grained permissions with allow/deny entries, inheritance, and auditing.

EFS / BitLocker: Per-file encryption with EFS, full-volume encryption with BitLocker.

Security Model

ACLs: Powerful, flexible, and borderline Byzantine. Deny rules, inheritance chains, audit entries, the whole cathedral.

EFS: Per-file encryption tied to user certificates. Functional, but awkward. Recovery agents exist, key management is very Windows, and it can become painful when profiles or certificates go sideways.

BitLocker: Full-volume encryption, usually TPM-backed. Separate from NTFS in architectural terms, but it is the encryption layer that actually won on Windows.

USN Journal: Persistent change log useful for forensics, backup, and monitoring.

Operational Assumptions

NTFS is built for Windows desktops and servers.

It expects NTFS-aware tooling: chkdsk, defrag, the Windows permissions model, and the usual Microsoft admin machinery.

It is only partially portable. Linux can handle it with external drivers such as ntfs-3g; macOS traditionally exposes it as read-only unless you go out of your way.

Weaknesses

The expected ones.

Fragmentation: No CoW means files can scatter over time. Defragmentation mitigates it; SSDs make it less visible, but the design is still old-school.

No native snapshots: Volume Shadow Copy is an OS service, not a filesystem-native mechanism in the ZFS/APFS sense.

EFS: Still there, still usable, but clearly overshadowed by BitLocker and much more fragile operationally.

Proprietary: Microsoft has published a fair amount, but the ecosystem still carries enough opacity to keep reverse engineers employed.

Complexity overhead: ACLs, ADS, reparse points, legacy semantics. More features, more weirdness, more attack surface.

Overall Commentary

NTFS is the filesystem nobody loves and everybody uses. It is over-engineered for edge cases most users will never hit, yet somehow still full of compromises.

It fragments like it came from another century. EFS exists, but BitLocker won the encryption war long ago.

But here is the thing: it works. Billions of Windows machines run NTFS without catastrophic drama. It is boring, legacy-laden, and inelegant, but reliable enough for enterprise reality. I would not choose it if I had a real choice.

But if you live in Windows-land, it is not the worst prison.

Ext4

I discuss ext4 together with NTFS because, to me, they feel oddly similar. I know many Linux fanboys will send ninjas to my house to kill me, and I have probably already received three fatwas from the Holy Linux Inquisition, led by Mr. Stallman and the Seven Dwarves, for the previous sentence. I don’t really care.

ext4 is Linux’s default answer to “what filesystem should I use?” It is not exciting. It does not chase paradigm shifts. It just works, predictably, across millions of deployments.

As the fourth iteration of the Extended Filesystem lineage (ext2, ext3, ext4), it represents evolutionary refinement rather than revolutionary redesign. Think of it as the Toyota Camry of filesystems: boring, reliable, and nobody ever regrets choosing it.

It shipped in 2008 with kernel 2.6.28, which makes it 18 years old in 2026. Not ancient like FFS, not cutting-edge like APFS, just… dependable.

So, to honour the structure of this post, let’s get to the philosophy. Let’s say ext4 is:

The iterative workhorse: backward-compatible evolution focused on reliability over revolution.

Or, better still:

What happens when you take a solid foundation (ext2) and incrementally fix its problems for 20 years without breaking anything.

Key architecture

ext2 and ext3 relied on indirect block pointers. ext4, instead, moved to extents: contiguous ranges of blocks described as something like (start_block, length). This brings several advantages: less metadata overhead, better large-file performance, and reduced fragmentation.

Journaling is inherited from ext3. ext4 still has no native CoW: it overwrites in place, while the journal records metadata changes and ordering semantics. It offers three journaling modes:

data=journal (safest, slowest — journals both metadata and data)
data=ordered (default — journals metadata, but forces data blocks out before the related metadata is committed)
data=writeback (fastest, least safe — journals metadata only, with no ordering guarantees for data writes)

Still on CoW: the lack of native Copy-on-Write means no cheap clones, no native snapshots, and no automatic deduplication.

Delayed allocation: block allocation is postponed until writeback. Dirty data accumulates in memory, allowing the filesystem to batch writes and choose optimal block placement before committing to disk. The upside is better block placement, less fragmentation, and often fewer writes. The downside is that a crash can still lose recently written data before commit. Journaling helps with consistency, but it does not magically turn ext4 into CoW. Journaling has overhead — every metadata change is written twice (once to journal, once to final location). This is the price of crash safety. Note also that data=journal disables delayed allocation.

ext4 can grow a filesystem while mounted via resize2fs, and filesystems can also be shrunk while unmounted. There is also e4defrag for defragmentation — rarely needed, but it exists.

We mentioned snapshots. ext4 has no native snapshot facility, unlike ZFS or APFS. LVM can provide snapshots, but that is OS-level plumbing, not a filesystem-native feature.

Security model

POSIX permissions + ACLs: standard Linux access control with user/group/world (rwx) permissions, plus optional ACLs via setfacl/getfacl when finer-grained control is needed. Solid, unsurprising, and good enough for most Unix-like workloads.

The filesystem also supports native encryption via fscrypt, introduced for ext4 in the Linux 4.1 timeframe. This is directory-tree-based encryption rather than full-disk encryption: you apply a policy to a directory, and the files and subdirectories under it are protected accordingly. Keys live in the kernel keyring, not on disk. A typical use case is protecting user data at rest, for example under /home.

Its obvious limitation is that this is not the same thing as full-volume encryption: some filesystem metadata remains visible (directory structure, file count), and without the key, filenames appear as base64-encoded ciphertext rather than readable names.

From a security standpoint, ext4 also offers two simple but useful features: immutable and append-only flags:

chattr +i (immutable — cannot modify, delete, or rename)
chattr +a (append-only — can add data, cannot modify existing content)

These provide basic tamper resistance. Nothing cryptographic, just kernel-enforced constraints.

Operational Assumptions

ext4 is designed for Linux servers and desktops.

It is still the default choice in many Linux environments, and very much the expected baseline in the Debian/Ubuntu world. Fedora Workstation moved to Btrfs long ago, and RHEL prefers XFS, but ext4 remains the boring, familiar standard Linux admins know by heart.

Standard Linux tooling (e2fsck, tune2fs, resize2fs, e4defrag) is part of the deal.

Portability

Linux-native (obviously)
Windows: third-party drivers and tools exist
macOS: readable via third-party tools and FUSE-based solutions
Not plug-and-play outside Linux

Other weaknesses

We already covered the CoW-related trade-offs and the fragmentation angle, even if ext4 mitigates both reasonably well.

Another thing I personally miss: ext4 journals metadata, but it does not provide end-to-end integrity checking for file data in the ZFS/APFS sense. Metadata checksums exist, but silent corruption in file contents is still a real possibility.

Overall commentary

Remember when I said ext4 and NTFS feel oddly similar? This is the reason.

They solve the same class of problems in roughly the same conservative way. Both are journal-based. Both overwrite in place. Both can fragment, although ext4 handles that a bit more gracefully through delayed allocation. Encryption arrived late in both worlds: EFS and BitLocker on the NTFS side, fscrypt on the ext4 one. And neither gives you native snapshots; if you want those, you go outside the filesystem itself—VSS for Windows, LVM for Linux.

In other words, both are defaults built for the real world: legacy constraints, predictable behaviour, and minimal drama. Architectural purity was never the point.

The real difference is cultural. ext4 evolved incrementally and in the open, through the gradual evolution of ext2, ext3, and ext4. NTFS evolved by Microsoft decree, accumulating thirty years of Windows baggage along the way.

Different ecosystem, different politics, similar result: dependable, boring, and exactly what millions of users need.

ext4 is what you get when you evolve carefully instead of revolutionising recklessly. It is not sexy. It does not have ZFS’s checksums or APFS’s sealed-volume theatrics. It fragments, although delayed allocation helps. It lacks native snapshots.

But here is what it does have: years of production hardening, predictable behaviour, and boring reliability. When you run apt install on a Debian server, you are not thinking about filesystem philosophy. You are thinking: “will this still work in five years?” ext4’s answer is usually yes.

I would not choose it for a NAS; ZFS wins there. I would not choose it for a laptop where tight OS integration matters; APFS wins there. But for a Linux server that just needs to serve files reliably, ext4 is still the safe bet.

Nobody ever got fired for choosing ext4.

APFS

No comparison of modern filesystems would be complete without APFS — the Apple File System.

The reason I dragged all the others onto the stage first is simple: I wanted a map of the landscape before focusing on Apple’s answer to it. For this blog, what matters is not just how the wider IT world solves storage problems, but how Apple chooses to solve them — and, more importantly, how those choices shape the security model of the platform.

That is why this long detour was necessary. To understand APFS properly, one must first understand what came before it, what problems other filesystems tried to solve, and what tradeoffs they embraced. Only then does it become possible to appreciate how deeply Apple built parts of its modern system architecture and defensive model around APFS.

Broadly speaking, traditional filesystems tend to live inside a relatively rigid storage layout. You start with a disk, carve it into partitions, and then create a filesystem inside each partition. Each partition has a fixed size unless you explicitly resize it, and each filesystem tends to consume the space assigned to it. This model works, but it is static, awkward to resize, and not especially elegant once multiple operating systems, recovery partitions, or encrypted containers enter the picture.

What the operating system actually mounts and uses are volumes or filesystems exposed through that structure. Those volumes are logically separate, and that separation is usually enforced by partition boundaries or by some additional abstraction layered on top.

APFS takes a very different path.

The Container Model

Instead of carving a disk into rigid, fixed-size partitions, APFS introduces the idea of a container. The closest rough analogy is a storage pool: not unlike a ZFS zpool, but designed for Apple’s world of single-disk systems — laptops, desktops, phones, tablets — rather than multi-disk servers.

A physical disk or SSD can hold one or more APFS containers. Inside each container live one or more volumes. These are not traditional fixed-size partitions. They share the available space dynamically from the container’s common pool.

Example: a 500 GB SSD might contain a single APFS container with three volumes:

System (the macOS read-only system volume)
Data (user data, writable)
Preboot (boot support files)

All three volumes draw from the same 500 GB pool. If the System volume needs 15 GB and the Data volume needs 300 GB, that is what they take — without pre-allocation, without rigid boundaries, and without manual resizing. Free space is shared across the container.

The importance of this approach is obvious if we think back to the old partition-resize mess: ext4, NTFS, moving boundaries around, hoping nothing went wrong, and sometimes losing data in the process. APFS removes that entire class of stupidity. You do not resize volumes in the old sense. They simply consume space from the container until that shared pool is exhausted.

This is a familiar idea in spirit: ZFS arrived at it in one direction, Apple in another. But APFS applies it with a very specific goal in mind — making modern storage layouts more flexible, less awkward to manage, and better suited to consumer devices.

Copy-on-Write (CoW)

Like ZFS, APFS is a copy-on-write filesystem. That means it never overwrites old data in place. When something changes, APFS writes the new version to fresh blocks, updates the relevant pointers, and only later frees the old blocks.

This approach changes the entire failure model. If the system crashes halfway through a write, the old data is still there. The new data may be incomplete, but the filesystem never ends up in that ugly half-updated limbo that older in-place filesystems have to clean up afterwards.

It also means that snapshots are almost trivial. Since the old blocks remain valid until they are explicitly released, taking a snapshot is basically a matter of freezing the current pointer state. No wholesale copying, no long wait, no drama.

The same logic makes clones cheap. If you duplicate a file or directory, APFS does not immediately duplicate the data blocks. It duplicates the references. The blocks remain shared until one side changes, and only then does CoW step in and split the data.

Compared to ext4 or NTFS, this is a different world. Those filesystems overwrite in place, so snapshots require extra machinery such as LVM or VSS, and cloning means physically copying data. APFS gets both almost for free because CoW is part of the design, not an add-on.

Snapshots and Clones

In APFS, snapshots are read-only views of the filesystem at a specific point in time. Apple uses them extensively. Time Machine, for example, no longer has to rely on the old HFS+ hard-link gymnastics; APFS gives it native snapshot support.

Clones are equally practical. Duplicate a large file and the operation is nearly instantaneous, because APFS is not copying ten gigabytes block by block at that moment. It is just reusing what already exists. Only the modified blocks become new writes later on.

This turns out to be extremely useful for system updates. macOS can clone the system state, apply an update to that cloned state, verify that everything is coherent, and then switch boot targets atomically. If something goes wrong, the old state is still there.

Encryption

One of the biggest differences between APFS and older filesystems is that encryption was not bolted on later. It was part of the design from the start.

APFS supports per-volume encryption, which means different volumes inside the same container can be protected independently. On modern Apple systems, key handling is tied to hardware security components such as the Secure Enclave, whether that lives in a T2-equipped Intel Mac or in Apple Silicon.

Apple supports different encryption setups, from unencrypted volumes to single-key configurations and more granular schemes with per-file keys wrapped by higher-level volume keys, as used by FileVault.

This is a very different story from ext4 or NTFS. ext4 gained fscrypt years after ext4 already existed, and even then the model remained directory-tree-based rather than volume-wide. NTFS had EFS, which always felt awkward and fragile, and in practice BitLocker became the real answer. With APFS, encryption is not the weird optional feature lurking at the edge of the design. It is native, mature, and tightly coupled with the rest of Apple’s platform security.

Space Efficiency

APFS is also much smarter than old-school partition thinking.

Volumes inside the same container share free space dynamically, so you do not have to pre-allocate rigid sizes and then regret them later. Space goes where it is needed.

It also supports sparse files, where unallocated ranges do not consume physical storage, and it has some support for compression in Apple-specific contexts. This is not ZFS-style transparent filesystem-wide compression, but it is still part of how Apple squeezes efficiency out of storage for selected content and system resources.

Crash Consistency

Because APFS is built around CoW and atomic pointer updates, it does not need journaling in the old ext4/NTFS sense.

If a crash happens in the middle of a write, the old version of the data is still intact. The new version may be incomplete, but until the pointers are updated, the filesystem continues to reference the valid state. That is why APFS can usually mount immediately after a crash without the ritual of journal replay or the looming fear of a long fsck.

This is one of the cleanest consequences of the design. ext4 and NTFS need journals because they overwrite in place. FFS with soft updates keeps consistency through ordering rules, but may still need background cleanup. APFS takes a different route: no journal, no replay, no leaked-space cleanup dance. The consistent state is already there.

What APFS Learned

This is where all the previous filesystems become useful as background rather than as museum pieces.

From BFS, APFS seems to inherit a broad philosophical lesson: the filesystem is not just plumbing. It is part of the identity of the operating system. APFS does not expose metadata queries in the BeOS sense, but it absolutely behaves like a core platform component rather than a silent storage backend.

From ZFS, the inheritance is more concrete: CoW, snapshots, space sharing, and the idea that storage layout should be fluid rather than trapped inside rigid partition boundaries. But Apple adapted those ideas to a very different target. ZFS was built with servers and large storage systems in mind. APFS was built for laptops, phones, tablets, and tightly integrated consumer devices.

From FFS, APFS inherits a more general discipline: reliability matters, and a filesystem should solve real problems without degenerating into a monster. Apple did not copy BSD’s solutions directly, but the same taste for pragmatic engineering is visible.

And from ext4 and NTFS, APFS mostly learned what to avoid: in-place overwrites, bolted-on encryption, external snapshot machinery, and the general feeling of dragging decades of compatibility baggage into a world that no longer matches the assumptions of spinning disks and static layouts.

Philosophy

Modern storage for modern devices: flash-optimised, encrypted by default, copy-on-write native, and designed as part of the OS security model.

Or, more bluntly:

What happens when you design a filesystem for 2017 rather than 1997, and assume SSDs, Secure Enclaves, and platform hardening are simply part of the deal.

Operational Assumptions

APFS is designed for Apple devices: Macs, iPhones, iPads, Apple Watches.

It assumes flash storage first. That does not mean it cannot exist on spinning disks, but its design clearly belongs to the SSD era: allocation strategy, cloning behaviour, snapshots, and general expectations all fit modern solid-state storage far better than old mechanical media.

It also assumes the Apple ecosystem around it: Secure Enclave-backed key handling, tight kernel integration, SIP, Sealed System Volumes, and the rest of the platform security stack.

And, of course, it assumes you are living in Apple-land. APFS is not a portable filesystem in the cross-platform sense. Outside macOS and iOS-family systems, support is limited and usually partial.

Weaknesses

APFS is not magic.

It is closed-source, which means that deep understanding often depends on reverse engineering, experimentation, and reading between Apple’s lines. But we’re not OSS crusaders, so we can deal with this.

It does not self-heal the way ZFS can when redundancy and checksums are combined. If a block goes bad, APFS can detect problems in some contexts, but it will not magically reconstruct damaged data for you. Backups still matter.

It is also a young filesystem compared to old warhorses such as FFS, ext4, or ZFS. It shipped in 2017. That is enough time to be real, but not enough time to carry the same historical weight as filesystems that have been beaten up in production for decades.

And finally, it is Apple-only in any practical sense. That is not a technical flaw so much as a strategic choice, but it still matters.

Overall Commentary

APFS is Apple’s answer to a simple question: what would a filesystem look like if you designed it for the hardware and threat model of the modern Apple ecosystem rather than for the compromises of the 1990s?

It assumes flash storage instead of spinning rust. It assumes encryption is normal, not exotic. It assumes snapshots and clones should be native features, not awkward external tricks. And it assumes the filesystem is part of system hardening, not just a place where bytes happen to live.

That is why APFS feels different. It does not just store files competently. It participates in how Apple secures the platform.

Is it perfect? Obviously not. It is closed, young, Apple-specific, and less transparent than many of its predecessors. But it is also purpose-built for what Apple actually needed: a filesystem that works hand in glove with hardware-backed key management, operating system hardening, atomic updates, and modern device workflows.

In Part 2, we will look at the consequence of that choice: APFS is not just a storage layer. It is one of the building blocks of macOS hardening, through mechanisms such as Sealed System Volumes, firmlinks, and the broader logic of system integrity.

BFS made the filesystem a user experience layer.
ZFS made it a data integrity layer.
APFS makes it a security boundary.

The tables that Google loves sooooo much when indexing your website

Overall comparison

Feature	ZFS	APFS	NTFS	FFS/FFS2	ext4	BFS
Copy-on-Write	Yes	Yes	No	No	No	No
Snapshots (native)	Yes	Yes	No	Bolt-on	No	No
Encryption (native)	Later	Yes	EFS	No	fscrypt	No
Checksums (data)	Yes	Metadata	No	No	No	No
Self-healing	Yes	No	No	No	No	No
ACLs	POSIX+	macOS	Windows	UFS2	Linux	Basic
Portability	BSD/Linux	macOS	Partial	BSD	Partial	Haiku
Use case	NAS/Server	Apple devices	Windows	BSD servers	Linux default	Multimedia

Conservatively estimated failure rate (my bullshit math)

Filesystem	Resize Operation	Estimated Failure Rate (Data Loss)
ext4	Grow (mounted)	< 1% (well-supported, journaled)
ext4	Shrink (unmounted)	5-8% (higher risk, metadata relocation)
NTFS	Grow (Windows DM)	2-5% (Microsoft tools are cautious)
NTFS	Shrink (3rd party)	10-15% (unmovable files, fragmentation issues)
FFS/UFS	Grow (`growfs`)	< 1% (mature, stable)
FFS/UFS	Shrink (manual)	30-40% (not officially supported)
FAT32	Any resize	15-20% (no journaling, brittle metadata)

Comparison ages

Filesystem	Release Year	Age (2026)
FFS	1984	42 years
NTFS	1993	33 years
BFS	1997	29 years (but BeOS died 2001)
ZFS	2005	21 years
ext4	2008	18 years
APFS	2017	9 years

Soft Updates vs. Journaling vs. CoW

Aspect	Soft Updates	Journaling	CoW (ZFS/APFS)
Write Overhead	1x (single write)	2x (journal + final)	1x (new blocks only)
Crash Consistency	Always consistent	Always consistent	Always consistent
Recovery Time	Instant mount + background fsck	Instant (journal replay)	Instant (no fsck needed)
Space Leaks	Possible (reclaimed later)	No	No
Snapshots	Bolt-on (FreeBSD)	External (LVM)	Native (free)
Complexity	Medium (dependency tracking)	Medium (journal management)	High (CoW + snapshots)

Conclusions

This post lays out the groundwork for the next one: Apple Defences: the organisation of the filesystem. I simply couldn’t give those concepts without an introduction of what led Apple to make some choices. That post will be very hands-on!

See you next week. Until then, stay paranoid, and copy-on-write your notes.

Want to understand how attackers bypass these protections? I’m building a macOS Reverse Engineering course that covers SIP internals, APFS forensics, and Mach-O binary analysis. Get in touch with me on Mastodon (my handle being @gbiondo on infosec.exchange) or simply drop me an email to work@bytearchitect.io.

Hardening macOS part 6: The Human Surface and Metadata Risks

2026-04-14T00:00:00+02:00

Context

You may know it - you may not know it, but IT people often have funny ways to refer to users. I remember lusers from the old, glorious days in which I was a sysadmin. But there are more, even sharper.

It’s peculiar noticing how when I shifted from pure system administration to security management this mindset held - and actually was even more pervasive, if possible.

Now as a “security expert”, I agree with the general mantra of the category, that appoints the human factor as the weaker link in the whole protection chain.

It’s true. There you go: the problem quite often sits between the chair and the keyboard.

But here’s the uncomfortable part: I’m the user too. And so are you.

We can harden the network layer, compartmentalise browsers, set up hardware tokens, encrypt everything twice — and then undo it all with a single careless click, a reused password, or a file shared with the wrong person.

This post isn’t about tools. It’s about behaviour. The habits, shortcuts, and blind spots that make all the technical work pointless. And unlike the previous posts in this series, there’s no configuration file to fix this. It’s just you, your choices, and the uncomfortable awareness that you’re the attack surface.

Let’s talk about what that actually means. But we’ll discuss this á la byte arquitechte, mes chers!

This is the post in this series that is more generic - the ideas you find here can be applied on all OS’s. Better than Java or Python, babs, for here we deal with the greatest vulnerability of any system.

The main exposure: the user

Yes, we’ll talk about our behaviours, what we do (and should not!), how we do things,… basically, all the boring considerations that all paranoids fear to say out loud in their heads.

I will try and look for my evolution as a (l)user.

Exercise:

Take a look at my Mastodon ProPic (infosec.exchange - handle: @gbiondo). Can you realise where that photo was taken? No? let me give you some suggestions:

google for “Black Sabbath Bridge”
cut the propic over one of the other images and do a Google Images search

Yay, the answer is Birmingham. Brum. Mordor. Call it whatever.

Now, this is deliberate - at least in my case. I have no ninja running after my head, but again - basic information that is easily obtained.

You may think that if you post a picture of your room it has less information. Really? I am looking at my webcam now, and I see in the background some of my books. If someone wanted to profile me, these would give a greater hint than the aforementioned propic.

Now, all this data has a collective name - we call it metadata, the name already suggests that this is data about data - and it makes sense, as we’ll shortly see.

Metadata: what your data says when you’re not talking

Metadata isn’t just in photos. It’s in everything you create - and quite often, also in everything that passes through your devices.

Open a Word document you wrote last month. Right-click, Properties, Details.

What do you see?

Author: your full name
Company: your employer (or worse — your client’s name if you’re a consultant)
Last modified: timestamp revealing your timezone
Total editing time: how long you actually worked on it
Software version: “Microsoft Word 16.x on macOS 14.3”

You just documented yourself. Identity, employer, timezone, work habits, OS version — all embedded in the file without you typing a single word of it.

Exercise

If you don’t have it already, install exiftool on your Mac:

brew install exiftool

Then take a picture with your phone and download it to your computer. Then run:

 exiftool ~/Desktop/Photo3.jpeg

and have fun! Just to give you the idea:

3gnever@0xREVENG3 ~ % exiftool ~/Desktop/Photo3.jpeg | grep -i GPS|wc -l 

      17

3gnever@0xREVENG3 ~ %

“Only” 17 pieces of information regarding where the picture has been taken!

Try it a little bit - exiftool works pretty much on all filetypes:

3gnever@0xREVENG3 ~ % exiftool /Users/3gnever/Desktop/topdown.pdf
ExifTool Version Number         : 13.55
File Name                       : topdown.pdf
Directory                       : /Users/3gnever/Desktop
File Size                       : 42 kB
File Modification Date/Time     : 2026:04:08 06:36:10+01:00
File Access Date/Time           : 2026:04:10 06:05:03+01:00
File Inode Change Date/Time     : 2026:04:08 06:36:10+01:00
File Permissions                : -rw-r--r--
File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
Linearized                      : No
Media Box                       : 0, 0, 595.2756, 841.8898
Page Count                      : 12
PDF Version                     : 1.4
Modify Date                     : 2026:04:08 05:36:10Z
Producer                        : macOS Version 26.4 (Build 25E246) Quartz PDFContext
Author                          : Gabriele Biondo
Title                           : Untitled
Creator                         : Seven7hSense
Create Date                     : 2026:04:08 05:36:10Z
3gnever@0xREVENG3 ~ % exiftool /Users/3gnever/Desktop/Dashboard\ _\ The\ Byte\ Architect-htmlonly.html 
ExifTool Version Number         : 13.55
File Name                       : Dashboard _ The Byte Architect-htmlonly.html
Directory                       : /Users/3gnever/Desktop
File Size                       : 35 kB
File Modification Date/Time     : 2026:04:09 08:01:50+01:00
File Access Date/Time           : 2026:04:09 08:01:51+01:00
File Inode Change Date/Time     : 2026:04:09 08:01:50+01:00
File Permissions                : -rw-r--r--
File Type                       : HTML
File Type Extension             : html
MIME Type                       : text/html
Title                           : Dashboard | The Byte Architect
Description                     : Hacking is my business… and business is good.
Robots                          : noindex, nofollow
Viewport                        : width=device-width, initial-scale=1.0

exiftool gives you an impressive quantity of data - for pictures, which is how I use it the most, it gives you:

GPS coordinates (latitude/longitude, accurate to meters)
Camera make and model
Timestamp
Lens focal length
Sometimes the camera serial number

There was a time when that sunset you posted on social media from your balcony would have leaked your home address to anyone with exiftool and thirty seconds of curiosity. These days, Meta strips EXIF data automatically before upload — but don’t assume every platform does the same.

This is metadata. Not the content — the context. And context is often more valuable than content.

You can encrypt an email end-to-end with PGP. Perfect forward secrecy, zero-knowledge architecture, the works. The metadata still reveals:

Who you emailed
When
How often
Roughly from where

That’s enough to map your entire social graph, infer relationships, track movements, and predict behaviour — without reading a single word of the actual message.

The NSA has been refreshingly honest about this: “We kill people based on metadata.”

You’re probably not on a targeted killing list. But the principle stands. Metadata tells stories you didn’t mean to share.

When it comes to PDF, I find qpdf a great tool. It removes metadata from PDFs:

brew install qpdf
qpdf --linearize --remove-unreferenced-resources input.pdf output.pdf

but nothing that exiftool doesn’t do - so up to you selecting your bane:

exiftool -all= document.pdf

If you prefer the GUI, look for ImageOptim on macOS.

For Word/LibreOffice documents: File → Properties → clear author, company, revision history. Export to PDF. Strip that PDF too. Metadata survives format conversions.

For photos you post publicly: disable location services in your camera app. Or use Scrambled Exif (Android) / Metapho (iOS) to strip EXIF on your phone before upload.

And remember: you can only strip metadata before you publish. Once it’s indexed, cached, scraped — it’s permanent. You can’t retract GPS coordinates from an image that’s already in Google’s database.

… and you believed it was “just a photo”.

Observe how the system and the applications give you enough rope to hang yourself: the metadata is just an artefact - a completely legit technology that can give you precious pieces of information on your data. Not being aware of it - or worse, not caring! - is a human behaviour. We’ll see this pattern quite often: a tool meant to give the users new possibilities end up being weaponizable against users.

Nowadays it looks like if you are not on social media, if you don’t like social media, and if your behaviour is a bit different from the usual social media user, then there’s something wrong with you.

Well, very Huxley-sh. But I am not the right guy to give judgements, here, for I find that environment toxic as hell. Plus, that is an over-structure. We cannot do much on perceptions.

First we should define what is meant by social media. In my current mindset, all applications that allow you to interact with unknown people are social media. So, all that TikTok/FaceBook/Instawhatever business - but not only. Also OnlyFans/Tinder/GiveMeYourContactToIntercourseApp and all that dismal.

The problem isn’t what you post. It’s the pattern.

You don’t need to dox yourself explicitly. Your behaviour does it for you.

You post at 8:00 AM, 1:00 PM, and 6:00 PM every day? Your timezone is visible. Cross-reference with daylight in your photos and someone can narrow your location to a region.

You post photos of your morning coffee, your office window view, your evening commute? You’ve just mapped your daily routine. A patient observer knows where you live, where you work, and what route you take between them.

You complain about your boss on a pseudonymous account but use the same sentence structure, vocabulary quirks, and posting schedule as your real account? Stylometry connects the dots. ~~It’s not paranoia if they’re actually correlating your datasets.~~

The problem isn’t individual posts. It’s the aggregate. One photo is harmless. A hundred photos become a timeline. One opinion is noise. Fifty opinions become a profile.

Books on your shelf, again

Remember the webcam example from earlier? The books visible in the background of a video call can profile you more accurately than your LinkedIn bio.

Someone screenshots your Zoom call. They zoom in on your bookshelf. They see:

The Phoenix Project — you work in DevOps or IT management
Thinking, Fast and Slow — you’re into behavioural economics or decision-making
Italian novels — you’re Italian or studied Italian literature
Security books, obviously — your field is clear
Perhaps, some controversial books (“Chaos Monkeys:…”? “Temporary Autonomous Zone”? Something more political? Anything religious? LGBT-related titles?)

They didn’t need your CV. Your environment told them.

Now apply this to Instagram stories, TikTok backgrounds, YouTube home office tours. Every frame is a data point.

What you actually do about it

Delay posting. Take the photo now. Post it three days later. Break the real-time correlation between your life and your feed.

Randomise timing. Use a scheduler if you want consistency without predictability. Don’t post at the exact moment something happens.

Strip location context. “Grabbed coffee this morning” is fine. “At the Starbucks on 5th and Main, same table as every Tuesday at 7:15 AM” is not.

Separate identities properly. If you run a pseudonymous account, treat it like a completely different person. Different tone. Different schedule. Different topics. Different everything. And for the love of encryption, do not cross-post the same content on both accounts within the same timeframe.

Assume correlation. If you post on Twitter, LinkedIn, and Instagram at roughly the same time with similar phrasing, anyone with basic OSINT skills can link those accounts in under five minutes. If you don’t want them linked, don’t make it trivial.

Background hygiene. Before you go live, stream, or post video — scan your background. Whiteboards with project names. Post-it notes with passwords (yes, I’ve seen this). Books that reveal more than you intended. Reflections in windows or screens showing your location. Get rid of those Your-Fave-Movement/Company/Band/Country flags. Get rid of everything that actually talks about you. Create an aseptic environment. Yes, it’s frustrating and alienating.

Or don’t. Blur your background. Use a virtual background. Or accept that you’re trading convenience for exposure and make peace with it.

As I mentioned before: I am not the most equilibrated voice when it comes to social media. I see this business as too pervasive and toxic. The thing is - I tried not to be too paranoid in this discussion. I could have discussed the LinkedIn arena - which is where the most delicate information pop up. I didn’t. On purpose. Left for you as an exercise. Another exercise for you: observe the patterns: where does human behaviour ends, and technicalities start? Any difference with the Metadata?

The Digital Twin you didn’t know you were building

Here’s the uncomfortable part.

All these breadcrumbs — posting times, books on your shelf, word choices, sentiment patterns, where you grab coffee, what you complain about — they’re not just data points for a hypothetical stalker.

They’re training data.

Algorithms don’t need to hack into your house. They just need enough signal to build a model of you. A digital twin that reacts to stimuli — ads, propaganda, nudges, recommendations — exactly like you would.

You post at 8 AM? The algorithm knows when you’re most receptive. You share articles about privacy? It knows what makes you angry, what makes you click. You engage more on Tuesdays? It schedules content for Tuesdays.

Your digital twin doesn’t need to be perfect. It just needs to be predictive enough to:

Sell you things you didn’t know you wanted
Show you news that confirms what you already believe
Surface content that keeps you scrolling
Influence how you vote, what you fear, who you trust

You’re not the customer. Your digital twin is the product. And you built it for free.

The irony? You thought you were just sharing your life. You were actually donating yourself to a prediction engine.

So here’s the real question: do you want that twin to exist? And if it already does — because let’s be honest, it probably does — how much are you still feeding it?

Your digital twin is the product. And you built it for free. And it’s a high-fidelity model because, at our core, we are creatures of habit. As far as I could see in my whole life: human beings love routines. Routines give you comfort. Credibility. Identity. You express yourself through your routines and habits. And this is wonderful, in a perfect world. In this world, these routine generate patterns. Patterns that can be exploited - and usually are exploited for profit. A not-so-mild form of manipulation, but it could be worse.

As we’re talking Social Media and web, why not mentioning…

“Sign in with Google.”

“Sign in with Facebook.”

“Sign in with GitHub.”

One click. No password to remember. No account creation form. Instant access.

Convenient as hell. And that’s the problem.

You just gave that service:

Your real name
Your email address
Potentially your profile picture
Access to your social graph (depending on permissions you didn’t read)
A link between that service and your Google/Facebook/GitHub account

And now, every service you’ve ever “signed in with Google” to is tied to that one account.

Single point of failure, distributed everywhere.

Your Google account gets compromised? Every service you signed into with Google is now compromised too. One breach, infinite exposure.

Worse: you’ve just told Google (or Facebook, or GitHub) everywhere you have an account. They know which services you use, when you signed up, how often you log in. They’re tracking your digital footprint across the entire web — and you gave them permission when you clicked that button.

The trust problem

Social login is built on a simple assumption: you trust the identity provider more than you trust yourself to manage passwords.

For most people, that’s probably true. Google’s security is likely better than Password123! reused across forty sites.

But here’s what you’re actually saying when you use social login:

“I trust Google/Facebook/GitHub to never get breached.”
“I trust them to never misuse my login data.”
“I trust them to never change their terms of service in ways I don’t like.”
“I trust that if my account gets locked, banned, or suspended, I won’t lose access to everything I’ve ever signed into with it.”

That last one? It happens. Google bans accounts. Facebook suspends people. GitHub locks accounts for ToS violations. And when that happens, you lose access to every service that relied on that login.

You don’t own your identity anymore. They do.

What you actually do about it

Don’t use social login. Just don’t.

Create an account the old-fashioned way. Use your password manager to generate a unique password. Enable 2FA on the service itself.

Yes, it’s a PitA. Yes, it takes an extra thirty seconds. That’s the point. That pain is a feature when the alternative is centralising your entire digital identity under one corporation’s control.

If you already did:

Go through your connected apps settings:

Google: myaccount.google.com/permissions
Facebook: Settings → Apps and Websites
GitHub: Settings → Applications → Authorized OAuth Apps

Revoke access to anything you don’t actively use. Then go to those services, create a proper account with a unique password, and break the link.

For developers:

Don’t offer only social login. Give users the option to create a real account. Some of us actually care about this. ~~And some of us remember when OAuth was supposed to be about delegation, not identity consolidation.~~

Enough dystopia for this post. Let’s get back to what you expect me to tell you. Like credentials hygiene, for starters.

Credentials hygiene

## Password reuse: the attack that never gets old

Everyone knows this one. Everyone. Literally.

Security trainings mention it. Articles warn about it. Your IT department sends passive-aggressive emails about it every quarter.

And yet here we are.

You use the same password for your email, your bank, and that random forum you signed up for in 2014 because you needed to download a PDF.

Why? Because remembering fifty unique passwords is impossible, and you’re not a computer.

Fair enough. The problem is: attackers know this too.

How it actually works

That forum you forgot about? It gets breached. The database leaks. Your email and password are now in a text file being sold for $3 on a Telegram channel.

The attackers don’t try to crack your password. You already gave it to them. They just try it everywhere else.

This is called credential stuffing. Automated bots take your leaked email and password, then try logging in to:

Gmail
Outlook
Your bank
Amazon
PayPal
Every major service they can think of

If you reused that password, one of those attempts succeeds.

The pattern? Email compromised to password reset links for everything else (bank account, cloud storage, social media), done.

This is not theoretical. Have I Been Pwned has logged over 12 billion breached credentials. The statistical probability that you’re not in there? Low.

The human problem

You know you shouldn’t reuse passwords. You do it anyway. Why?

Because the alternative — remembering Xk9$mP2@vQ7! for your bank, wL4#nR8&tY3% for your email, and bF6@hS1$pM9^ for Netflix — is cognitively impossible.

So you do what every human does: you create a system.

MyPassword2014! for old accounts.
MyPassword2018! for newer ones.
MyPassword2024! for this year.

Predictable. Weak. Worse than random because it feels secure.

Or you use BankPassword!, EmailPassword!, WorkPassword! — which is just reuse with extra steps.

The human brain is not built for this. Passwords were designed for a world where you had three accounts, not three hundred.

What you actually do about it

Use a password manager.

Strongbox. Bitwarden. 1Password. KeePassXC. I don’t care which one. Pick one. Install it. Use it.

Generate unique passwords for every service. Let the manager remember them. You only need to remember one master password — make it long, make it strong, and never reuse it anywhere else.

Audit your breaches.

Go to haveibeenpwned.com. Enter your email addresses. If you’re in a breach, change those passwords immediately. All of them. Even the ones from 2009 that you “don’t use anymore” — because you probably reused that password somewhere you do still use.

Enable 2FA everywhere.

Even if your password leaks, 2FA stops the login cold. Prefer hardware tokens (YubiKey) over SMS. SMS can be intercepted, SIM-swapped, social-engineered. A YubiKey sitting in your desk drawer cannot.

Rotate old credentials.

API keys you generated two years ago and forgot about. SSH keys you haven’t touched since your last laptop. App-specific passwords for services you don’t use anymore. Clean them up.

The honest truth

You will reuse passwords. Not maliciously — just because you’re tired, you’re busy, and “this site doesn’t matter anyway.”

That’s the site that gets breached. Always.

The goal isn’t perfection. The goal is: make credential stuffing unprofitable.

If your leaked password only works on one throwaway forum and nowhere else? The attackers move on. There are easier targets.

But if your leaked password unlocks your email, and your email unlocks everything else? You just made their job trivial.

SSH keys without passphrases: the unlocked front door

You generated an SSH key. Good.

You didn’t set a passphrase. Bad.

Now that key is sitting in ~/.ssh/id_rsa (or ~/.ssh/id_ed25519 if you’re modern), completely unencrypted. Anyone with access to your laptop — malware, physical theft, an unencrypted backup — can use it to access every server you’ve ever SSHed into.

An SSH key without a passphrase is a plaintext credential.

And unlike a password you can change with a few clicks, revoking SSH keys means logging into every server, editing ~/.ssh/authorized_keys, and hoping you didn’t miss one.

Why people skip passphrases

Because typing a passphrase every time you SSH is annoying.

You’re deploying code. You’re debugging production. You’re jumping between five servers in ten minutes. Stopping to type a passphrase each time breaks your flow.

So you generate the key without one. Or you generate it with one, get annoyed after three days, and regenerate it without.

I get it. Convenience wins. Always.

But here’s what you’re actually doing: you’re turning your SSH key into a password stored in plaintext on disk. The exact thing you’d never do with your email password, you’re doing with root access to your infrastructure.

What actually happens when it leaks

Let’s say your laptop gets stolen. Or you get hit with ransomware that exfiltrates ~/.ssh/ before encrypting your disk. Or you restore from an unencrypted Time Machine backup that someone finds.

The attacker now has:

Your private key (unencrypted)
Your ~/.ssh/config file (which lists all your servers)
Your ~/.ssh/known_hosts file (which confirms which servers you’ve accessed)

They don’t need to crack anything. They just:

ssh -i stolen_key user@your-production-server

And they’re in. Root access. No password prompt. No 2FA. Just in.

What you actually do about it

Set a passphrase when you generate the key

ssh-keygen -t ed25519 -C "your_email@example.com"

It will ask for a passphrase. Use one. Make it strong. Store it in your password manager if you need to.

Already have keys without passphrases?

You can add one retroactively:

ssh-keygen -p -f ~/.ssh/id_ed25519

It will prompt for the old passphrase (none) and the new one. Done.

Use `ssh-agent` to avoid typing it constantly

Once per session, unlock your key:

ssh-add ~/.ssh/id_ed25519

Enter the passphrase once. The agent remembers it for the session. You SSH freely after that.

On macOS, you can make it even smoother:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

This stores the passphrase in your macOS Keychain. You unlock it once (when you log in), and ssh-agent handles the rest.

Rotate old keys.

If you’ve been using the same SSH key for five years, generate a new one. Remove the old public key from your servers’ ~/.ssh/authorized_keys. Treat keys like passwords — they expire.

Separate keys for separate contexts

Work servers? ~/.ssh/work_ed25519.
Personal servers? ~/.ssh/personal_ed25519.
GitHub? ~/.ssh/github_ed25519.

If one key leaks, the blast radius is contained. Your ~/.ssh/config can handle the routing:

Host github.com
  IdentityFile ~/.ssh/github_ed25519

Host work-server
  IdentityFile ~/.ssh/work_ed25519

The honest truth

You’ll generate a key without a passphrase “just for testing.” That key will still be in ~/.ssh/ three years later, with access to servers you forgot existed.

Clean your SSH directory. Right now. Go look. You’ll find keys you don’t remember creating, for servers you don’t remember accessing.

Delete them. Revoke their public keys from the servers. Start fresh.

Because the alternative is: someone else finds them first.

The pattern you’ve probably noticed

Metadata. Social media patterns. Password reuse. SSH keys without passphrases. Social login.

None of these are technical failures. Your OS didn’t fail. Your browser didn’t fail. Your firewall is fine.

You failed. Or more accurately: human behaviour failed.

The tools work. The encryption works. The compartmentalisation works. But then you post a photo with GPS coordinates embedded. You reuse a password because it’s easier. You skip the SSH passphrase because typing it is annoying. You click “Sign in with Google” because it’s one less account to manage.

And all the hardening, all the configuration, all the layered defence — gone.

This is why security people are exhausted. It’s not the technology. Technology is solvable. Humans are not.

You can patch software. You can’t patch behaviour.

But here’s the thing: you can change it. Not overnight. Not perfectly. But incrementally.

Strip metadata before you share. Delay your posts. Use a password manager. Set passphrases on your SSH keys. Create proper accounts instead of social login.

One habit at a time. One decision at a time.

Because the alternative is: you’ll do all the technical work, set up all the defences, harden all the layers — and then leak your home address in a sunset photo’s EXIF data.

The human factor is the weakest link. But it’s also the only one you can actually control.

Conclusion

In the next post: VeraCrypt and plausible deniability, oversharing in the workplace, security theater, when paranoia is actually justified, and how I actually work day-to-day. The behaviours that make or break everything we’ve built so far.

Stay paranoid — but stay sane.

A kind request for you

I’m deciding what to write next. Which gap hurts you most — code signing internals, AppKit underdocumented patterns, or macOS threat detection? Hit me directly: work@bytearchitect.dev

Reverse with me - Qardio necromancy - pt 2

2026-03-30T00:00:00+02:00

Still I want to share with you my Reverse Engineering style. Although I originally planned to write some more “hardening macOS” stuff, lately I am quite tired and I want to do only what it feels good to. Really - need some time off. But that’s another thing.

So, still measuring how the gravity impacts on aesthetics - or in a more understandable fashion - the weight/scale problem.

If you are too lazy to read the previous post Reverse with me - Qardio necromancytoo bad! It’s all there! But let me summarize quickly what we understood:

Property	Value
Device name	`QardioBase`
Device UUID	`DDD101E2-5809-1322-6FE7-CAD62DC14121`
Bluetooth version	4.1
BDA/MAC Address	`5C:D6:1F:C4:1C:A3`
Proprietary Service UUID	`C8219E89-93E0-4169-A3DC-EA7959E866AF`
Communication	Bidirectional
Notify characteristics	`0x0019`, `0x001c`, `0x002d`, `0x0030`
Read characteristics	`0x000e`, `0x000c`, `0x0028`
Write characteristics	`0x002e`
Communication media	BlueTooth, IP Connection

Now, where were we? Right. We had the UUID, the characteristics, the MAC. We knew the device talked. We just didn’t know what it was saying.

The Frida Wall and the Change of Ways

The obvious next step was the iOS binary. QardioBase is still installed on an old iPhone — the last survivor of the app’s existence on this planet. So we reached for Frida.

frida -U -n Qardio

Failed to attach: unable to attach to the specified process

FairPlay. The app is signed, the iPhone is not jailbroken, and that’s the end of that conversation. Frida can attach to processes signed with your own developer certificate — not to App Store binaries on a non-jailbroken device. I could have jailbroken the phone, but hey, that’s too easy - it’d be like DoSsing someone. If you DoS someone you’re no hacker - you’re a kiddie. It’s a matter of class, innit?

So I changed approach.

Sniffing the Air: The GATT Sequence

The binary was locked. The device wasn’t.

Two routes:

what I discovered in iOS logs
NRF52840-DONGLE + BlackArch + Wireshark

But I am the changer of ways, therefore here you go: another shiny route! Use the dongle, starting from the elements I’ve seen in the first probe (iOS logs). Capture as many scale states as possible, and document them.

So, since this is going to be a long and painful exercise, but the real value is only understanding ONE operation, let’s focus on getting my weight, solely. All the other aspects and functionalities will be obtained in exactly the same way, and they’re left as an exercise for the reader! (sorry - I couldn’t help but writing this horrible sentence. If you’ve had some math, chances are you’ve seen that sentence that the teachers use to torture the students. After years of reading it, now it was my time to write it. I was officially excited!)

Back to our business - Weight. One operation, one goal.

Here’s what we’re looking for: the moment the scale transmits a measurement. From the iOS logs we already knew the cast: a proprietary service (C8219E89-93E0-4169-A3DC-EA7959E866AF), a handful of characteristics, bidirectional communication. The dongle gives us the same picture, but from the air — no iPhone required, no app required, just radio.

The sequence, as captured, goes like this:

The scale advertises. Continuously. It’s looking for someone to talk to.
A client connects and discovers the GATT services.
The client subscribes to notifications on the STATE characteristic (A78AF805...).
The scale emits STATE updates. When STATE hits 6, a measurement is ready.
The client reads the MEASUREMENT characteristic (B24F98BE...).
The scale responds with a JSON payload.

That’s it. That’s the entire protocol for reading weight. No authentication, no encryption, no handshake beyond standard GATT. Qardio built a scale that hands you your data if you simply ask politely.

Which I did.

Talk is cheap, show me the Swift code

I wrote a simple swift project - I am not sure I will transform this one into a fully fledged iOS app (that’s more a “No” than a “Yes”, but if you wanna do it, don’t hesitate to get in touch with me - I’ll gladly share this code and all the reversing artefacts with you).

Just the AppDelegate - then adding a few Entitlements, and here we go!

//
//  AppDelegate.swift
//  QardioBase
//
//  Created by Gabriele Biondo on 28/03/2026.
//

import Cocoa
import CoreBluetooth

let QARDIO_SERVICE = CBUUID(string: "C8219E89-93E0-4169-A3DC-EA7959E866AF")
let CHAR_STATE     = CBUUID(string: "A78AF805-8F3F-4E8F-A964-318B768BC38C")
let CHAR_ENG       = CBUUID(string: "9F3F4E1B-37D7-4F95-B374-CF585D808BEB")
let CHAR_MEAS      = CBUUID(string: "B24F98BE-9CD4-4F82-B935-01F18F104EDE")

@main
class AppDelegate: NSObject, NSApplicationDelegate, CBCentralManagerDelegate, CBPeripheralDelegate {

    var central: CBCentralManager!
    var peripheral: CBPeripheral?
    var engChar: CBCharacteristic?
    var measChar: CBCharacteristic?
    var window: NSWindow?

    func applicationDidFinishLaunching(_ notification: Notification) {
        central = CBCentralManager(delegate: self, queue: nil)
    }

    // MARK: - Central

    func centralManagerDidUpdateState(_ central: CBCentralManager) {
        guard central.state == .poweredOn else {
            print("BLE non disponibile: \(central.state.rawValue)")
            return
        }
        print("BLE pronto, scansione in corso...")
        central.scanForPeripherals(withServices: [QARDIO_SERVICE])
    }

    func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral,
                        advertisementData: [String: Any], rssi RSSI: NSNumber) {
        print("Trovato: \(peripheral.name ?? "unknown") \(peripheral.identifier)")
        self.peripheral = peripheral
        central.stopScan()
        central.connect(peripheral)
    }

    func centralManager(_ central: CBCentralManager, didConnect peripheral: CBPeripheral) {
        print("Connesso a \(peripheral.name ?? "device")")
        peripheral.delegate = self
        peripheral.discoverServices([QARDIO_SERVICE])
    }

    // MARK: - Peripheral

    func peripheral(_ peripheral: CBPeripheral, didDiscoverServices error: Error?) {
        guard let service = peripheral.services?.first else { return }
        print("Servizio trovato: \(service.uuid)")
        peripheral.discoverCharacteristics([CHAR_STATE, CHAR_ENG, CHAR_MEAS], for: service)
    }

    func peripheral(_ peripheral: CBPeripheral, didDiscoverCharacteristicsFor service: CBService, error: Error?) {
        for char in service.characteristics ?? [] {
            print("Caratteristica: \(char.uuid)")
            if char.uuid == CHAR_ENG  { engChar = char; peripheral.setNotifyValue(true, for: char) }
            if char.uuid == CHAR_STATE { peripheral.setNotifyValue(true, for: char) }
            if char.uuid == CHAR_MEAS { measChar = char }
        }
    }

    func peripheral(_ peripheral: CBPeripheral, didUpdateValueFor characteristic: CBCharacteristic, error: Error?) {
        guard let data = characteristic.value else { return }

        if characteristic.uuid == CHAR_STATE {
            let state = data[0]
            print("STATE: \(state)")
            if state == 1 {
                print("Configuration mode — abilito engineering...")
                enableConfig()
            }
            if state == 6 {
                print("Misura pronta — leggo...")
                readMeasurement()
            }
        }

        if characteristic.uuid == CHAR_ENG {
            print("ENG raw: \(data.map { String(format: "%02x", $0) }.joined(separator: " "))")
            if data.count >= 4 && data[2] == 9 {
                print("Config mode confermata")
                readMeasurement()
            }
        }

        if characteristic.uuid == CHAR_MEAS {
            if let json = String(data: data, encoding: .utf8) {
                print("MEASUREMENT: \(json)")
            }
        }
    }

    // MARK: - Commands

    func enableConfig() {
        guard let char = engChar, let p = peripheral else { return }
        let cmd: [UInt8] = [0x00, 0x00, 0x01, 0x01]
        p.writeValue(Data(cmd), for: char, type: .withResponse)
    }

    func readMeasurement() {
        guard let char = measChar, let p = peripheral else { return }
        p.readValue(for: char)
    }
}

Again: using a project is overkill - but it was kind of faster.

Finger crossed, I run this guy and I prepare to weight myself. I obtain this output:

BLE pronto, scansione in corso...
Trovato: QardioBase F9275DED-C0DC-56F0-D972-3D2FCB657C4B
Connesso a QardioBase
Servizio trovato: C8219E89-93E0-4169-A3DC-EA7959E866AF
Caratteristica: A78AF805-8F3F-4E8F-A964-318B768BC38C
Caratteristica: B24F98BE-9CD4-4F82-B935-01F18F104EDE
Caratteristica: 9F3F4E1B-37D7-4F95-B374-CF585D808BEB
ENG raw: 00 00 0e 10 08 00
ENG raw: 00 00
ENG raw: 00 00
ENG raw: 21 70 28 10
ENG raw: 1d 00 00 00
ENG raw: c9 71 38 44 44 fc
ENG raw: c5 01 00 01 01 00
ENG raw: 49 74 38 44 44 7c
ENG raw: 45 04 00 00 00 00
ENG raw: c9 76 7f 44 44 38
ENG raw: c5 06 00 00 00 00
ENG raw: 49 79 7c 08 04
ENG raw: 45 09 00 00 00
ENG raw: 49 7b 7d
ENG raw: 45 0b 00
ENG raw: 49 7c 38 54 54 18
ENG raw: 45 0c 00 00 00 00
ENG raw: c9 7e 7f
ENG raw: c5 0e 00
ENG raw: a1 71 38 44 44 fc
ENG raw: 9d 01 00 01 01 00
ENG raw: 21 74 3c 40 40 3c
ENG raw: 1d 04 00 00 00 00
ENG raw: a1 76 38 54 54 18
ENG raw: 9d 06 00 00 00 00
ENG raw: 21 79 48 54 24
ENG raw: 00 00
ENG raw: 00 00
ENG raw: 49 70 28 10
ENG raw: 45 00 00 00
ENG raw: c9 71 38 44 44 fc
ENG raw: c5 01 00 01 01 00
ENG raw: 49 74 38 44 44 7c
ENG raw: 45 04 00 00 00 00
ENG raw: c9 76 7f 44 44 38
ENG raw: c5 06 00 00 00 00
ENG raw: 49 79 7c 08 04
ENG raw: 45 09 00 00 00
ENG raw: 49 7b 7d
ENG raw: 45 0b 00
ENG raw: 49 7c 38 54 54 18
ENG raw: 45 0c 00 00 00 00
ENG raw: c9 7e 7f
ENG raw: c5 0e 00
ENG raw: a1 71 38 44 44 fc
ENG raw: 9d 01 00 01 01 00
ENG raw: 21 74 3c 40 40 3c
ENG raw: 1d 04 00 00 00 00
ENG raw: a1 76 38 54 54 18
ENG raw: 9d 06 00 00 00 00
ENG raw: 21 79 48 54 24
ENG raw: 1d 09 00 00 00
ENG raw: 21 7b 3e 44
ENG raw: 1d 0b 00 00
ENG raw: 00 80
ENG raw: 00 00 05 06
STATE: 6
Misura pronta — leggo...
MEASUREMENT: {"id":"114537690006011751348217","weight":"76.0","bmi":"19.3","z":"2031","fat":"57","tbw":"31","bmc":"3","mt":"9","sm":"17","algorithm":"0","user":"gabriel","userid":"blah"}
ENG raw: 00 00
ENG raw: 00 00
ENG raw: c9 72 01 81 61 19 07 01
ENG raw: c5 02 00 01 00 00 00 00
ENG raw: 49 76 70 8c 0a 09 90 60
ENG raw: 45 06 00 00 01 01 00 00
ENG raw: c9 79 00
ENG raw: c5 09 01
ENG raw: c9 7a 7c 82 01 01 82 7c
ENG raw: c5 0a 00 00 01 01 00 00
ENG raw: 15 76 7f 10 28 44
ENG raw: 11 06 00 00 00 00
ENG raw: 95 78 38 44 44 fc
ENG raw: 91 08 00 01 01 00
ENG raw: 00 80
ENG raw: 00 00
ENG raw: 00 00
ENG raw: 49 73 8f 09 09 09 91 60
ENG raw: 45 03 00 01 01 01 00 00
ENG raw: c9 76 01 81 61 19 07 01
ENG raw: c5 06 00 01 00 00 00 00
ENG raw: 49 7a 06 86 60 18 86 80
ENG raw: 45 0a 00 01 00 00 01 01
ENG raw: 95 75 7e 05
ENG raw: 91 05 00 00
ENG raw: 15 77 38 44 44 7c
ENG raw: 11 07 00 00 00 00
ENG raw: 95 79 3e 44
ENG raw: 91 09 00 00
ENG raw: 00 80
ENG raw: 00 00
ENG raw: 00 00
ENG raw: b5 71 38 44 44 fc
ENG raw: b1 01 00 01 01 00
ENG raw: 35 74 38 44 44 7c
ENG raw: 31 04 00 00 00 00
ENG raw: b5 76 7f 44 44 38
ENG raw: b1 06 00 00 00 00
ENG raw: 35 79 7c 08 04
ENG raw: 31 09 00 00 00
ENG raw: 35 7b 7d
ENG raw: 31 0b 00
ENG raw: 35 7c 38 54 54 18
ENG raw: 31 0c 00 00 00 00
ENG raw: b5 7e 7f
ENG raw: b1 0e 00
ENG raw: 00 80
ENG raw: 00 00
ENG raw: 00 00
ENG raw: c3 07 01
ENG raw: 43 08 01
ENG raw: bf 07 01
ENG raw: 3f 08 01
ENG raw: 00 80
ENG raw: 00 00 ec 00
ENG raw: 00 00
ENG raw: 00 00
ENG raw: c9 73 48 54 24
ENG raw: c5 03 00 00 00
ENG raw: c9 75 38 44 44 7c
ENG raw: c5 05 00 00 00 00
ENG raw: 49 78 1c 20 40 3c
ENG raw: 45 08 00 00 00 00
ENG raw: c9 7a 38 54 54 18
ENG raw: c5 0a 00 00 00 00
ENG raw: 21 73 38 54 54 18
ENG raw: 1d 03 00 00 00 00
ENG raw: a1 75 7c 08 04
ENG raw: 9d 05 00 00 00
ENG raw: a1 77 7c 08 04
ENG raw: 9d 07 00 00 00
ENG raw: a1 79 38 44 44 38
ENG raw: 9d 09 00 00 00 00
ENG raw: 21 7c 7c 08 04
ENG raw: 1d 0c 00 00 00
ENG raw: 00 80
ENG raw: 00 00 05 00
STATE: 0
ENG raw: 00 00 ec 00
ENG raw: 00 00
ENG raw: 00 00
ENG raw: 61 73 00 80 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80
ENG raw: 41 73 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
ENG raw: 21 73 0e 30 40 80 00 00 00 00 00 00 00 00 00 00 00 00 80 40
ENG raw: 01 73 00 00 00 00 01 01 02 02 02 02 02 02 02 02 01 01 00 00
ENG raw: 00 80
ENG raw: 00 00 05 0c
STATE: 12
ENG raw: 00 00 eb 00
BLE non disponibile: 4
BLE pronto, scansione in corso...
BLE non disponibile: 4
BLE pronto, scansione in corso...
...

Now, about those ENG raw packets.

The ENGINEERING characteristic is chatty. Very chatty. While you’re standing on the scale, it streams a continuous flow of binary data — sensor readings, state transitions, internal counters. It’s the scale thinking out loud.

The packets come in pairs — a data packet followed by an acknowledgement:

c9 71 38 44 44 fc   ← data
c5 01 00 01 01 00   ← ack

Byte 0 varies in a pattern that looks like a bitmask — 61, 41, 21, 01 in sequence, which in binary is:

A bit shifting down. Probably indicating which sensor segment is reporting. Byte 1 is consistently 73 (115 decimal) across an entire block — likely a session or frame identifier.

The state transitions are readable:

00 05 03   → STATE 3  — user stepping on
00 05 06   → STATE 6  — measurement ready
00 05 00   → STATE 0  — idle
00 05 0c   → STATE 12 — post-measurement

There’s also this, appearing just before STATE 6:

00 00 0b 00 a1 df ff

Bytes a1 df ff — interpreted as a signed 24-bit little-endian integer — give -8287. Not a weight in kilograms. Almost certainly a raw ADC reading from the load cell, relative to tare. The conversion to kilograms requires a calibration factor and offset that live in the firmware. I don’t have those, and frankly I don’t need them.

Because here’s the interesting design choice Qardio made: the ENGINEERING channel is effectively obscured by complexity — raw sensor data, binary protocol, no documentation. The MEASUREMENT channel, on the other hand, is a JSON string in plain text.

Interpreting the JSON (or: Why you shouldn’t wear socks)

They made the internals hard to read and the output trivial to read. Which means that for our purposes — resurrecting the scale — I can ignore everything above and focus entirely on what arrives on B24F98BE:

{
  "id": "114537690006011751348217",
  "weight": "76.0",
  "bmi": "19.3",
  "z": "2031",
  "fat": "57",
  "tbw": "31",
  "bmc": "3",
  "mt": "9",
  "sm": "17",
  "algorithm": "0",
  "user": "gabriel",
  "userid": "blah"
}

Dafuq?

I am not 76 kg - far from that. But it has a meaning, I didn’t really weigh myself in the right manner (I had my center of gravity outside the scale, to use the keyboard)

I am definitely not Jabba the Hut, and the other values are not mine - actually any doctor would avoid a patient with those figures…

Now, BMI is the body mass index. It’s a derived metric. Since it’s based on the weight, which is rubbish, this is rubbish as well (but you could infer my height. I don’t care, please do. You would be fascinated.)

z is the bioelectrical impedance (in Ohm). Long story short - the scale sends an imperceptible electric signal through the feet, measuring the impedance of the organic tissues. Water conducts, fat does not. Simple physics. Now 2031 Ω is total rubbish. Normally, an adult in good health, without bionic transplants nor alien eggs inside him, has a body impedance ranging between 400 and 600 Ω, depending on side conditions such as height, muscles, hydration. 2031 Ohm is 3 to 4 times the expected value. A bit of logic tells us that this is the classic scenario in which there is no contact - or contact is hindered somehow and…

… oh, ffs! The socks. I weighted myself with socks on.

This reverberates on all values:

tbw total body water, 31% - this is probably the result of being in a desert for weeks! A healthy adult has values that are easily twice this one.
bmc body mineral contents. 3 kg - well that can be plausible. This metric is less impacted by impedance.
mt - muscle tissue. 9 kg over 76 would mean that who jumped on the scale had been on a bed for months - it’d be a severe condition. Not plausible.
sm - skeletal muscle - same as above.

What happened there: high impedance implies that the signal doesn’t flow through. In turn the software interprets the data as “no water” therefore compensating with “lots of fat”. The rest? Clusterfuck.

I wanted to retroengineer a scale, I ended up doing physics - which is not exactly my passion.

Now, I have enough material to do a few more tests and draw my conclusions. In principle:

I need to restart this mac. PitA, but sometimes, on development phases, CoreBluetooth on Mac goes cuckoo.
I want to take a clean measurement.
If this last operation shall confirm my weight - which it should by the way, for the values I saw in the scale’s display are the same I reported in the JSON record - I would be ready to go to write the App. If I ever decide to do so

I am already very satisfied of how the analysis progressed.

Lesson learnt: The Engineering Labyrinth vs. The Open Backdoor

There is a profound, almost comical lesson buried in this exercise.

The ENGINEERING characteristic (9F3F4E1B...) is what I’d call the Debug Stream. Loud, chatty, binary pairs flying at you constantly. Byte masks shifting down — 61, 41, 21, 01. ACKs everywhere. It looks serious. It looks like someone knew what they were doing.

And inside that stream, you’re staring at raw physics — values like -8287, which are ADC integers relative to a tare offset. To make sense of them you’d need the calibration math from the firmware. Good luck with that.

So you’d be forgiven for thinking the system is impenetrable.

Then you look at the MEASUREMENT characteristic (B24F98BE...).

Plain UTF-8 JSON. {"weight": "76.0"}. No custom parser. No bit-banging. Just a string.

Qardio built a high-tech moat around the sensors and left the master key under the doormat — because it was easier for the app developers to consume a JSON object than to deal with raw hex blobs. The scale does all the heavy lifting at the edge, calculates everything, and then hands you the result on a silver platter. In plain text.

IoT security is rarely a solid wall. It’s usually a series of random obstacles. If you obsess over the engineering noise, you’ll think the system is impenetrable. Follow the data to where the app actually consumes it, and the emperor is naked.

The ENGINEERING channel is smoke and mirrors — intimidating, close to the silicon, deeply unreadable. A few handles away, the MEASUREMENT channel screams the truth in plain text.

Over-engineering on the inside. Poverty of design on the outside.

For a reverser, it’s the Promised Land.

Catcha next time - til then, stay paranoid. And fit, possibly…

Reverse with me - Qardio necromancy

2026-03-24T00:00:00+01:00

*Last week I didn’t publish, sorry. There’s a reason.

I am not the guy who uses the FartingCat (ChatGPT, in french, sounds like “chat, j’ai peté”, which means “cat, I farted”) to write posts on Linkedin, sorry. Why should one be willing to read something that the alleged author didn’t bother writing?

Plus, my audience is not Linkedin - and I don’t do rubbish to be regular. My bowels already are.

The problem

Like many IT people, I despise technology.

You come at my place? still you’d find analog stereo, real keys, dumb appliances, dumb neighbours that don’t mind their own business, and all the like. I have the place where I work (“Hangar 18”) which is something different, but my sancta sanctorum is strictly analog.

Well, not entirely. A few years ago I received this “QardioBase2 WiFi Smart Scale and Body Analyzer: monitor weight, BMI and body composition, easily store, track and share data. Free app for iOS, Android, Kindle. Works with Apple Health” (as Amazon describes it). Apple Health integration? Never bothered. But for sure, it had quite a good app.

Lately I wanted to install the app on a new iPhone 17, just to realise that the app in the App Store was not present anymore. After the usual swearing, I started digging a little bit on the internet to find that someone has programmed LibreArm - a free version for the QardioArm device, but it is a different thing. I fortunately have another device for blood pressure measurements.

The problem was still there then. So… so as mr. Taylor did some (great) necromancy on the blood pressure device, why not to do the same on the scale? From now onwards, I’ll call that post the Post.

The high-level plan

Reverse that zombie, bring it back to life. Write an app. Become rich and famous.

Ok, that’s the rubbish. High level plans and Executive summaries must be there, so let’s fill them in accordingly.

The real plan

Although I already know a lot about that scale, I want to treat this as a black box.

Open questions

Does it use wifi (and it asks you to connect to the internet, when initialising. Why?).
Does it use BLE?

working hypothesis: it uses both

Is there any form of encryption in the communications? how does it work?
how many internal states does the scale have? what internal states does the scale have?
is the communication bi-directional?
Assuming we can get a hold of the communication: what is the format of data?
1. endianness
2. data structures
3. measurement units
4. headers?
5. other weirdness?

And it’s pretty much it. Don’t be fooled by the relatively low number of questions - they are not so straightforward to answer.

Resources

we have an old copy of the App, so we could disassemble it straight away. Good luck, it’d take eons. But it’s always a good resource to have - especially in later stages.
the post. There’s also some code. Although it does not solve our problems, it can be of inspiration.

Understanding communications

It’s easier to start with BLE. At least, it’s a 1-1 communication. In the Hangar I have like a dozen of wifi networks and honestly I cannot remember into which one I enrolled the scale. It’ll be a nightmare of jumping and getting down from the scale. Taking notes will be my Cardio training.

So - old, good passive sniffing over-the-air. Packet logger should be sufficient. I know that sometimes it has its idiosyncrasies with the bluetooth chip - would that be the case, we’ll use the iPhone and log BLE traffic. We’ll cross that bridge.

Then wifi. While writing the previous paragraph I had the enlightenment: it suffices steer the internet traffic of the iPhone through an http proxy - hoping that these guys don’t use another exotic protocol. But I am kind of sure they don’t.

Certificate pinning is a thing — we’ll deal with it if we find it.

We’ll be able to draw our first set of conclusions, hopefully answering questions 1 and 2.

Then it’ll be the encryption carousel. I really hope there’s none - it would have been mentioned in the post - but we really need to understand this. Let’s be ready for it. My dream? Caesar’s cypher, with n=1! That’d address question 3 - from here onwards, the remaining part is just a matter of assigning semantics to raw data.

Preparing the playground

iOS

Well, I need to have detailed logs from the iPhone - hopefully that will be enough, worst case they’ll help a lot. Either way, I want verbose bluetooth logs - and to obtain these, I need a configuration profile. Without the latter, iOS would log only high level events. Good, but not good enough.

With this profile installed, bluetoothd will log pretty much everything: service discoveries, GATT characteristics, and the like.

So i point the iPhone browser to https://developer.apple.com/bug-reporting/profiles-and-logs/. Bluetooth section. It’s a trivial install.

Mac

Mac and iPhone will be connected via USB (USB C, in my case). Not a big deal.

Mac will not need any special program apart from the venerable Console.app.

Qardio scale

It suffices having the scale nearby. It’s about 1 m. away.

Reversing the connection

I first do some connection tests - all works fine (I am impressed. Lately working with Apple internals is what elicits my blasphemous tuscanian nature the most…). I happen to see the pieces of data I almost forgot, like

debug	16:09:01.586286+0000	bluetoothd	Device found: CBDevice FC3BB896-15E5-D2CB-C421-3B43EBFE669F, BDA 5C:D6:1F:EA:CB:2D, Nm 'QardioARM'

in fact, the “old” phone is paired also with a QardioARM device (blood pressure meter - the one mentioned in the post).

I also see that my airpods have three serial numbers:

Device found: CBDevice F77B65FB-982E-8692-A128-40ADBAB4F526, BDA 30:D8:75:20:18:09, Nm 'Gabriel's AirPods Pro', SN 'REDACTED1', SN Left'REDACTED2', SN Right 'REDACTED3'

one per each speaker, and the last one for the case. Apple tracks everything. Also ears.

Then I also saw com.apple.icloud.searchpartyd passing by. This is supposedly the “Find my” process. Apple knows when I find my weight :)

com.apple.internal.carkitd - CarPlay. My car wants to know my weight…

Well, apart all these stupid jokes, it seems that everything works fine and therefore, we can begin the real thing.

The test

The test plan is trivial. It will be sufficient to:

select the right device in Console.app
launch the Qardio app on the iPhone
wait a bit - there could be precious handshaking information passing through
step on the scale
waiting for it to measure my weight
step off
keeping the app alive whilst waiting for the app to save data somewhere (we’ll see where afterwards) and feeling guilty for the weight - that’s always a good thing to do.
wait for some more time - there could be further delayed interactions.
quitting the app on the iphone
stopping the capture.

In principle, one could do this also from the terminal, but this time i went for Console. Truth is, Console.app is faster to set up for a first pass.

We need to accept the fact that this first run can only be very approximate.

At a first glance, I see three processes appearing during the measurement: bluetoothd, wifid, and Qardio. I start suspecting that my working hypothesis is true, but proving this requires more sound analyses.

Fortunately, Console supports textual copy-paste. And grep is our friend.

First, I start with bluetoothd.

Bluetooth

As I said - grep is my friend, therefore I create a file with only bluetoothd events:

3gnever@0xREVENG3 Desktop % ls -alh 2nd\ Qardio.txt
-rw-r--r--  1 3gnever  staff    11M 22 Mar 16:31 2nd Qardio.txt
3gnever@0xREVENG3 Desktop % grep "bluetoothd" "2nd Qardio.txt" > bluetoothd-from-qardio.txt
3gnever@0xREVENG3 Desktop % ls -alh bluetoothd-from-qardio.txt                   
-rw-r--r--  1 3gnever  staff   106K 22 Mar 17:24 bluetoothd-from-qardio.txt

Quite manageable. Navigating with a text editor this last file, I see some interesting facts, like:

peripheral’s name
peripheral’s MAC
its UUID
and the Bluetooth version.

One step at a time.

Device’s name

This reminds me of all those crappy movies ripped off from “The Exorcist” where the priest wants the name of the entity… however, let’s do it.

The first approach one can conceive is to start querying this database of logs, hoping to have the right enlightenment - and in fact, reversing has this trial-and-errors nature, after all.

But hey, here we are talking bluetooth, and the protocol has well defined phases, so let’s start with something that hopefully gives us quick results. The crucial phase in the whole bluetooth transaction is pairing - so why not…

3gnever@0xREVENG3 Desktop % grep -i pair bluetoothd-from-qardio.txt 

debug 16:26:35.983020+0000 bluetoothd Device found: CBDevice FC3BB896-15E5-D2CB-C421-3B43EBFE669F, BDA 5C:D6:1F:EA:CB:2D, Nm 'QardioARM', DsFl 0x800000 < Pairing >, DvF 0x2000 < BLEPaired >, CF 0x0 < >, unchanged
debug 16:26:36.023122+0000 bluetoothd Device found: CBDevice FC3BB896-15E5-D2CB-C421-3B43EBFE669F, BDA 5C:D6:1F:EA:CB:2D, Nm 'QardioARM', DsFl 0x800000 < Pairing >, DvF 0x2000 < BLEPaired >, CF 0x0 < >, unchanged
...
debug 16:27:23.591469+0000 bluetoothd Device found: CBDevice FC3BB896-15E5-D2CB-C421-3B43EBFE669F, BDA 5C:D6:1F:EA:CB:2D, Nm 'QardioARM', DsFl 0x800000 < Pairing >, DvF 0x2000 < BLEPaired >, CF 0x0 < >, unchanged

3gnever@0xREVENG3 Desktop % grep -i pair bluetoothd-from-qardio.txt|wc -l
      16

Too optimistic of me. Especially when you have two Qardio devices connected to the phone. We need a better way to get to the data we want. Perhaps looking for device could help:

3gnever@0xREVENG3 Desktop % grep -i device bluetoothd-from-qardio.txt|grep -vi QardioARM|wc -l

     218

Good news. We also know one thing about the scale: its name! It’s in its box, after all :) Therefore we can try also:

3gnever@0xREVENG3 Desktop % grep -i device bluetoothd-from-qardio.txt|grep -vi QardioARM|grep -i qardiobase |wc -l

      30

Let’s see if this was a good intuition.

3gnever@0xREVENG3 Desktop % grep -i device bluetoothd-from-qardio.txt|grep -vi QardioARM|grep -i qardiobase

debug 16:26:35.833276+0000 bluetoothd Found device "DDD101E2-5809-1322-6FE7-CAD62DC14121 Public 5C:D6:1F:C4:1C:A3 RSSI:-82 with data:"QardioBase", RSSI: 0 dB (non-saturated), Tx: -2 dB, Service UUIDs: C8219E89-93E0-4169-A3DC-EA7959E866AF, connectable, sourceCore: MainCore, IsELNAOn: 0, IsPassup: 0, IsFromSCCompensation0, IsCoexDenied0,  Setting name to QardioBase

info 16:26:35.833937+0000 bluetoothd Device found new: CBDevice DDD101E2-5809-1322-6FE7-CAD62DC14121, BDA 5C:D6:1F:C4:1C:A3, Nm 'QardioBase', DvF 0x40000000000 < Connectable >, RSSI -82, Ch 39, AdTsMC <1293840675>, CF 0x80204000000 < New RSSI Attributes >

default 16:26:35.835410+0000 bluetoothd Device connecting - {cbuuid: DDD101E2-5809-1322-6FE7-CAD62DC14121, devicename: QardioBase, result: 0, adv-addr: 5C:D6:1F:C4:1C:A3-Public, resolved-addr: }

...

default 16:26:38.112385+0000 bluetoothd The device "DDD101E2-5809-1322-6FE7-CAD62DC14121" is named "QardioBase"

...

default 16:27:15.772599+0000 bluetoothd Device disconnected - {cbuuid: DDD101E2-5809-1322-6FE7-CAD62DC14121, devicename: QardioBase, lmHandle: 0x55, adv-addr: 5C:D6:1F:C4:1C:A3-Public, resolved-addr: , result: 313}

debug 16:27:15.779532+0000 bluetoothd Device found: CBDevice DDD101E2-5809-1322-6FE7-CAD62DC14121, BDA 5C:D6:1F:C4:1C:A3, Nm 'QardioBase', DvF 0x40000200000 < Central Connectable >, CnS 0x400000 < BLE >, BTv 4.1, CF 0x800200000 < Connections DiscoveryFlags >, unchanged

....

debug 16:27:18.325975+0000 bluetoothd Device found: CBDevice DDD101E2-5809-1322-6FE7-CAD62DC14121, BDA 5C:D6:1F:C4:1C:A3, Nm 'QardioBase', DvF 0x40000200000 < Central Connectable >, CnS 0x400000 < BLE >, BTv 4.1, CF 0x800200000 < Connections DiscoveryFlags >, unchanged

default 16:27:18.326843+0000 bluetoothd Device lost: CBDevice DDD101E2-5809-1322-6FE7-CAD62DC14121, BDA 5C:D6:1F:C4:1C:A3, Nm 'QardioBase', DvF 0x40000200000 < Central Connectable >, CnS 0x400000 < BLE >, BTv 4.1, CF 0x800200000 < Connections DiscoveryFlags >

Quite dense:

these logs show that we have found the device name: ~~Pazuzu~~ QardioBase and its UUID: DDD101E2-5809-1322-6FE7-CAD62DC14121
As for the what happened - what I highlighted shows the following:
1. the device has been detected (16:26:35)
2. connection has been confirmed (16:26:38). iOS has confirmed the name via GAP.
3. connection has been lost (16:27:11) - actually I don’t remember what happened. It may be a program issue - should be investigated
4. 16:27:15: device connected again
5. 16:27:18: another disconnection… Blah!

So, long story short, we have:

Property	Value
Device name	`QardioBase`
Device UUID	`DDD101E2-5809-1322-6FE7-CAD62DC14121`

which is already a good beginning.

Taking a deeper look into the logs pasted above, we see the presence of the string BDA 5C:D6:1F:C4:1C:A3. BDA is how Apple delineates a Bluetooth Device Address - in other words, the MAC Address of the Bluetooth Device.

Furthermore, in this log entry we saw before:

debug 16:27:15.779532+0000 bluetoothd Device found: CBDevice DDD101E2-5809-1322-6FE7-CAD62DC14121, BDA 5C:D6:1F:C4:1C:A3, Nm 'QardioBase', DvF 0x40000200000 < Central Connectable >, CnS 0x400000 < BLE >, BTv 4.1, CF 0x800200000 < Connections DiscoveryFlags >, unchanged

there appears the string BTv 4.1 - this is a simple declaration from the device, that declares its Bluetooth version as 4.1. It’s not crucial for us, but it’s good to know.

Therefore, we can update the table as follows:

Property	Value
Device name	`QardioBase`
Device UUID	`DDD101E2-5809-1322-6FE7-CAD62DC14121`
Bluetooth version	4.1
BDA/MAC Address	`5C:D6:1F:C4:1C:A3`

I realise I mentioned GAP assuming that every reader knows what it is.

Unfortunately, reversing BlueTooth devices requires knowing the protocol, which is not the most frequent asset of pentesters/reversers (as for me: the only times I played with BT before was when I wanted to stop my former girlfriend playing like 20 times in a row the same song on a bluetooth loudspeaker. Then, I simply decided to pour some water onto the loudspeaker - easier).

For those who aren’t BlueTooth hardcore techies - GAP stands for Generic Access Profile. It’s a BLE profile defining how a devices announces itself/it’s discoverable to the other ones. In short, GAP defines the protocols for advertising (how the devices shares its name and its services), discovery (how a central finds the devices nearby), and connection establishment (basic procedures to connect). In our case, when we saw Setting name to QardioBase and The device is named "QardioBase", the name has been read via GAP, by the Generic Access Service (0x1800). This last service is standardised and mandatory on all BLE devices.

So some more theory required here. I promise I’ll keep it as short as possible.

If GAP is concerned with how to find and connect to devices, GATT focuses on the interaction with them. We have already seen use cases (e.g. - “blood pressure monitor”); services which is a bunch related data grouped together by UUID; characteristics, the atomic datum or command within a service - identified by UUID as well; and a descriptor which is metadata regarding characteristics.

From this perspective, a BLE device can be seen as a GATT DataBase which exposes services and characteristics that the central (in my case, the old iPhone) reads, writes, subscribes, and interacts with.

Let’s try this query and see what we get:

3gnever@0xREVENG3 Desktop % grep -i "service\|uuid" bluetoothd-from-qardio.txt | grep -i "DDD101E2" | grep -iv "qardioarm"

debug 16:26:35.833276+0000 bluetoothd Found device "DDD101E2-5809-1322-6FE7-CAD62DC14121 Public 5C:D6:1F:C4:1C:A3 RSSI:-82 with data:"QardioBase", RSSI: 0 dB (non-saturated), Tx: -2 dB, Service UUIDs: C8219E89-93E0-4169-A3DC-EA7959E866AF, connectable, sourceCore: MainCore, IsELNAOn: 0, IsPassup: 0, IsFromSCCompensation0, IsCoexDenied0,  Setting name to QardioBase

default 16:26:35.834150+0000 bluetoothd App connecting - {cbuuid: DDD101E2-5809-1322-6FE7-CAD62DC14121, bundle: com.getqardio.Qardio}

default 16:26:35.835410+0000 bluetoothd Device connecting - {cbuuid: DDD101E2-5809-1322-6FE7-CAD62DC14121, devicename: QardioBase, result: 0, adv-addr: 5C:D6:1F:C4:1C:A3-Public, resolved-addr: }

debug 16:26:35.880693+0000 bluetoothd Found device "DDD101E2-5809-1322-6FE7-CAD62DC14121 Public 5C:D6:1F:C4:1C:A3 RSSI:-83 with data:"QardioBase", RSSI: 0 dB (non-saturated), Tx: -2 dB, Service UUIDs: C8219E89-93E0-4169-A3DC-EA7959E866AF, connectable, sourceCore: MainCore, IsELNAOn: 0, IsPassup: 0, IsFromSCCompensation0, IsCoexDenied0,  Setting name to QardioBase

default 16:26:35.977813+0000 bluetoothd Device ready - {cbuuid: DDD101E2-5809-1322-6FE7-CAD62DC14121, devicename: QardioBase, lmHandle: 0x55, adv-addr: 5C:D6:1F:C4:1C:A3-Public, resolved-addr: , result: 0}

default 16:26:35.980199+0000 bluetoothd App ready - {cbuuid: DDD101E2-5809-1322-6FE7-CAD62DC14121, bundle: com.getqardio.Qardio, transport: le, result: 0}

default 16:27:15.772599+0000 bluetoothd Device disconnected - {cbuuid: DDD101E2-5809-1322-6FE7-CAD62DC14121, devicename: QardioBase, lmHandle: 0x55, adv-addr: 5C:D6:1F:C4:1C:A3-Public, resolved-addr: , result: 313}

default 16:27:15.775114+0000 bluetoothd App disconnected - {cbuuid: DDD101E2-5809-1322-6FE7-CAD62DC14121, bundle: com.getqardio.Qardio, reconnecting: N}

debug 16:27:15.814510+0000 bluetoothd Found device "DDD101E2-5809-1322-6FE7-CAD62DC14121 Public 5C:D6:1F:C4:1C:A3 RSSI:-88 with data:"QardioBase", RSSI: 0 dB (non-saturated), Tx: -2 dB, Service UUIDs: C8219E89-93E0-4169-A3DC-EA7959E866AF, connectable, sourceCore: MainCore, IsELNAOn: 0, IsPassup: 0, IsFromSCCompensation0, IsCoexDenied0,  Setting name to QardioBase

default 16:27:15.817358+0000 bluetoothd App connecting - {cbuuid: DDD101E2-5809-1322-6FE7-CAD62DC14121, bundle: com.getqardio.Qardio}

default 16:27:15.821300+0000 bluetoothd Device connecting - {cbuuid: DDD101E2-5809-1322-6FE7-CAD62DC14121, devicename: QardioBase, result: 0, adv-addr: 5C:D6:1F:C4:1C:A3-Public, resolved-addr: }

debug 16:27:15.840575+0000 bluetoothd Found device "DDD101E2-5809-1322-6FE7-CAD62DC14121 Public 5C:D6:1F:C4:1C:A3 RSSI:-85 with data:"QardioBase", RSSI: 0 dB (non-saturated), Tx: -2 dB, Service UUIDs: C8219E89-93E0-4169-A3DC-EA7959E866AF, connectable, sourceCore: MainCore, IsELNAOn: 0, IsPassup: 0, IsFromSCCompensation0, IsCoexDenied0,  Setting name to QardioBase

default 16:27:15.967087+0000 bluetoothd Device ready - {cbuuid: DDD101E2-5809-1322-6FE7-CAD62DC14121, devicename: QardioBase, lmHandle: 0x59, adv-addr: 5C:D6:1F:C4:1C:A3-Public, resolved-addr: , result: 0}

default 16:27:15.970037+0000 bluetoothd App ready - {cbuuid: DDD101E2-5809-1322-6FE7-CAD62DC14121, bundle: com.getqardio.Qardio, transport: le, result: 0}

default 16:27:18.297794+0000 bluetoothd Device disconnected - {cbuuid: DDD101E2-5809-1322-6FE7-CAD62DC14121, devicename: QardioBase, lmHandle: 0x59, adv-addr: 5C:D6:1F:C4:1C:A3-Public, resolved-addr: , result: 307}

default 16:27:18.322684+0000 bluetoothd App disconnected - {cbuuid: DDD101E2-5809-1322-6FE7-CAD62DC14121, bundle: com.getqardio.Qardio, reconnecting: N}

This response already gives us the services part of GATT: C8219E89-93E0-4169-A3DC-EA7959E866AF. How can I tell that this UUID is the proprietary service UUID? Well, it’s 128 bits, and services standardised by the BT SIG use 16-bit UUIDs. Therefore, a long UUID is a proprietary service - generated by device’s manufacturers for their custom services.

Other services will emerge from the GATT service discovery — more on that shortly.

Another interesting query will be:

3gnever@0xREVENG3 Desktop % grep -i service bluetoothd-from-qardio.txt
...
default	16:26:35.980330+0000	bluetoothd	Received XPC message "CBMsgIdPeripheralDiscoverServices" from session "com.getqardio.Qardio-central-791-158"
debug	16:26:36.021058+0000	bluetoothd	Sending XPC message "CBMsgIdPeripheralServicesDiscovered" to session "com.getqardio.Qardio-central-791-158"
default	16:26:36.021406+0000	bluetoothd	Received XPC message "CBMsgIdServiceDiscoverCharacteristics" from session "com.getqardio.Qardio-central-791-158"
debug	16:26:36.022288+0000	bluetoothd	Sending XPC message "CBMsgIdServiceCharacteristicsDiscovered" to session "com.getqardio.Qardio-central-791-158"
default	16:26:36.021586+0000	bluetoothd	Received XPC message "CBMsgIdServiceDiscoverCharacteristics" from session "com.getqardio.Qardio-central-791-158"
debug	16:26:36.022939+0000	bluetoothd	Sending XPC message "CBMsgIdServiceCharacteristicsDiscovered" to session "com.getqardio.Qardio-central-791-158"
default	16:26:36.022435+0000	bluetoothd	Received XPC message "CBMsgIdServiceDiscoverCharacteristics" from session "com.getqardio.Qardio-central-791-158"
debug	16:26:36.027683+0000	bluetoothd	Sending XPC message "CBMsgIdServiceCharacteristicsDiscovered" to session "com.getqardio.Qardio-central-791-158"
...
3gnever@0xREVENG3 Desktop %

When the app interrogates the device for services, bluetoothd responds (ServicesDiscovered) and for each found service, the app sends requests to get the characteristics (DiscoverCharacteristics) - bluetoothd responds with CharacteristicsDiscovered. Three rounds of characteristics discovery imply three services.

The only visible UUID is the one we found before.

Time to dig into the characteristics. Let’s go with the most natural grep:

3gnever@0xREVENG3 Desktop % grep -i "characteristic" bluetoothd-from-qardio.txt
...
default	16:26:36.028928+0000	bluetoothd	Received XPC message "CBMsgIdCharacteristicNotifyValue" from session "com.getqardio.Qardio-central-791-158"
default	16:26:36.028996+0000	bluetoothd	Received XPC message "CBMsgIdCharacteristicNotifyValue" from session "com.getqardio.Qardio-central-791-158"
default	16:26:36.028996+0000	bluetoothd	Received XPC message "CBMsgIdCharacteristicNotifyValue" from session "com.getqardio.Qardio-central-791-158"
default	16:26:36.028996+0000	bluetoothd	Received XPC message "CBMsgIdCharacteristicNotifyValue" from session "com.getqardio.Qardio-central-791-158"
default	16:26:36.029194+0000	bluetoothd	Received XPC message "CBMsgIdCharacteristicReadValue" from session "com.getqardio.Qardio-central-791-158"
default	16:26:36.029215+0000	bluetoothd	Received XPC message "CBMsgIdCharacteristicReadValue" from session "com.getqardio.Qardio-central-791-158"
default	16:26:36.029230+0000	bluetoothd	Received XPC message "CBMsgIdCharacteristicWriteValue" from session "com.getqardio.Qardio-central-791-158"
...
3gnever@0xREVENG3 Desktop %

After the discovery phase, the app subscribes four characteristics for notifications (NotifyValue four times); reads two characteristics (ReadValue twice), and writes on one (WriteValue - a single instance). This addresses question 5, about the directions of the data flow (namely - it’s bidirectional).

The final step is obtaining the specific handles of the characteristics:

3gnever@0xREVENG3 Desktop % grep -i "subscribing\|reading value\|writing value" qardiobase-only.txt
default	16:26:36.028965+0000	bluetoothd	Subscribing to updates of characteristic handle 0x0019 on device "DDD101E2-5809-1322-6FE7-CAD62DC14121"
default	16:26:36.029011+0000	bluetoothd	Subscribing to updates of characteristic handle 0x001c on device "DDD101E2-5809-1322-6FE7-CAD62DC14121"
default	16:26:36.029028+0000	bluetoothd	Subscribing to updates of characteristic handle 0x002d on device "DDD101E2-5809-1322-6FE7-CAD62DC14121"
default	16:26:36.029169+0000	bluetoothd	Subscribing to updates of characteristic handle 0x0030 on device "DDD101E2-5809-1322-6FE7-CAD62DC14121"
default	16:26:36.029206+0000	bluetoothd	Reading value for characteristic value handle 0x000e, char handle 0x000d on device "DDD101E2-5809-1322-6FE7-CAD62DC14121"
default	16:26:36.029222+0000	bluetoothd	Reading value for characteristic value handle 0x000c, char handle 0x000b on device "DDD101E2-5809-1322-6FE7-CAD62DC14121"
default	16:26:36.029267+0000	bluetoothd	Writing value with response to characteristic handle 0x002e on device "DDD101E2-5809-1322-6FE7-CAD62DC14121"
default	16:26:38.832947+0000	bluetoothd	Writing value without response to characteristic handle 0x002e on device "DDD101E2-5809-1322-6FE7-CAD62DC14121"
...
default	16:26:54.916492+0000	bluetoothd	Reading value for characteristic value handle 0x0028, char handle 0x0027 on device "DDD101E2-5809-1322-6FE7-CAD62DC14121"
...
3gnever@0xREVENG3 Desktop %

Observe that 0x002e is written twice: the first time with response and then without response. Moreover, 0x0028 is read way later - almost 20 seconds after the connection.

Therefore, at the end of this phase, the table becomes:

Property	Value
Device name	`QardioBase`
Device UUID	`DDD101E2-5809-1322-6FE7-CAD62DC14121`
Bluetooth version	4.1
BDA/MAC Address	`5C:D6:1F:C4:1C:A3`
Proprietary Service UUID	`C8219E89-93E0-4169-A3DC-EA7959E866AF`
Communication	Bidirectional
Characteristics	NotifyValue x4, ReadValue x2, WriteValue x1
Notify characteristics	`0x0019`, `0x001c`, `0x002d`, `0x0030`
Read characteristics	`0x000e`, `0x000c`, `0x0028`
Write characteristics	`0x002e`

… and we’re done with BLE. Now, the wifid.

wifid

The first query - quite naive - is:

3gnever@0xREVENG3 Desktop % grep -i "qardio" "2nd Qardio.txt"| grep -i wifid      

debug 16:26:32.947741+0000 runningboardd Sending state 0xb054475d0 for app<com.getqardio.Qardio(CE6D7FBD-90F3-4114-9F4E-8D9080896142)> to [osservice<com.apple.wifid>:53]

default 16:26:32.949071+0000 wifid Received state update for 791 (app<com.getqardio.Qardio(CE6D7FBD-90F3-4114-9F4E-8D9080896142)>, running-active-Visible

info 16:26:32.949251+0000 wifid Update delivered for [app<com.getqardio.Qardio(CE6D7FBD-90F3-4114-9F4E-8D9080896142)>:791] with taskState 4

debug 16:26:35.837357+0000 runningboardd Sending state 0xb054459d0 for app<com.getqardio.Qardio(CE6D7FBD-90F3-4114-9F4E-8D9080896142)> to [osservice<com.apple.wifid>:53]

default 16:26:35.838378+0000 wifid Received state update for 791 (app<com.getqardio.Qardio(CE6D7FBD-90F3-4114-9F4E-8D9080896142)>, running-active-Visible

info 16:26:35.838505+0000 wifid Update delivered for [app<com.getqardio.Qardio(CE6D7FBD-90F3-4114-9F4E-8D9080896142)>:791] with taskState 4

default 16:26:50.441823+0000 wifid WiFiDeviceManagerCatsSetLowLatencyApp: CATSUpdate en0: fgApp:com.getqardio.Qardio b=0x0 rc=1

default 16:26:52.673213+0000 wifid WiFiDeviceManagerCatsSetLowLatencyApp: CATSUpdate en0: fgApp:com.getqardio.Qardio b=0x0 rc=1

debug 16:27:07.935585+0000 runningboardd Sending state 0xb05444ee0 for app<com.getqardio.Qardio(CE6D7FBD-90F3-4114-9F4E-8D9080896142)> to [osservice<com.apple.wifid>:53]

default 16:27:07.936119+0000 wifid Received state update for 791 (app<com.getqardio.Qardio(CE6D7FBD-90F3-4114-9F4E-8D9080896142)>, running-active-Visible

info 16:27:07.936348+0000 wifid Update delivered for [app<com.getqardio.Qardio(CE6D7FBD-90F3-4114-9F4E-8D9080896142)>:791] with taskState 4

default 16:27:10.247198+0000 wifid WiFiDeviceManagerCatsSetLowLatencyApp: CATSUpdate en0: fgApp:com.getqardio.Qardio b=0x0 rc=1

debug 16:27:10.905860+0000 runningboardd Sending state 0xb05447e90 for app<com.getqardio.Qardio(CE6D7FBD-90F3-4114-9F4E-8D9080896142)> to [osservice<com.apple.wifid>:53]

default 16:27:10.906356+0000 wifid Received state update for 791 (app<com.getqardio.Qardio(CE6D7FBD-90F3-4114-9F4E-8D9080896142)>, running-active-Visible

info 16:27:10.906620+0000 wifid Update delivered for [app<com.getqardio.Qardio(CE6D7FBD-90F3-4114-9F4E-8D9080896142)>:791] with taskState 4

default 16:27:11.840672+0000 wifid WiFiDeviceManagerCatsSetLowLatencyApp: CATSUpdate en0: fgApp:com.getqardio.Qardio b=0x0 rc=1

This per se confirms that the app has two lines of communication - BlueTooth and WiFi. Neat. wifid knows that Qardio is in foreground (running-active-Visible, taskState 4) and gives it priority on the network itself (CATSUpdate... LowLatencyApp), but there is no connection whatsoever shown here. A deeper analysis wouldn’t show anything special, at the wifid level - at least, not now - so we move to the Qardio entries.

Property	Value
Device name	`QardioBase`
Device UUID	`DDD101E2-5809-1322-6FE7-CAD62DC14121`
Bluetooth version	4.1
BDA/MAC Address	`5C:D6:1F:C4:1C:A3`
Proprietary Service UUID	`C8219E89-93E0-4169-A3DC-EA7959E866AF`
Communication	Bidirectional
Notify characteristics	`0x0019`, `0x001c`, `0x002d`, `0x0030`
Read characteristics	`0x000e`, `0x000c`, `0x0028`
Write characteristics	`0x002e`
Communication media	BlueTooth, IP Connection

Qardio

A deeper look into the Qardio entries tells the rest of the story:

3gnever@0xREVENG3 Desktop % grep -i "tcp_disconnect\|nw_connection" "2nd Qardio.txt" | grep -iv "necp" | head -20
...
info    16:26:26.538347+0000  Qardio  nw_connection_create_with_id [C70] create connection to Hostname#d6701f48:443
info    16:26:26.538652+0000  Qardio  nw_connection_endpoint_report... [C70 Hostname#d6701f48:443 waiting parent-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good)]
default 16:26:26.538738+0000  Qardio  nw_connection_report_state_with_handler_on_nw_queue [C70] reporting state preparing
info    16:26:26.600951+0000  Qardio  nw_protocol_tcp_disconnect [C70.1.1.1:3] input protocol initiated disconnect
default 16:26:26.601155+0000  Qardio  nw_connection_report_state_with_handler_on_nw_queue [C70] reporting state cancelled
info    16:26:26.601443+0000  Qardio  nw_connection_create_with_id [C71] create connection to Hostname#d6701f48:443
...
3gnever@0xREVENG3 Desktop %

The WiFi path is perfectly healthy — Path is satisfied, LQM: good, uses wifi. The app is reaching out to a backend over HTTPS (port 443), hostname redacted by iOS. But every single connection goes straight from preparing to cancelled, and the app immediately retries — C69, C70, C71, and so on, for the entire duration of the session.

The conclusion is straightforward: the Qardio backend is unreachable. The servers are gone. The company went bankrupt, and the lights went out. This also explains the save error we saw during the tests — the scale measured, the app tried to sync, and got nothing back.

For our purposes, this is actually fine. We don’t need the backend — we just need the scale.

Conclusions

Reversing rarely needs super-weapons. The whole exercise could have been done with a mint machine (no, no Linux Mint. Mint, as in fresh. Although I could have done this also with my Linux laptop, huh).

This phase - which I led as a mix between forensics and discovery activities - is quite boring. Was it inconclusive? Kind of. I hoped that all data flew unredacted between the scale and the phone - but that’s reasonably impossible. Legal reasons, largely prevent this kind of things. Me, wishful thinking…

The next step? well, I need that scale. Therefore I will reverse the app. What else?

Obviously, this kind of activities is time consuming. The mantra still holds - I don’t publish because I must, I publish because I have something to say. It will take some time before you see the second part of this post - but as I said: I need a scale, therefore I will reverse that app. With time, indeed.

I hope you enjoyed this, and that you got a glimpse into the modus operandi of a reverser.

Have fun, reverse your sockets and socks, and be paranoid!

Bypassing MFA with Reverse Proxies: Building a Rust-based Firefox Extension to Kill AitM Phishing

2026-03-09T00:00:00+01:00

A couple of weeks ago, I described the Adversary in the Middle (AitM) family of attacks on this post: Starkiller Phishing Kit: Why MFA Fails Against Real-Time Reverse Proxies.

Enticed by the structure of the attack itself, the first thing that came into my mind was: how can we protect a regular internet user? Someone who does not care about “threat agents” and “threat models”, but simply wants to use their machine to pay a parking ticket without giving the credentials of their bank to some weird guy three thousand kilometers away?

Here we go - I started my RustRover, and off I went coding.

So, no macOS hardening today. It’ll be back soon.

Introduction

I always found the idea of writing an extension for a browser a challenge, because:

I hate JavaScript. With a passion.
I tried several ones - very few have a real meaning.
In general, they enlarge attack surfaces.

Nevertheless, with the idea of thwarting an attack aimed at an user that is culturally unprepared against it, and potentially unprotected, the only logical place where the protection could happen is the browser.

Obtorto collo I started reading some documentation. I discovered that the world of browsers is quite heterogeneous and there is nothing such as standards.

Firefox

To avoid the dispersion of my (very little amount, nowadays) resources, I decided to focus only on one browser - the one I like the most: Firefox. The good news is that several other browsers I use (LibreWolf, Mullvad) are Firefox Based - so write once, run in many places. Good.

I was tempted to support also Chrome and Safari.

Firefox exposes more APIs than Chrome, including the access to webRequest. With blocking. Turns out that Chrome has decommissioned this feature in MV3. MV3 is also where Chrome has removed the support for webRequestBlocking which is - incidentally - what I plan to use to block requests. Finally, there’s the legend that Chrome developers have to fork over 5 bucks to Mountain View just to get started. I wasn’t in the mood to find out if it’s true.

As for Safari - Safari is the outsider. I like it - I already said it a few times, but Apple does not make developer’s life easy. Believe me - they just don’t. Safari extensions must be distributed within the App Store, within a macOS app wrapper. Signed, notarised, Apple reviewed. For a free tool, that’s overkill. Several limitations on the API seal the deal - some API I planned to use may not be there. So… So the answer for Apple Users must be something else (which I am writing, but that’s material for another discussion).

TBA Lore - what’s in a name: ElectricEye

If you strolled for some time on this blog, you know that I often use Heavy Metal, Maths, or paradox references. It’s just a matter of avoid christening something like my exceptional extension - which I find boring.

My first two programs are named after a Black Sabbath and a Megadeth song. Aradia’s workflow is modeled after Mercyful Fate’s “Come to the Sabbath” lyrics. My cat’s name is Sabbath and no, I don’t use that name in my passwords, save your time.

Long story short, this time was Judas Priest’s Electric Eye

I’m made of metal
My circuits gleam
I am perpetual
I keep the country clean

Hopefully this guy will keep “Zia Maria”’s transactions clean. And safe. While the attacker strives to be an invisible spy, EE is the eye that peers deeper—spotting the proxy before it can ever touch Zia Maria’s data.

Technical Analysis

The blueprint - how EE works

First, and foremost, how it does not work.

I am not a fan of blacklist. They’re inherently broken. If IT Security has a mantra, it is “Kill ‘em all, let God sort them out”, or better “Block ‘em all, allow only few well-known good ones”.

Blacklists are broken by design. While you strive to find all the domains in which I deploy my evil proxies, I spawn 5 more. 10 more. The only limit is the cost of buying them - but again: I saw domains available for $3…

Long story short - a blacklist would be late. Always.

There must be a better approach - and the better approach is always about structure. The Nature of Things never lies.

A web page works mainly at three levels: DNS, HTTP headers, DOM. There’s a fourth layer in the AitM attack: TLS. In each of these, the AitM leaves breadcrumbs that can be followed. Precious hints.

Several independent layers that must converge to a precise set of circumstances to confirm an AitM. Miss one — no problem. Miss all of them? That’s your attacker.

DNS - the URL

Here my analysis is quite simple:

High entropy: an algorithmically generated domain name such as xk4f9q2m.evil.com have high entropy. Surely, way higher than bancaintesa.it or vodafone.co.uk.
Punycode / homograph: аrаdia.zone vs. aradia.zone. Can you spot the difference? let’s look at the bytes:

String	`xxd`
`аrаdia.zone`	`00000000: d0b0 72d0 b064 6961 2e7a 6f6e 65 ..r..dia.zone`
`aradia.zone`	`00000000: 6172 6164 6961 2e7a 6f6e 65 aradia.zone`

Good luck spotting out that thing only with your eyes.

Typosquatting: a simpler variant of the homograph attack: apple.com vs. app1e.com.
Subdomain anomalies: stats.pure-evil.online - a subdomain that has nothing to do with the root domain.

HTTP Layer

I am a pentester. Or I used to be that before I undertook “the way of the exploiting fist” - but the mindset is framed in blood. As a pentester, you first look at the structure of the HTTP header. If you don’t you’re not a nice guy.

There’s a plethora of checks that one may wanna do to see “how secure” an HTTP transaction can be. Some apply, some don’t. The thing is - quite often also good people misconfigure their web servers, and I did not want to increase the level of noise.

I went for a few choices. Simple ones:

Missing CSP: A “Free-for-all” script injection. With no CSP, any browser will blindly trust whatever is loaded. A properly crafted CSP could prevent the browser from sending data to unauthorised domains, or loading external scripts required by the kit. If missing, the AitM proxy has a good time manipulating DOM and stealing cookies. Plus, no CSP (frame-ancestors) means that inserting an iframe is easy as stealing ZiaMaria’s cookies. Both Browser’s and cookies in the jar-oh!
Missing HSTS: HSTS (HTTP Strict Transport Security) is what protects from Downgrade Attacks (or SSL Stripping), and session hijacking. Zia Maria would end up sending her data over unencrypted media. No-no!
Proxy headers - such as X-Forwarded-For, Via, X-Real-IP. Proxy breadcrumbs. Fingerprints. Call ‘em whatever.

TLS Layer

TLS is where things get interesting.

An AitM proxy sits between you and the server. This means two separate TLS handshakes: one with the victim, one with the legitimate server. The proxy negotiates both — and it negotiates them with its own capabilities, not the server’s. This leaves traces.

The most reliable signal I implemented is certificate age. AitM kits are opportunistic by nature — domains are bought, Let’s Encrypt certificates are generated, the kit is deployed. Fast. The whole infrastructure can be up in hours. A certificate that is less than 72 hours old on a domain claiming to be your bank is… suspicious. Very.

Is a fresh certificate a definitive proof of an AitM? No. Legitimate services rotate certificates too: ChatGPT scored a borderline 0.45 in my tests for exactly this reason. But combined with other signals, it becomes a meaningful contribution to the overall risk score.

The other theoretical signals: CA anomalies, cipher suite mismatches, TLS version downgrade. These are on the roadmap. For now, certificate age does the heavy lifting.

DOM Layer

This is the one that seals the deal.

DNS, HTTP headers, TLS. All useful signals. But a well-configured AitM proxy can get most of them right. Strip the proxy headers, use a aged domain, forward the security headers. Sophisticated kits do exactly that.

The DOM, however, is harder to fake.

Evilginx, and most AitM kits for what matters, work by proxying the legitimate site in real time. The HTML comes from the real server, gets modified on the fly, and is served to the victim. The problem is that rewriting every single URL in the DOM is hard. Expensive. Error-prone. Most kits don’t bother, or better, don’t bother completely.

The result? The browser is on stats.pure-evil.online. But the DOM is full of references to aradia.zone. Links, form actions, canonical tags, og:url. The real domain bleeds through.

Electric Eye’s content script scans the DOM continuously — with a MutationObserver, throttled at 500ms to avoid killing performance. When the ratio of links pointing to a different domain crosses a threshold, DomainMismatch fires. Weight: 0.50. Confidence: proportional to the ratio.

On a clean site — Repubblica, Google, Apple — this signal never fires. On stats.pure-evil.online proxying aradia.zone — it fires immediately. Combined with the other signals, the score hits 1.00. Critical. Hold your horses!

Risk scoring

Aradia, EE, and Unveiler (yet to come, but you’ll hear this name quite soon) mechanism is quite easy: events rise signals. Signals are modelled into numbers. Numbers become risk ratios. Risk ratios become decision rationale.

I deliberately avoided to bluntly block suspicious connections. I just decided to have a popup telling you a risk ratio. And if you’re not colorblind nor dyscalculic (which I am, by the way. Dyscalculic, I mean), you can decide if proceeding on navigation or doing your banking differently.

The model is not complex. It is a simple multiplicative model with corrections, because additive models tend to amplify background noises. Easy Peasy.

If risk is usually modelled as likelihood × impact, here I decided to model risk factor as weight × confidence. For now, the model holds.

Let’s oxidate their gluteus maximus!

Rust.

No discussion. The engine had to be written in a serious language that compiles into WASM. I could do C++ but I tend to avoid it, lately. Traumatised by its string management, despite the improvements in the latest versions.

JavaScript was not a choice. Sure as death and taxes, it’d enlarge the attack surface. No-no.

Engine written in pure Rust. No frills, no weird unsafe stuff. Pure Rust. And it works fine.

There is some JavaScript, indeed. The glue I needed to pass data to WASM. That’s what JS is for. Someone said that “tongue is that sexual organ that some perverts use to talk”. Likewise, JS is that glueish language that some perverts use to program.

Demo-ish

I plan to do a video with this, unfortunately 1 minute of video requires 10 minutes of takes and this is a low-priority task for me.

I hope you can appreciate the efforts nevertheless.

On a “normal” website, EE works almost transparently. See the images below, for instance.

Has a meaning: there is no data here. Let’s see something more complex - my websites:

and:

These show that cobbler’s children are the worst shod. I am complaining about a CSP I don’t put in my websites. What a dork I am.

But these values are good. Take for instance also

Then, let’s be mean. I spun up a VPS and configured it like this:

ssh root@$VPS_IP
cd ~/evilginx2
./build/evilginx -p phishlets/

and from there:

config domain pure-evil.online
config ipv4 $VPS_IP
phishlets hostname aradia pure-evil.online
phishlets enable aradia
lures create aradia
lures

Now let’s assume that Zia Maria wants my SWAF (SwampWAF) and receives a phishy email steering her to a malicious domain. That’s what EE could do for her:

You can see a slight discrepancy between the values (the first one is lower). That’s the magic of DOM analysis: the higher the number of links in the page, the higher the chance that some of them are not rewritten. And - BANG! - I spot you out!

There is a grey area - I am still working on it. Take Amazon:

Here signals are/can be quite misleading:

High entropy: amazon.com has a very low entropy, but the guys spin up subdomains and dynamically generated URLs. A real nightmare.
CSP/HSTS missing: Cobbler’s children, again.
ProxyHeaderDetected - dominating factor. Blame mr. CloudFront.

As I said, this is something I am still working on. A neater model.

Current status

I submitted the first version to the Mozilla Add-ons store. I am totally unaware of Mozilla’s timelines — but in general, it takes a week or so for an extension to be approved. I don’t expect Mozilla to be any faster.

As soon as it’s out, I’ll post the link. In the meantime, if you want to play with it, write me at hello@aradia.zone and I’ll send you a copy directly. Spamming a hacker is not a very smart move in a world made of technology. Just saying — to wake up the hamster in your head.

Here the download link: https://addons.mozilla.org/en-US/firefox/addon/electric-eye/

Conclusion

Electric Eye is not a silver bullet. No tool is.

What it is, is a different approach. Instead of chasing domains and updating blacklists, it looks at behaviour. At structure. At the things that an AitM proxy cannot easily hide — because hiding them means breaking the attack itself.

The false positive rate is low. The true positive rate, against a real Evilginx deployment, is 1.00. That’s not a coincidence — that’s the DOM bleeding through.

There is work still to do. The CDN grey area needs a neater model. The TLS signals are partially roadmap. And a video demo is coming — eventually, when I find 10 consecutive minutes of patience.

But Zia Maria is already safer than she was last week. And that’s enough for now.

More is coming. Stay paranoid, have fun… and keep your horses held!

Hardening macOS 5: Secure Email Clients, Providers, and Encryption Tools

2026-03-02T00:00:00+01:00

Last week I didn’t release any post on hardening macOS — sorry about that. I thought my witchcraft with network security was over; reality shows I was wrong. This AitM stuff drains my time, and I’m not the guy who releases weak stuff.

If you’re curious: I’m about to release a browser extension for all major platforms — Chromium, Firefox, and Safari — to help protect users. Mid or end of March 2026.

_Apart from that: today we talk communications. For a Cy[b

ph]erpunk like myself, talking about communications is walking on eggshells. The risks are being too verbose and being too opinionated. If there’s anything like “talking politics at the pub” within the security scene, well — talking about communications is a great way to start a fight. And no, I don’t want to do politics._

So this will be a weird post. I’m telling you upfront.

Previous posts on this series

The postman always reads twice

Before we talk about tools, let’s establish something uncomfortable: email was never designed to be private. It was designed to be delivered. The privacy part was an afterthought — and it shows.

When you send an email, it hops between servers. Each hop is an opportunity. Your client sends it to your provider’s server. Your provider’s server talks to the recipient’s provider’s server. The recipient’s client picks it up. At each step, someone with access to those servers can read your message. Whether they do is a matter of policy, law, and opportunity — none of which you control.

This is not paranoia. This is how SMTP works. It has worked this way since 1982.

With that cheerful thought in mind, let’s talk about your options.

Email clients: the tool you actually touch

Your email client is the interface between you and your messages. It doesn’t determine who can read your email on the server side — that’s your provider’s job — but it determines how you interact with your mail, whether encryption is practical, and whether you’ll actually use it.

The main contenders on macOS:

Client	Platform	GPG support	Cost	Notes
Apple Mail	macOS/iOS	Plugin required (paid)	Free	Excellent UX, deep Apple integration
Canary Mail	macOS/iOS	Native, free	Free/Pro	Apple Mail-like experience, my choice
Thunderbird	Linux/macOS/Windows	Native	Free	Solid, cross-platform, telemetry uninspected
Outlook	macOS/Windows	Supported	Microsoft 365	Good on Windows, loses context on Mac

Apple Mail is the obvious choice for most Apple users. The experience is excellent, the integration with the rest of your devices is seamless, and it does everything you’d expect. The only limitation worth mentioning: GPG support requires a paid plugin. If you don’t need GPG, this isn’t a limitation at all — it’s probably the right choice for you.

Thunderbird I used it for years. It’s solid, open source, cross-platform, and handles GPG natively. I’ll be honest: I’ve never properly audited its telemetry, which is a gap I’m not proud of. But if you’re on Linux — which, if you’re running a pentest setup on Arch, you are — Thunderbird is your realistic option. Not because it’s perfect, but because it works and nothing else competes.

Outlook deserves a more nuanced take than it usually gets. On Windows, in a Microsoft-heavy environment, it’s genuinely good. It works. The GPG support exists, even if it was cumbersome for a while. On Mac, it’s a nice-looking application that makes less sense the more you think about it. The G-Suite and other cross-platform alternatives exist. The Outlook mobile apps on iOS and Android are mediocre. And if you’re honest with yourself, you probably end up using webmail anyway. Good, but you have to want it.

Canary Mail is my choice. It looks and feels like Apple Mail, supports encryption natively without extra cost, and works consistently across macOS and iOS. The reason I didn’t choose Apple Mail is simple: when I made my decision, I wanted GPG support without paying extra. Canary gave me that. It’s not a dramatic choice — it’s a pragmatic one.

A note on multi-platform setups: if you run macOS and Linux, as I do, you’ll end up with Canary on the Mac and Thunderbird on Linux. Not because one is better — because that’s what the ecosystem gives you.

Email providers: the contract you sign with your data

Your client is the tool. Your provider is the contract. You can have the most privacy-conscious client in existence, but if your provider reads your email on the server side, you’re decorating a glass room.

Google has built one of the most impressive productivity suites in existence. The engineering is genuine, the tools are excellent, and some of the third-party integrations built on top of G-Suite are genuinely clever. I have a Gmail account. Several, actually. Like most people.

The trade-off is equally genuine: Google knows everything about you. Everything. Your email, your calendar, your location, your searches, your documents. They are an American company, subject to the Patriot Act — which means a government request for your data doesn’t require your knowledge or consent. This isn’t conspiracy theory. It’s US law. Choose accordingly.

Microsoft makes excellent software. Office is a formidable suite. VSCode is one of the best editors available — and it’s free, which is almost suspicious. F# is a beautiful language. The list goes on.

As an email provider, however, my answer is no. Years ago, Microsoft accessed an employee’s mailbox before terminating them — a move that, regardless of scale, said something about the culture. Setting up a Microsoft 365 organisation is an exercise in patience that borders on self-harm. And the American jurisdiction problem applies here too, in full.

Apple tries harder than the other two on privacy, and the effort is visible. Hide My Email is a genuinely useful feature — the idea of generating disposable aliases to protect your real address is sound practice. The execution, however, has limits: five aliases only, and — the detail that stings — disabling an alias doesn’t stop mail from arriving on it. For serious compartmentalisation, five aliases isn’t enough. For casual use, it’s fine.

Proton is based in Switzerland. The Swiss jurisdiction is not subject to the Patriot Act, and Proton has fought legal battles to protect user data. Client-side encryption means that Proton, technically, cannot read your email — the decryption happens on your device. It has grown into a full ecosystem: mail, VPN, calendar, drive, password manager. The VPN, if you’re on a higher tier, is among the best available.

The downside: Proton will charge you for anything beyond the basics, and the tiers escalate quickly. It’s not free if you want to use it seriously. Dear Patriot Act — not today.

Tuta is German. Hannover, specifically — subject to GDPR and German privacy law, which goes further than most. Like Proton, it offers client-side encryption. Unlike Proton, it is uncompromising to the point of being brutal: lose your recovery key, lose everything. No reset. No support ticket that saves you. This is a feature, not a bug — but it requires that you know what you’re doing. If you’ve read this far in this series, you probably do.

Note to self: being so nice to everyone will bring me a slow, painful death. Note for the reader: As you may see, I tried to supply you with a factual and non-opinionated review of the main email providers out there. ~~Nothing new, but how can someone write anything new when trying to be nice to the world?~~

What I plan to do

When I find some time, I will spin up a VPS on 1984.hosting. Put a serious OpenBSD box. An even serious-er MTA. Send all logs to /dev/null. And forget about all this.

A note for my Italian readers

Italy has a thing called PEC — Posta Elettronica Certificata, or Certified Electronic Mail. It sounds serious. It has “certified” in the name. The government made it mandatory for professionals, businesses, and public administration. You pay for it annually. There are accredited providers. There are regulations. There are audits. There is an entire bureaucratic ecosystem built around it.

That is the theory. In practical terms, after years of Italian-ity, this is my reading: cousinocracy. In Italy, the cousin is a deity-like character. You write superb websites and want to be paid accordingly? Your customers will always have a cousin who does the same for half the price. You’re a great electrician? Well, your customer’s cousin is surely better than you. And when it comes to politics — sorry to say it bluntly, but blunt I am — politicians usually do favours for their cousins. Perhaps because they owe them a lot. Like their seat.

What does it actually do? It certifies that your email was delivered. That’s it. The content travels in plaintext. No encryption. No integrity protection. No confidentiality whatsoever. It’s a glorified read receipt — the digital equivalent of sending a letter via registered post, except the postman can read everything inside, photocopy it, and nobody considers this a problem.

Meanwhile, PGP has been freely available since 1991. It actually encrypts your content. It works internationally. It costs nothing. Phil Zimmermann almost went to prison for releasing it, because governments understood that real encryption was a threat to their ability to snoop. Italy looked at all of this, looked at decades of cryptographic progress, and decided: no thanks. We’ll build our own thing, make it mandatory by law, hand the market to a handful of accredited providers, and call it security.

The result is a system that protects nobody’s privacy, generates revenue for a cosy oligopoly of providers, and gives Italian professionals the warm feeling of compliance without any of the actual security. Brilliant, really. In the most depressing way possible.

If you ever needed a textbook example of security theater institutionalised by law, benvenuti in Italia.

For what it’s worth: find the cheapest provider. They all do the same nothing.

PGP: the standard nobody loves and everyone uses

PGP — Pretty Good Privacy — has been the de facto standard for email encryption since 1991. It’s not the most elegant solution. The key management is arcane, the web of trust is effectively dead, and the user experience hasn’t aged particularly well. But it works, it’s interoperable, and — crucially — it’s what your counterpart probably supports, if they support anything at all.

In practice, PGP gives you two tools: encryption and signing. Encryption hides the content of your message from anyone without the recipient’s private key. Signing proves that the message came from you and hasn’t been tampered with. They are different operations, and you don’t always need both.

A word on using them: resist the temptation to encrypt and sign everything by default. It sounds like the maximally secure approach, but in practice it means entering your passphrase on every message. Which means either a weak passphrase — because you’re entering it fifty times a day — or a saved passphrase somewhere that isn’t your password manager. Neither is what you want. Use encryption and signing when they matter. That’s what they’re for.

Canary Mail, for what it’s worth, handles this well — it asks you explicitly what you want to do with each message, on both macOS and iOS. That pain is a feature.

Are there better alternatives? Technically, yes.

Age is a modern encryption tool — simpler, cleaner, better algorithms. But it’s designed for files and data, not email. No equivalent ecosystem.

S/MIME is the enterprise alternative — certificate-based rather than web-of-trust-based, better integrated into corporate email clients. Requires a CA, costs money, and is more closed than PGP.

Signal Protocol is cryptographically superior for messaging — perfect forward secrecy, double ratchet algorithm. But it’s for chat, not email.

The honest answer: PGP is the standard not because it’s the best, but because it’s the one your counterpart might actually have. In encryption, as in so many things, interoperability beats theoretical perfection.

Chat: you don’t choose your app — your contacts do

I’ll be honest: I’m not a chat person. Chat is an invasion. It’s an abuse of your time, dressed up as convenience. If you DM me, don’t expect a prompt answer. Or a kind one. But I will answer.

With that established: the landscape is what it is.

Signal is the pragmatic choice. End-to-end encrypted by default, open source, audited, minimal metadata collection. The Signal Protocol is genuinely good cryptography. The usability is acceptable. Enough people use it to make it useful — which, in secure messaging, is the critical variable.

WhatsApp is end-to-end encrypted, technically. It also belongs to Meta, which has demonstrated, repeatedly and comprehensively, that your privacy is not the product they’re selling — you are. The encryption protects the content in transit. The metadata, the social graph, the usage patterns — those are a totally different matter.

Telegram has a reputation for privacy that significantly exceeds its actual privacy properties. Standard chats are not end-to-end encrypted — they’re encrypted in transit, stored on Telegram’s servers. Only “Secret Chats” are end-to-end encrypted, and most people never use them. The recent legal troubles of its founder add context that each reader can weigh for themselves.

SimpleX Chat is, technically, the best answer in this space. No user identifiers — no phone number, no username. Decentralised. You can run your own relay server. Metadata minimisation that takes the problem seriously. Audited and open source. I mention it in my manual as the right answer to the question nobody around you is asking. I use it. So does one other person I know.

This is the fundamental problem with secure messaging: it requires both parties to participate. You can make the right choice and find yourself talking to nobody. The most secure messaging app in the world is useless if your contacts are on WhatsApp.

The times of Messenger are over. The fragmentation is total. Pick Signal for the people who’ll use it, and make your peace with the rest.

Conclusion

Next time, we go deeper — and further from the keyboard. No tools, no configurations, no checklists. Just behaviour. The human factor is the one layer no software can harden for you, and the one layer most guides conveniently ignore.

Until then: stay paranoid, but have fun.

Starkiller Phishing Kit: Why MFA Fails Against Real-Time Reverse Proxies

2026-02-24T00:00:00+01:00

Sorry, no Hardening macOS this week.

I actually wanted to, but my attention was caught on something else, somehow more urgent. Originally I wanted to limit this blog to Apple and BSD-related contents, but this attack deserves all my attention for a simple reason:

IT IS BEAUTIFUL

*As much as I despise cybercriminals, I think that these mofos are really what pushes the Internet forward.

And when an attack is well crafted, chapeau!, let’s admit it!

Don’t worry, Hardening (and also Reversing 101) will come back next week!

Introduction

This week, Dark Reading reported on a phishing-as-a-service platform called Starkiller, disclosed by researchers at Abnormal AI. Krebs picked it up too.

If you haven’t read the article, go read it. I’ll wait.

Done? Good. Now let me tell you why this thing kept me up past my usual 3:30 AM. If you haven’t, fear not - I’ll fill you in.

The new kid in town is actually a new generation of phishing-as-a-service (PaaS) platforms. This new kid has radically changed the phishing threat model (finally, I’d say. It was sooo 90ish using “Employee security training” as the panacea for everything… but they won’t learn): these platforms do not create fake login pages - they actually proxy the real ones in real time. Aim’s capturing credentials, MFA tokens, session cookies - the whole landscape of boring things. What makes this different is the flow: the user authenticates for real, and credentials are stolen in transit, contextually, as the session happens.

Traditional defences such as domain blacklisting, static page analysis, and obviously MFA pathetically fail to AitM (which, by the way, means Adversary in the Middle. Because the Man in the Middle was not an adversary, clearly…).

Let’s not panic, anyway. We know there’s no perfect defence… but there’s no perfect attack either.

Technical Analysis

The old-phashioned phishing

The usual way to mount a phishing attack was kind of boring: the attacker created a static HTML page, a clone of the actual login page. The user then enters credentials, which are captured. Later on, the credentials get replayed.

It goes without saying that here MFA constitutes a great defence.

These cloned pages go stale quickly, look imperfect, and are easily fingerprinted by security vendors.

The New Way

The attacker runs a reverse proxy, often a headless Chrome instance in a docker container. This reverse proxy:

loads the actual login page from the legitimate service
serves the page to the victim - although through the attacker infrastructure
intercepts everything while in transit:
1. keystrokes
2. MFA codes
3. session cookies
this easily leads to obtaining an authenticated session, not distinguishable from the real user’s

The victims: they see the real website, with real content, real functionalities, and real MFA prompts. Everything is real, because everything is real. It’s just taking a detour through someone else’s server. The only anomaly being the URI - and modern kits easily disguise the URIs!

So, dear “Solve everything with MFA”-consultant, now it’s time you find another mantra. But let me explain you why your old mantra is not enough anymore.

MFA does not protect against session hijacking through a real-time proxy. The user completes the MFA challenge legitimately. The token is valid. The session is real. The attacker just happens to be forwarding everything through their own pipe.

The question is not “was MFA completed?” The question is: does the authenticated session behave like the legitimate user?

Key capabilities of Starkiller

Capability	Impact
Real-time page proxying via headless Chrome	No static templates to fingerprint
Session token & cookie theft	MFA bypass without breaking MFA
Live session monitoring	Attacker watches victim interact in real-time
Keystroke logging	Captures everything, not just form submissions
URL masking (@ trick, URL shorteners)	Disguises malicious links
Automated Telegram alerts	Instant notification on credential capture
Campaign analytics dashboard	Conversion tracking, geo-targeting
Subscription model with updates	Continuously evolving, harder to detect

Who’s Behind It

Starkiller is one of several services offered by a threat group called Jinkusu. It’s sold as a subscription service with community support, feature requests, and regular updates — mirroring legitimate SaaS business models.

A subscription service. With a dashboard. With campaign analytics. With customer support on Telegram. If this wasn’t scary, it would have been ph-ashinating.

Why Traditional Defences Fail

Defence	Why It Fails Against AitM
Domain blocklisting	New domains spun up per campaign; domains are burned and replaced
Static page analysis	No static page exists — content is proxied live
URL reputation filtering	URL shorteners and the @ trick bypass reputation checks
MFA (TOTP, SMS, push)	The user completes real MFA; the token is intercepted in transit
Email gateway scanning	Phishing links point to infrastructure that serves benign content to scanners
Security awareness training	The page is real, the certificate is valid, the content is legitimate

Ok, now we have a grasp of the severity of the situation. It’s not nice, at all, but again, there are many things you can do. The first one, being getting rid of mantras.

Detection

Detection must shift from “is this page fake?” to “is this session behaving normally?”

Easier said than done.

TLS Fingerprinting

Every TLS client — browser, automation tool, or proxy — produces a distinctive handshake pattern called a JA3 fingerprint. This fingerprint is derived from the cipher suites, extensions, and elliptic curves offered in the TLS ClientHello message.

Detection signal:

ClientHello with fewer extensions than expected for the claimed User-Agent
Cipher suite ordering inconsistent with the browser version
Missing GREASE values (real browsers inject these; some headless configurations don’t)
JA3 hash matching known automation/proxy fingerprints

Operational note: I have developed a proof-of-concept tool (ja3-probe) that demonstrates this detection capability. The PoC parses TLS ClientHello messages, extracts JA3 components, and classifies the client against a database of known fingerprints.

Post-Authentication Behaviour Analysis (Identity Layer)

This is the most critical detection layer. Even if the attacker captures a valid session, the replayed session will exhibit anomalies:

Proxemics: (AKA “you’re not Superman, you’re not the Flash. You’re not even Sideshow Bob) A legitimate user authenticates from London, then the session is used from an Eastern European IP like 30 seconds later. Something phishy, there.
Session token reuse: The same token appears from multiple IP addresses or device fingerprints. Obviously this requires some infrastructure.
Device mismatch: Authentication completed on a known corporate device, but the session is replayed from an unknown device
Behavioural deviation: Post-login actions don’t match the user’s established patterns (e.g., immediately creating mail forwarding rules)

Recommended actions:

Enable Continuous Access Evaluation (CAE) where available (Microsoft Entra supports this, and so does Okta Identity Threat Protection)
Implement session binding to IP address and device fingerprint at the identity provider level
Alert on inbox rule creation within 60 minutes of authentication from a new location
Monitor for OAuth app consent grants from unexpected sessions

DNS & Certificate Intelligence (Infrastructure Layer)

AitM infrastructure leaves traces in the DNS and certificate ecosystem:

Certificate Transparency (CT) logs: Simultaneous issuance of multiple certificates for subdomains mimicking SSO portals is a strong indicator
Domain age: Phishing domains are typically registered within 72 hours of use
DNS patterns: Research by Infoblox has shown that Evilginx campaigns produce consistent DNS patterns even when hiding behind Cloudflare, enabling signature-based tracking
Dedicated feeds: Lab539 has developed methods to identify AitM infrastructure before it’s used in campaigns

But this is redundant for you, because you read First hardening of the network layer and you learned how to harden your DNS settings so that new domains are not resolved. Yes, you can say that it’s your DNS, not your customers, but there you go: the solution is as easy as recommending your customers to read that article! Better yet, to become avid readers of this blog.

Anti-Evasion Awareness

Modern AitM kits actively detect and evade security scanners:

They serve benign redirects to non-browser User-Agents
They use bot detection (JA4 fingerprinting) to filter scanner traffic
They employ short-lived URLs that expire after a single use

This means passive scanning and crawling are unreliable. Active detection must focus on signals visible during real user sessions, not on probing the phishing infrastructure from outside.

Before some vendor or LinkedIn compliance bard weaponises a sentence in this post, it is worth reiterating that:

JA3/JA4 are correlation signals, not verdicts.
FIDO2/passkeys are highly effective when properly deployed, but weak fallback flows can reintroduce risk.
DNS hardening reduces exposure; it does not “solve phishing” in isolation.
IP/device/session binding must be implemented with risk-based logic, not cargo-cult rigidity.
Actions

Technicalities

Deploy FIDO2 / Passkeys for high-value accounts. This is the single most effective countermeasure. FIDO2 authentication is cryptographically bound to the legitimate domain. Properly deployed FIDO2/passkeys are phishing-resistant because the authentication ceremony is bound to the legitimate origin (RP ID). An AiTM proxy on a different domain cannot simply relay that like it relays passwords or TOTP codes.. This is not a workaround — it’s a fundamental property of the protocol. If you do one thing after reading this post, do this.

Implement session binding. Tie your session tokens to the IP address and device fingerprint that created them. If a session token suddenly appears from a different IP in a different country, that’s not your user. Kill the session.

Enable Continuous Access Evaluation (CAE) if you’re on Microsoft 365 / Entra. CAE allows near-real-time revocation of sessions when risk signals are detected. It’s not enabled by default. Enable it.

Monitor post-authentication behaviour. The classic AitM-to-BEC escalation path is: steal session → create inbox forwarding rules → send fraudulent payment requests. Alert on inbox rule creation within the first hour after authentication from a new location. Alert on MFA method changes. Alert on OAuth app consent grants.

Inspect TLS fingerprints. Feed JA3/JA4 hashes from your reverse proxy or WAF into your SIEM. Flag connections where the TLS fingerprint doesn’t match the claimed User-Agent.

Subscribe to AitM-specific threat intelligence. Lab539 and Infoblox both publish feeds that identify AitM infrastructure, sometimes before it’s used in campaigns. Integrate these into your DNS-layer blocking.

La touche de l’Architecte

Password managers are your canary. A password manager will only auto-fill credentials on the domain where they were saved. If your password manager doesn’t offer to fill in your Microsoft credentials, you’re not on Microsoft’s domain. Train your users to notice this.

Plan for passwordless. The long-term answer to credential-based attacks is eliminating credentials. Passkeys, certificate-based authentication, hardware tokens. The credential that doesn’t exist can’t be stolen.

What You Should NOT Do

Do not panic-buy a vendor solution without understanding the problem first.

I mean it. Every time a new attack technique gets media coverage, the vendor machine spins up. By next week you’ll have twelve companies telling you their product “stops Starkiller” or “prevents AitM attacks” with some proprietary AI-powered-blockchain-quantum-something.

Before you buy anything, ask yourself:

Do I understand how AitM actually works? (If you’ve read this far, you do.)
What layer does this vendor’s solution operate at? If it’s just email filtering, it won’t help once the user clicks the link. If it’s just domain blocklisting, it won’t help against freshly spun-up infrastructure.
Does this solution address session hijacking, or just credential theft? Because AitM is a session hijacking attack. Stopping the credential theft is nice, but if the session token is already gone, you’re still compromised.
Have I done the basics first? FIDO2, session binding, CAE, post-auth monitoring — these are free or near-free and more effective than most paid solutions.

The security industry has a vendorisation problem. Every threat becomes a sales opportunity before it becomes a learning opportunity. Don’t let that happen to you. Understand the attack. Implement the fundamentals. Then evaluate whether you need additional tooling.

And for the love of all that is holy, stop treating MFA as the end of the conversation. It’s the beginning.

Some self promotion

Yeah, I don’t like pushy vendors, therefore I hate selling myself as well. However: remember that in my last posts i randomly ranted about rotten scrapers and revolting script kiddies messing with my resources? Well, if not, you don’t miss much - but I had these issues. Nastier than caries, more insistent than the aforementioned salesman.

What did I do? My response was deliberately nasty. Aradia. There you go: https://www.aradia.zone. Have a look there. Aradia does all the tech-stuff you’ve seen before. And more, because its reason to be is to torture mofos wasting your resources.

Or get in touch with me. I am quite often on https://infosec.exchange - my handle is @gbiondo.

Curious what this looks like in production? aradia.zone/stats

Conclusions

I am a man of my word. You will see a new article in a week for the Hardening macOS series. Perhaps also for the Reversing 101.

In the meantime, be ruthless, be smart, be paranoid, and be also iron man, for fairies wear boots.

And have fun!

References

Abnormal AI, “Starkiller Phishing Kit” (February 2026) — https://abnormal.ai/blog/starkiller-phishing-kit
Krebs on Security, “‘Starkiller’ Phishing Service Proxies Real Login Pages, MFA” (February 2026)
Infoblox, “DNS Uncovers Infrastructure Used in SSO Attacks” (December 2025)
Kulkan Security, “See no Evil(ginx) / Detecting and Stopping AitM Phishing Threats” (February 2026)
Microsoft Security Blog, “Detecting and mitigating a multi-stage AiTM phishing and BEC campaign” (June 2023)
Push Security, “Phishing 2.0: How Phishing Toolkits Are Evolving with AitM” (April 2025)
Salesforce, JA3 — https://github.com/salesforce/ja3
FoxIO, JA4+ — https://github.com/FoxIO-LLC/ja4

Hardening macOS 4: Secrets Management & Hardware Security Keys

2026-02-17T00:00:00+01:00

Long week.

I worked on Aradia, mainly. It’s something I’ wi’ll discuss with you shortly - but for the time being: remember I was complaining about a noticeable scraping attack? Well, Aradia is the answer.

_Another news that can be of interest for you: all the content of these lessons, enriched with theory, exercises, and tips will be part of the “Digital Self-Defence Manual” - an ebook I’m publishing, that should see the light in Q2 2026. Hopefully.

‘til then, only these posts, sorry about that!

Previous posts on this series

macOS Hardening: a new series
First hardening of the network layer
Hardening macOS pt.3: Browsers compartmentalisation
Introduction

In this post we’ll talk about one of the most important aspects of security: managing access to systems and services.

In general, when you access a system, you need to provide your credentials. These are evaluated and then access is granted. Once access is granted, you can perform some activities, according to your authorisation level.

So: Authentication, and Authorisation. Whilst Authorisation is totally outside of your sphere of influence, Authentication is. You have passwords, and increasingly other pieces of information required to access the system (tokens and other forms of MFA).

Therefore, Authentication is mostly based on something you know (passwords), and quite often on something you have (tokens, certificates), and sometimes, on something you are (biometric information such as your face or your fingerprints). Some advanced mechanisms also work on something you do, but they are not so widespread enough to be relevant here.

Our objective now is protecting our secrets (passwords, API Secrets, certificates, other debris) from a plethora of enemies:

ourselves. We are our own worst enemy when we reuse passwords and certificates. Revoking, changing, and rotating secrets is basic hygiene. You wouldn’t take a shower and put on your dirty undies, would you?
cybercriminals. I know, I never mention them as enemies, but they’re there. They act in weird ways, targeting different attack surfaces, such as:
1. yourself - indeed, dude: this happens more often than you’d think. Not always via computer (I bet you’ve received tons of calls in which someone asks you for personal data)
2. your browser - as solid as your browser may be, it’s still a browser. It is not a password manager. Distrust browsers pretending to be password managers - if for no other reason, because you don’t always use your browser (think about a terminal connection, for instance).
3. your trust - although not really secrets-focused, keep in mind that you should give your passwords to no living being. Not even that hot chick you met on a random social (yes, sometimes they ask you for passwords)
system corruption - very unlikely, but it happens. Countless times a cute OS with a cuter penguin scrambled its /etc/passwd. Especially in its cute, early years…

So, let’s get the elephant out of the room first: calls and scams. I never planned to cover this, but I’ve been receiving too many calls from too many people with strange accents and broken English that I think giving you some hints can’t hurt. Then we move on to the good stuff.

Scams

What do the following plots have in common? Note - I’m not transliterating the accents.

Phone call 1: “Good morning, Sir. This is Mr. <unspeakable name that spoken backwards would summon Pazuzu> from the Court of London. We have a file on you. You owe <a consistent amount of money> and if you don’t pay, this will impact:

your credit score
your criminal records
your hairline - you’ll become immediately bald
other things Now you give us your personal data, but you need to wire 5k to us. “

Phone call 2: “Good morning, Sir. Here is mr. <another unspeakable name, but this time, if you speak it backwards, you’d summon Cthulhu> from <your mobile carrier>. We have a new contract proposal for you, if you accept the proposal you’ll receive

123 days a month of free phone traffic
190 hexabytes of free traffic. Per hour
every week, the winning EuroMillions numbers
Charlize Theron (yes, I am that old)
Santa’s sleigh The only thing you need to give us is your name, your phone number, and the pin of your contract… “

So, what is the punchline? Several aspects:

these guys don’t know anything about you. Otherwise, they would not ask for your personal data.
something “too bad” about to happen to you? Well, you’d suspect — at least — that something was coming. Nothing that big comes out of the blue, does it?
something “too good to be true”? Well — you’ve only had one stroke of great luck in this life: stumbling on my blog. Seriously: if your carrier wanted to get in touch with you, they would use other channels, not a phone call.
Nobody asks you for a pin or a password on the phone. If they do, and you tell them to go do pushups on the motorway, nobody could blame you. You can always say that it sounded like a scam.

The answer? My polite answer is “Ok, nice. What’s my name?”. Then, you have the funniest answers like “how dare you, not cooperating with the Court?”. Ibid - if it were really the Court, even a newly graduated solicitor could defend your position. But the Court does not contact you like that, sure as taxes and death.

Uh, by the way: these dialogues are exaggerated. Real scams are more subtle — which is precisely why they work. But the patterns are real.

Now, let’s come back to business.

Most Apple users don’t really think much about secrets management. It’s kind of normal - “do you want to save the password not in Safari but somewhere else on your system? Plus, it is safe! AES256!” sounds very reasonable. And if we look at this from a sceptical perspective, it’s not entirely false.

The Passwords Utility and the Apple Keychain are two great pieces of software. Very secure, indeed, but with some limitations.

Many colleagues complain about the portability factor, their arguments being:

the Combo Passwords Utility/Apple Keychain works solely on Apple. Linux, other BSDs, Windows - no access at all. Tough luck
It’s closed source. You have to trust Apple. Full stop. Nobody can audit it.
Everything passes through Apple’s servers. And although communication is E2EE, you have no control over the infrastructure.
Apple can change their policies when they want and you have no control over that.

I find these arguments quite naive, actually. Perhaps because I don’t spearhead any crusade, but to me the real issues are different. They’re not wrong — but these are ideological concerns. The practical ones bite harder.

You wanna talk about Vendor lock-in-ness? Here we go:
- if you lose access to your Apple ID, you’re on your own, buddy. No access to your passwords. Including the password of your Apple ID. Yes, really.
Technical limits:
- try to export your passwords. You get an unencrypted CSV file. My corneas are still bleeding.
- no terminal access. This is painful, especially if you’re like me (I currently have 42 open terminals, not counting the pseudo-terminals from VS Code, Zed, and RustRover)
- No SSH key management. At least, not integrated.
- No custom fields for API keys/secrets, tokens, recovery codes, notes… anything that you would really need.
- limited secrets sharing. Only with Apple users, at that.

Warning - If you ever use Apple’s CSV export, delete that file with srm or immediate disk wiping. Leaving an unencrypted list of all your passwords in your Downloads folder is the digital equivalent of leaving your house keys taped to the front door.

However, “the Combo” has several good aspects:

AES 256 encryption. An industry standard.
Biometric unlock. It seamlessly integrates Face ID/Touch ID. From a UX perspective, this is perfect.
Smart Autofill. Phishing-resistant — it fills in credentials if and only if the domain matches. Kudos!
Sandboxed in the OS. Not a third-party app, with its own attack surface.
It is already there, in every fresh macOS installation. You don’t need to install anything.
You’re nudged into using it. You use a password, you are asked to save it.
Decent password generator.
Automatic sync among iCloud devices.
Native passkeys support.

There’s one aspect that goes unnoticed, and to me it’s the real differentiator: at the end of the day, the best password manager is the one that people actually use. So if your grandma was used to writing her password in her scratchpad-for-everything and starts using “the Combo”, bring her some flowers. She deserves them. If only for her unbeatable Apple cake!

In my opinion, the only viable alternative is the kdbx format.

The `kdbx` format

This time I’m referring to a format rather than a program, for a reason: there are multiple programs that interoperate with it, so everybody can choose according to their preferences.

If I am not mistaken, the support matrix is as follows:

Program	Platform	Notes
KeePass	Windows (Linux/macOS via Mono)	The original. Interface from another era, but rock solid.
KeePassXC	macOS, Linux, Windows	The community fork. Modern, actively maintained, browser extension. The desktop reference.
KeeWeb	macOS, Linux, Windows, Web	Electron-based, clean interface. Also runs as a web app.
Strongbox	macOS, iOS, iPadOS	Native Apple client. YubiKey support, free tier + Pro.
KeePassium	iOS, iPadOS	Open source, independently audited. YubiKey NFC/Lightning. Free tier + premium.
KeePassDX	Android	Modern, actively maintained. The Android reference.
Keepass2Android	Android	YubiKey challenge-response support. Solid alternative.
AuthPass	Android, macOS, Linux, Windows	Cross-platform, friendly interface. Less known, but capable.
kpcli	Linux, macOS	Command line interactive shell. For terminal lovers.
passhole	Linux, macOS	CLI inspired by `pass`. Python-based.
KeePassXC-Browser	Firefox, Chrome	Browser extension, connects to KeePassXC. Autofill done right.

Pro’s and con’s, indeed. Choose your bane. In this post I will talk about Strongbox because it is my choice, but it’s a matter of personal preference.

Download and install the client of your choice, and run it. The first thing you need to do is create the database for your keys. There are multiple options here, depending on the client itself, but at the end of the day there’s a choice to make: online vs. offline databases.

This choice obviously depends on your needs and use cases, so I’ll just give you some criteria. Remember, security is useless when it hinders usability, so make a choice and secure it.

	Online (cloud-synced)	Offline (local file)
Availability	Access from any device, anywhere	Only where the file physically is
Sync	Automatic across devices	Manual (USB, SCP, rsync, your problem)
Backup	Cloud provider handles redundancy	You handle it. No excuses.
Attack surface	Cloud provider is a target. Breach = your vault exposed (encrypted, but still)	No remote attack surface. They need physical access.
Trust	You trust the cloud provider with your encrypted blob	You trust yourself. And your backup discipline.
Single point of failure	Provider goes down / bans your account = locked out	Disk dies without backup = game over
Forensics	Metadata: when you access, from where, how often	No metadata leakage
Convenience	High	Low to medium
Control	Partial	Total

At a glance: Offline means more secure, Online means more usable.

Let’s imagine a use case where the user wants to mimic Apple’s Combo, so we opt for the online solution.

To set up the client as we planned, first we create a database. In my case, Strongbox offers a few good options:

Strangely enough, Strongbox doesn’t explicitly list iCloud Drive as a storage option in the creation dialog — but if you choose ‘File’ and save it in your iCloud Drive folder, it works and syncs across devices. If you don’t like this, you have plenty of options, as Strongbox supports its own Sync technology, local files, OneDrive, Dropbox, Google Drive, SFTP, WebDAV.

We want to make our life easy and sync with other Apple devices, therefore we opt for the native solution. Note that this option may not work with third-party devices, such as Android phones or Linux boxes. Choose wisely.

The creation of a database gives us:

desdinova@HardenedPanettone ~ % ls -al /Users/desdinova/Library/Mobile\ Documents/com~apple~CloudDocs| grep kdbx 
-rw-r--r--@   1 desdinova  staff      1093 16 Feb 11:54 A new database.kdbx

Neat. The file actually saves to iCloud.

The rest is really client-dependent, and some aspects may vary. Creating an entry is trivial, but Strongbox offers some interesting options:

Notice the passphrase generator: 134 bits, over 100 million years to crack. This screenshot is worth more than an entire post on password theory.

I want to show you some Strongbox settings. I open Database settings (⇧⌘,) to get

Now, this comes in handy: the extensions for your browsers:

Firefox, LibreWolf, Mullvad: https://addons.mozilla.org/en-GB/firefox/addon/strongbox-autofill/
Chrome, Brave, Chromium-based browsers: https://chromewebstore.google.com/detail/strongbox-autofill/mnilpkfepdibngheginihjpknnopchbn
Safari: see below

The remaining part of the settings is either client-specific or crypto-related. The good thing is that our password manager is now partially integrated with our browsers. To finalise the integration, we must enable it system-wide.

To do so - System settings, General, AutoFill & Passwords: enable the Secret Managers you want.

Multi-Factor Authentication

Your password manager is set up. Your passwords are strong, unique, and stored in an encrypted database. Good. Now let’s talk about what happens when your password gets stolen anyway.

Because it will. Breaches happen. Phishing happens. Keyloggers happen. The question is not if someone gets your password, but what they can do with it.

The answer should be: nothing. That’s where Multi-Factor Authentication (MFA) comes in. You already know the concept — something you know (password) plus something you have (a token). Enable it everywhere. No exceptions.

Now, not all MFA is created equal:

SMS codes: better than nothing, but barely. SIM swapping is trivial for a motivated attacker. If this is your only option, use it — but don’t sleep well at night.
Authenticator apps (Google Authenticator, Authy, etc.): better. The code is generated on your device, not sent over the network. But if your phone is compromised, so are your codes.
Hardware security keys: the gold standard. A physical device that must be present to authenticate. No phishing, no remote compromise, no SIM swap. You either have the key, or you don’t get in.

The two main players in the hardware key space are YubiKey and Google Titan:

	YubiKey 5 Series	Google Titan
Protocols	FIDO2, U2F, PIV, OpenPGP, TOTP, Smart Card	FIDO2, U2F
Connectors	USB-A, USB-C, Lightning, NFC	USB-A/NFC, USB-C/NFC
Passkeys storage	~100	~250
Price	£50–70	£25–30
Versatility	SSH agent, PGP signing, smart card, TOTP — the Swiss army knife	Web authentication only

If all you need is solid 2FA for your online accounts, Titan does the job at half the price. If you want a single device that handles SSH keys, PGP signing, smart card authentication, and TOTP on top of FIDO2 — YubiKey is the answer.

I use YubiKeys. Two of them — because hardware dies, gets lost, and goes through the washing machine. Always register two keys on every service that supports it. Keep one on your keychain, one in a safe place. If you lose both, recovery codes are your last resort — and yes, those should be in your password manager too.

One final note: whatever you choose, register your hardware keys on all critical services first. Email, cloud storage, password manager, banking, code repositories. These are the dominoes — if one falls, the rest follow. Start from the top.

One last thing: back it up.

Your secrets are now in one file. One encrypted, portable, beautiful file. Which means: lose that file, lose everything.

If you chose the online route, your cloud provider handles redundancy — but don’t rely on that alone. Download a local copy. Put it on an encrypted USB drive. Store it somewhere safe, somewhere physical, somewhere that is not your laptop bag.

If you chose the offline route, this is entirely on you. No backup, no sympathy.

In both cases: test your backup. Open it, unlock it, verify it works. A backup you’ve never tested is not a backup — it’s a hope.

Conclusion (with Will-o’-the-Wisp)

We covered a lot of ground today. We got the scam elephant out of the room, discussed why Apple’s Keychain is good but not enough, explored the kdbx ecosystem, set up a proper password manager, and put a hardware lock on our digital lives.

None of this is paranoia. This is basic hygiene — the digital equivalent of locking your front door and not leaving the key under the mat.

But if you’ve been paying attention, you’ve probably noticed some gaps. Things I haven’t mentioned. Tools I haven’t recommended. Practices I’ve deliberately avoided.

That’s not an oversight. In the next and final post, we’ll talk about what I consciously left out — and why. Because in security, what you choose not to do matters just as much as what you do.

Stay paranoid, but have fun.

References

Fraud and scams

The Byte Architect

Apple Defences - APFS and the SSV

Introduction

How it all begins

The filesystem

Snapshots

Sealing

Putting it all together: SSV

Conclusions

Memento, deinde loquere

Filesystem Wars: Why Your Choice of Storage is Actually a Security Move

Enter the arena

In memoriam - ReiserFS

THE FUNDAMENTAL PROBLEM: Crash Consistency

FFS/FFS2

Key architecture

Security model

Operational assumptions

Weaknesses

Overall commentary

ZFS (Zettabyte File System) — Sun Microsystems / OpenZFS

Key architecture

Security model

Operational assumptions

Weaknesses

Overall commentary

BFS (Be File System) — BeOS / Haiku

Key architecture

Security Model

Operational Assumptions

Weaknesses

Overall Commentary

NTFS

Key Architecture

Security Model

Operational Assumptions

Weaknesses

Overall Commentary

Ext4

Key architecture

Security model

Operational Assumptions

Portability

Other weaknesses

Overall commentary

APFS

The Container Model

Copy-on-Write (CoW)

Snapshots and Clones

Encryption

Space Efficiency

Crash Consistency

What APFS Learned

Philosophy

Operational Assumptions

Weaknesses

Overall Commentary

The tables that Google loves sooooo much when indexing your website

Overall comparison

Conservatively estimated failure rate (my bullshit math)

Comparison ages

Soft Updates vs. Journaling vs. CoW

Conclusions

Hardening macOS part 6: The Human Surface and Metadata Risks

Context

The main exposure: the user

Exercise:

Metadata: what your data says when you’re not talking

Exercise

Social media patterns

Books on your shelf, again

What you actually do about it

The Digital Twin you didn’t know you were building

Social login: convenience is a hell of a drug

The trust problem

What you actually do about it

Credentials hygiene

## Password reuse: the attack that never gets old

How it actually works

The human problem

Use `ssh-agent` to avoid typing it constantly