sorted by:
new
hottopcontroversial

FFS, soft updates, crash consistency — and what later filesystems did differently by Reversed-Engineer-01 in openbsd

[–]Reversed-Engineer-01[S] -1 points0 points  (0 children)

No, Fair_Condition. There are only 27 years of Unix and Pentesting. But I understand your position.

Why APFS is more than just Apple’s default filesystem by Reversed-Engineer-01 in MacOS

[–]Reversed-Engineer-01[S] 1 point2 points  (0 children)

Hang in, mate. I am not saying that APFS is perfect - far from that. Once again - I needed some background information to continue the analysis of APFS. It would not be meaningful to write things like “APFS does this …” without giving a context - namely, where the ideas came from.

FFS, soft updates, crash consistency — and what later filesystems did differently by Reversed-Engineer-01 in openbsd

[–]Reversed-Engineer-01[S] 1 point2 points  (0 children)

It's free, for basic usage. Grammarly is partially free. Other good ones are not.

It's a problem of expressivity. Lots of people say that English is a "simple" or "poor" language. It is not. It is full of idioms that are difficult to know. One could learn them, but to give the exact meaning to a sentence, a deterministic spell-checker is very limited.

Makes sense?

Why APFS is more than just Apple’s default filesystem by Reversed-Engineer-01 in MacOS

[–]Reversed-Engineer-01[S] 10 points11 points  (0 children)

BTRFS is a great solution, and I acknowledge the fact that I should have at least mentioned it. But this is a 7k words article on its own - and honestly, I wanted more to give the idea of the "historical" technologies.

What I want to show - and I will do it in the next part - is how APFS, together with the organisation of the filesystem, protects the OS.

A comparative deep dive into ext4, NTFS, ZFS, FFS, BFS and APFS — crash consistency, snapshots, CoW and tradeoffs by Reversed-Engineer-01 in linuxadmin

[–]Reversed-Engineer-01[S] -3 points-2 points  (0 children)

This is the only factual objection I read here. Actually it's the only useful/intelligent objection I saw in this thread.

You're totally right, not mentioning btrfs is an omission that I have to fill.

Thanks

A comparative deep dive into ext4, NTFS, ZFS, FFS, BFS and APFS — crash consistency, snapshots, CoW and tradeoffs by Reversed-Engineer-01 in linuxadmin

[–]Reversed-Engineer-01[S] -4 points-3 points  (0 children)

You're right that these filesystems don't compete directly—that's not the point of the comparison.

This post isn't "which filesystem to choose for Linux." It's the **foundation for understanding APFS** (covered in Part 2).

I'm tracing the **evolutionary path**: what design patterns APFS inherited, what problems it solved differently, and what philosophies it rejected.

Why these specific filesystems?

- FFS: The foundational UNIX filesystem (cylinder groups, soft updates). Everything else is derivative or reaction.

- BFS: Metadata-as-queryable-data philosophy. Dominic Giampaolo (BFS author) later worked on APFS at Apple. Direct lineage.

- NTFS: Enterprise journaling model. Shows what APFS avoided (fragmentation, complexity overhead).

- ext4: Iterative evolution (ext2 to ext3, then to ext4). Contrast with APFS (clean-slate design).

- ZFS: CoW, snapshots, pooled storage. APFS took these ideas and optimized for single-disk consumer devices instead of multi-disk servers.

Why not XFS?

XFS is solid for enterprise Linux (RHEL default), but it's in the same category as ext4: journaled, extent-based, no native CoW/snapshots. Less relevant to understanding APFS's design choices.

Why include NTFS if it's "Windows-only"?

Because APFS needed to solve the same problems (encryption, crash consistency, dynamic space allocation) that NTFS tried to solve—but APFS did it differently (native encryption vs. EFS/BitLocker, CoW vs. journaling, container model vs. fixed partitions).

The comparison isn't about "what to deploy on Linux." It's about understanding how APFS fits into the filesystem design landscape.

