HNHacker News
TopNewBestAskShowJobs

cryptbe

572 karma · joined September 18, 2010

submissionscomments
cryptbe··on Today, we hacked what we'd set out to hack: the iPhone
Cool to see our work here. I'm Thai, and I run Calif. Happy to answer any questions.

We'll publish the technical details of these hacks over the coming weeks. Writing these articles takes time, and we've been busy with a PHP thing [1].

In the meantime, check out The Great Glyph Grift [2] for a glimpse of what can go wrong when iOS parses PDFs.

Just in case you wonder, we've disclosed most of the bugs in these exploit chains to Apple and will disclose the rest. So far in 2026, we've reported close to 100 bugs to Apple. We don't accept Apple bounties, and we're not being paid for this work. We don't sell bugs or exploits, and we have no sponsors funding this research.

We do this because it's fun, intellectually challenging, and we want to help make the iPhone safer. We also have a business to run, so we do need some marketing points.

[1] https://calif.io/php2shell

[2] https://calif.io/research/the-great-glyph-grift

cryptbe··on Today, we hacked what we'd set out to hack: the iPhone
Check out https://calif.io/research/the-great-glyph-grift, which shows one could go wrong with PDF in iOS.

We're gonna publish more in the coming weeks. Writing these blog posts take time, and we've been busy with another PHP thing.

cryptbe··on Today, we hacked what we'd set out to hack: the iPhone
We disclosed most bugs to Apple, and are going to disclose the rest. We've disclosed probably close to 100 bugs to Apple in the past 6 months.

We've also been working with closely with the Signal Foundation to help them reduce the attack surface.

It's not true that we don't want to make devices more secure. We do and it's why we do this research.

We also do want our name out there because we're having a lot of fun and want to share that with our friends and the rest of the world.

cryptbe··on Today, we hacked what we'd set out to hack: the iPhone
Thanks Tom! You're always super kind to us.
cryptbe··on Today, we hacked what we'd set out to hack: the iPhone
We disclosed most of the bugs used in these chains to Apple, and are going to disclose the rest, if not already.

>Just as a reminder for some folks here: During their WeWorm research in July–September 2026, Calif didn't stop at proving RCE to Tencent—they spent an extra week using AI to build a fully functional, self-propagating zero-click worm across three live phones, triggering temporary account bans from Tencent during testing.

Not sure what exactly your point is. The WeWorm demo was done in a controlled environment.

Also we do this for free. We don't charge neither Tencent nor Apple. We don't even take their bounties. Why can't we have some fun?

If you're so upset about how we do it, my suggestion is go find your own bugs.

cryptbe··on CVE-2026-28952: Apple macOS 26.5 Kernel Vuln found by Claude
Oh hey, this is our work! We helped Anthropic analyze and report this bug.

For the record, this bug has nothing to do with our recent MIE attack [1] [2], which exploited two different kernel bugs. Our bugs are not fixed yet.

[1] https://blog.calif.io/p/first-public-kernel-memory-corruptio...

[2] https://news.ycombinator.com/item?id=48139219

cryptbe··on Local privilege escalation via execve()
Nope. Try the PoC on macOS:

https://github.com/califio/publications/blob/main/MADBugs/fr...

The script downloads and sets up FreeBSD on QEMU, then runs the exploit.

The exploit is very smart: https://github.com/califio/publications/blob/main/MADBugs/fr.... It basically backdoors sshd.

cryptbe··on Local privilege escalation via execve()
You're always super kind to me :)
cryptbe··on Local privilege escalation via execve()
Nice to randomly encounter our own work here.

Check out our blog post for a fun walkthrough: https://blog.calif.io/p/cve-2026-7270-how-i-get-root-on-free...

AI-generated working exploit, write-up and prompts: https://github.com/califio/publications/tree/main/MADBugs/fr...

cryptbe··on "cat readme.txt" is not safe if you use iTerm2
The feature is enabled by default. You can test it by yourself.
cryptbe··on "cat readme.txt" is not safe if you use iTerm2
This is a good title, thanks! There was iTerm2 in the original title, but it overflowed to the subtitle in Substack.

I've now updated the blog post.

cryptbe··on "cat readme.txt" is not safe if you use iTerm2
Disclosure: I didn't discover the vulnerability. I wrote the blog post.

Thanks for releasing a fix!

It was surprising that there wasn't an official release, even though the bug impacts otherwise routine, harmless workflows. The patch itself [1] framed the issue as "hypothetical," so the goal of the blog post was to demonstrate that it is not. I'm glad that you've agreed to release a fix.