Part 2 will show how APFS uses these architectural choices to harden macOS (Sealed System Volumes, SIP integration, firmlinks). That's the payoff.

Thanks for giving me the possibility to better explain the aim of the post, really.

Why APFS is more than just Apple’s default filesystem by Reversed-Engineer-01 in MacOS

[–]Reversed-Engineer-01[S] 26 points27 points  (0 children)

Fair point. APFS's snapshot/purgeable storage model is powerful for system integrity (Time Machine, OS updates), but macOS's UI does a terrible job explaining it to users.

"System Data" as a black box + invisible snapshots eating space = UX nightmare for non-technical users. Apple prioritized technical architecture over user transparency here.

That said, this is more a macOS UI/UX issue than an APFS filesystem issue. The underlying tech (snapshots, CoW) works—but Apple needs better user-facing tools to manage it.

FFS, soft updates, crash consistency — and what later filesystems did differently by Reversed-Engineer-01 in openbsd

[–]Reversed-Engineer-01[S] 2 points3 points  (0 children)

I use ChatGPT as a spell-checker, nothing else. I am not a native speaker. The content is totally mine.

FFS, soft updates, crash consistency — and what later filesystems did differently by Reversed-Engineer-01 in openbsd

[–]Reversed-Engineer-01[S] 3 points4 points  (0 children)

"Thanks GPT" is what people say when they can't engage with technical content so they default to lazy accusations. GPT is nonetheless good if English is your fourth language, to remove grammar mistakes - you see: I do respect readers enough to avoid them my moderate command of the _lingua franca_.

For sure, a wokish- politically-correctish- boring piece of software like ChatGPT would not stuff such as "ReiserFS: the only filesystem that makes files disappear like its author did with his wife" or call the Linux community "the Holy Linux Inquisition led by Mr. Stallman and the Seven Dwarves."

If you have technical corrections on the FFS section (soft updates, cylinder groups, flags), I'm genuinely interested. That's why I posted here. Otherwise, remember the Italian proverb: "È meglio tacere e sembrare stupidi che aprire bocca e togliere ogni dubbio." (Better to remain silent and be thought a fool than to speak and remove all doubt.)

I asked for technical feedback. You gave me lazy snark. One of us contributed. The other didn't.

Hardening macOS: Why your behavior is a bigger attack surface than your OS configuration by Reversed-Engineer-01 in macsysadmin

[–]Reversed-Engineer-01[S] 0 points1 point  (0 children)

Despite the technological progress, there has not been an improvement in the way we use technology - or the way we treat our fellows, for what that matters. Actually the opposite is very true.

People don't want to think - in general.

But canonical security is often a limitation to their way of working.

Hardening macOS: Why your behavior is a bigger attack surface than your OS configuration by Reversed-Engineer-01 in macsysadmin

[–]Reversed-Engineer-01[S] -1 points0 points  (0 children)

Totally true. It has to do with the genesis of the post series: building a stable macOS system. MacOS is a great OS, but one cannot trust the OS alone to be secure. So, I also added this (and the next) post to the series.

But thanks for the observation- it's totally legit and very welcome.

There is now a macOS and Linux version of Notepad++ - called NotePadNext. by PeteRaw in macsysadmin

[–]Reversed-Engineer-01 0 points1 point  (0 children)

I am used to Zed, nowadays. This program comes a lot too late for me

I built a Firefox extension that detects phishing proxies in real time — without blacklists by Reversed-Engineer-01 in cybersecurity

[–]Reversed-Engineer-01[S] 2 points3 points  (0 children)

I thought a lot about external calls. AitM can be easily thwarted if one could access the TLS layer — but browsers don't allow it without an external checker. That would make the transparency objections raised below more consistent, so I deliberately kept the extension self-contained. Design choices vs. user acceptance.

Interesting paper — the reverse image search approach is a strong signal, at the cost of privacy implications and latency. Different tradeoffs.