[1] https://github.com/gnachman/iTerm2/commit/a9e745993c2e2cbb30...

cryptbe··on "cat readme.txt" is not safe if you use iTerm2
Disclosure: I didn't discover the vulnerability. I wrote the blog post.

>The author was able to develop an exploit by prompting an LLM with just the upstream commit

Yes, I was able to do this. I believe anyone watching iTerm2's commits would be able to do this too.

>but I still think this blog post raises the visibility of the vulnerability.

Yes, I wanted to raise the visibility of the vulnerability, and it works!

The author of iTerm2 initially didn’t consider it severe enough to warrant an immediate release, but they now seem to have reconsidered.

cryptbe··on Claude wrote a full FreeBSD remote kernel RCE with root shell
>Key point is that Claude did not find the bug it exploits.

It found the bug man. You didn't even read the advisory. It was credited to "Nicholas Carlini using Claude, Anthropic".

cryptbe··on Mad Bugs: Vim vs. Emacs vs. Claude
>But you would expect running "git status" or "git ls-files" in the unzipped directory to completely pwn your system? Probably not either.

That’s fair, but it would be pretty unusual for me to run Git commands in a directory I’m not actively working on. On the other hand, I open files from random folders all the time without really thinking about it, so that scenario feels much more realistic.

cryptbe··on Mad Bugs: Vim vs. Emacs vs. Claude
I think we can agree that Git is at least partly responsible for this issue, if not more.

That said, even being aware of that doesn’t necessarily help much in practice. When you’re using Emacs or Vim, you’re not really thinking about Git at all. You’re just opening and editing files. So it’s not obvious to most users why Git would be relevant in that context.

This is why I think editor maintainers should do more to protect their users. Even if the root cause sits elsewhere, users experience the risk at the point where they open files. From their perspective, the editor is the last line of defense, so it makes sense to add safeguards there.

cryptbe··on Mad Bugs: Vim vs. Emacs vs. Claude
Yes, likely. And git is not going to fix it. So isn't it fair to expect the editor maintainers to do something about it, to protect their users, no?
cryptbe··on Mad Bugs: Vim vs. Emacs vs. Claude
Disclosure: I didn’t discover the bugs, but helped write the blog post.

These issues are technically classified as local code execution (AV:L), but they go against a pretty strong user expectation: that opening a file should be safe. In reality, they can be triggered through very common workflows like downloading and opening files, which makes them feel a lot closer to some remote scenarios, even if they’re not strictly RCE.

At the end of the day, regardless of how you classify them, it’s worth being aware of the risks when opening untrusted files in editors like Vim or Emacs.

cryptbe··on Mad Bugs: Vim vs. Emacs vs. Claude
When I wget a tarball, unzip, and emacs a.txt inside, I don't expect that it'd execute arbitrary commands.

I think people should be aware of this risk, especially when it looks like it's not getting fixed.

Disclosure: I didn't find the bugs. I helped wrote the blog post.

cryptbe··on Dissecting LockBit v3 Ransomware
Thanks for sharing. I'm one of the co-authors of the blog post. Let me know if you have any questions!

tl;dr: We analyzed a LockBit v3 variant, and rediscovered a bug that allows us to decrypt some data without paying the ransom. We also found a design flaw that may cause permanent data loss. Nothing's earth-shattering, but it should be a fun read if you're into crypto and security!

cryptbe··on Google Alternatives
It really is turned off. Companies like Google get huge fines when they break their promise -- even accidentally.
cryptbe··on Google Alternatives
You can use Google Search and tell Google not to log your search history or use the data for advertising purposes. See my comment [1] for how to turn on these privacy controls.

[1] https://news.ycombinator.com/item?id=25383289

cryptbe··on Google Alternatives
Google provides decent security/privacy controls, see my comment on how to turn them on [1].

If you have any specific concerns, I'd love to learn more and see if there's anything I can help.

[1] https://news.ycombinator.com/item?id=25383289

cryptbe··on Google Alternatives
If you want to keep using Google services, here are some Google Alternatives Alternatives:

1/ Google Search, YouTube, Maps: visit https://myactivity.google.com/activitycontrols to turn on auto-deletion or turn off search history, location history or YouTube watch history. This page also allows you to turn off ads personalization. There are many security and privacy controls on https://myaccount.google.com/, turn them on however you see fit.

2/ Chrome: visit chrome://settings/syncSetup to turn off Chromesync, disallow Chrome sign-in, disable automcomplete searches and URLs, etc. You can also change the default search engine to something else, but see point 1/ if you want to use Google Search. Use Incognito mode more often.

3/ Gmail, Photos, Calendar, Drive, Docs: "we don’t use information in apps where you primarily store personal content—such as Gmail, Drive, Calendar and Photos—for advertising purposes, period." [1] In other words, Gmail, YouTube or Search ads are not targeted or personalized using your emails, photos, events, docs, etc.

Disclosure: I'm a Google's security engineer, advocating for and contributing to some of the aforementioned security/privacy controls.

[1] https://blog.google/technology/safety-security/keeping-priva...

cryptbe··on So you want to roll your own crypto?
>Crypto is hard because you don't get quick feedback on whether you are doing well.

Well said.

If you are to implement a sorting algorithm, you'll know immediately whether it works or is fast enough. Crypto doesn't provide this feedback. It's important to get help from others, if you can't tell yourself whether your code works.

cryptbe··on So you want to roll your own crypto?
I wrote this article to encourage people to study the field I love. If I wanted to tell people to back off, why would I bother providing advice, material and telling people to have fun?

>Those rules aren't easy to follow, but they are simple to know about.

If the rules were so simple, how come your library had a signature bypass vulnerability that you did NOT understand its root cause until I explained?

The root cause looks deceptively simple, until you take your time to understand the underlying math. I didn't fully understand it until a professor at MIT explained it to me. Maybe it's just that I'm stupid, but it is never simple to me.

>About not using your crypto until it's been vetted by professionals… How do you get those vaunted professionals to even look at your work?

You can't expect people to pay attention to your work until you earn it. Why would anyone bother reviewing a random library from a random dude? Frank of libsodium fame didn't start by writing a brand new library from scratch, but built it on top of NaCl. If he did that, nobody would take him seriously either.

>About CTF (Capture The Flag), and cryptopal challenges, my advice is: don't waste your time. The penetration testing approach to secure systems does not work. You whack a mole, two more appear. We need ways to prevent whole classes of errors, like proofs. For instance, tools like https://verifpal.com/ can be a great help when designing a protocol.

This was how my friends and I got started. Maybe you were right that it isn't worth it, but it helps get us to where we are, being paid to do security and crypto.

There are two approaches to learning: top down or bottom up.

The former is what you get at university. If you want to learn crypto, you have to learn abstract algebra, linear algebra, probability theory, complexity theory, and computer security. If you want to learn complexity theory, you want to learn automata theory, computability theory, and algorithms. If you want to learn computer security, you want to learn computer architecture, operating systems, networking, etc.

The top down approach is systematic, but it might not prepare you for the real world. For that, you need internships and CTFs. They are reality checks with a fast feedback loop, showing you very quickly which skill or knowledge you are lacking or need improvement. They are also fun.

cryptbe··on So you want to roll your own crypto?
>I of course agree with all of this, but as someone pretty much at the bottom of the food chain who just wants to encrypt some data, there's often no libraries that safely glue the primitives together in the way that I require.

>I hope this doesn't come off as entitled, but I feel like the best way to get people to stop rolling their own crypto is to provide more/better libraries.

Author here. I mentioned libsodium [1] and Tink [2]. We started Tink because we want to provide more/better libraries.

>Granted, this is getting better, for example NaCl's crypto_box[0] is awesome and very hard to misuse. But say you want forward secrecy now. chirp, tumbleweed.

It looks like you want to build an interactive protocol. I'm not sure if libsodium has a solution, but Tink doesn't. So far we've been focusing on encryption at rest. Can you tell me more about your use case?

[1] https://github.com/jedisct1/libsodium

[2] https://github.com/google/tink

cryptbe··on So you want to roll your own crypto?
I'll tell you next time we meet ;-)
cryptbe··on So you want to roll your own crypto?
For example, let's look at the IV.

Symmetric encryption algorithms usually need an input called the initialization vector (IV), but different algorithms have different requirements.

AES-CBC requires unpredictability, but AES-CTR (and AES-GCM) require uniqueness. Misunderstanding of these requirements have led to real world attacks, see for example BEAST or https://eprint.iacr.org/2016/475.pdf.

cryptbe··on So you want to roll your own crypto?
>Or was it that they were trying to use low level APIs in OpenSSL to create some higher-level cryptosystem they perhaps didn’t fully understand?

Yes. They wanted to encrypt some URL parameters with AES-ECB.

Page 1 of 4Next →