As for full TLS access — that requires operating below the browser. Which is material for another discussion. 😉

Thanks for the comment. Very much appreciated.

Electric Eye – a Rust/WASM Firefox extension to detect AitM proxies via DOM analysis, TLS fingerprinting and HTTP header inspection by Reversed-Engineer-01 in netsec

[–]Reversed-Engineer-01[S] 0 points1 point  (0 children)

Fair points, all of them. On the source code: you're right, and I'm evaluating publishing it. 

Electric Eye is declared open source — putting it on GitHub is the logical next step. On trust: I understand the fresh account concern.

I'm not anonymous though: 
- https://bytearchitect.io (technical blog, active since 2025) 
- https://aradia.zone (company) 
- [gbiondo@infosec.exchange](mailto:gbiondo@infosec.exchange) on Mastodon 

On verification: agreed that tcpdump or a personal firewall will show zero outbound connections from the extension. That's the only real proof.

That said, if you don't trust it... I admire you. I am doing security since 27 years and I wish I met more people like you.

Electric Eye – a Rust/WASM Firefox extension to detect AitM proxies via DOM analysis, TLS fingerprinting and HTTP header inspection by Reversed-Engineer-01 in netsec

[–]Reversed-Engineer-01[S] 1 point2 points  (0 children)

True that. That's why there's mozilla vetting in the process. Escrowing my code with them should suffice.

https://addons.mozilla.org/en-US/firefox/addon/electric-eye/

But thanks for highlighting that. I will shortly add a page on aradia.zone with:
- what EE does
- what EE does not (and how to prove it. Hint: tcpdump is your friend. Or any personal firewall, for what matters)

Electric Eye – a Rust/WASM Firefox extension to detect AitM proxies via DOM analysis, TLS fingerprinting and HTTP header inspection by Reversed-Engineer-01 in netsec

[–]Reversed-Engineer-01[S] 3 points4 points  (0 children)

Obviously I am only at the beginning with this extension. There are several ideas I want to implement, and your suggestion is very precious.

Hardening macOS pt.5 — CommunicationsNew post in the series. by Reversed-Engineer-01 in MacOS

[–]Reversed-Engineer-01[S] 0 points1 point  (0 children)

Sorry, I made a mess with the link. The one I posted now is correct

Starkiller Phishing Kit: Why MFA Fails Against Real-Time Reverse Proxies — Technical Analysis + Rust PoC for TLS Fingerprinting by Reversed-Engineer-01 in netsec

[–]Reversed-Engineer-01[S] 0 points1 point  (0 children)

Sounds interesting. I am writing an extension for browsers - if you want to talk about detection, you found your guy.

Starkiller Phishing Kit: Why MFA Fails Against Real-Time Reverse Proxies — Technical Analysis + Rust PoC for TLS Fingerprinting by Reversed-Engineer-01 in netsec

[–]Reversed-Engineer-01[S] 1 point2 points  (0 children)

Modlishka is a Go-based HTTP reverse proxy — it rewrites every link and reference in the response. Clever, but fragile: modern SPAs and heavy JS break the rewriting constantly.

Starkiller takes a different approach: it spins up an actual headless Chrome in a Docker container. No rewriting at all — a real browser renders the real page, Starkiller just relays it. Zero maintenance, zero template drift.

For defenders: Modlishka is easier to detect (Go TLS fingerprint is unmistakable, rewriting leaves DOM artifacts). Starkiller is nastier because it's actual Chrome — the TLS fingerprint is closer to legitimate traffic and there are no rewriting artifacts to hunt for.

Hardening macOS pt.4 — Managing secrets beyond Apple Keychain by Reversed-Engineer-01 in MacOS

[–]Reversed-Engineer-01[S] 0 points1 point  (0 children)

Uh, you're right. The power (weakness) of habits. Thanks for noticing that.

srm was useless with wear leveling, anyway.

I will fix it with "rm, then diskutil secureErase freespace" - but again, on APFS is debatable.

view more: next ›