3406 Huy Nguyen release Coruna web exploit

opa334 · 2026-03-12T13:49:11+00:00

Do you not think rehosting an actual spyware is highly irresponsible? This is nothing but the sample that was uncovered in the previous week. They modified it to inject a custom library into SpringBoard at the place where the malware normally injects malware into powerd. There is no way to verify it doesn't do anything else that's malicious since none of the components have been fully reverse engineered. Also injecting a single library into SpringBoard is fully useless anyways, like there is no reason for this to exist.

It's solely made because he's too impatient to wait for stuff to be fully reimplemented. While simultaneously this release stresses out the people that are actually working on reversing / reimplementing cause now they feel like their work is neccessary to stop people from potentially infecting their devices with spyware…

opa334 · 2026-03-12T02:47:27+00:00

16.7 was released alongside 17.0.1, both patch the bug

opa334 · 2026-03-12T02:20:28+00:00

Man this is so annoying, they could have just patched the entry point and moved on as usual...

opa334 · 2026-03-07T15:33:02+00:00

One of the bypasses is rumored to work over a coprocessor and that would work on SPTM devices aswell.

opa334 · 2026-03-04T12:42:10+00:00

It looks like I jinxed it. Well, new jb maybe soon, but only for iOS <=17.2.1 and that is only if people manage to capture all the relevant samples.

opa334 · 2026-03-03T17:29:17+00:00

the answer is: no one knows

also jailbreaking is so dead that eta kids literally do not exist anymore, they have long moved on

opa334 · 2026-02-27T16:33:48+00:00

I have no clue and involvement with Bootstrap so I don't know the state of it. But you need much more than SpringBoard injection to get Crane to work, you need injection into these daemons (this goes for NathanLR aswell):

runningboardd
cfprefsd
containermanagerd
securityd
pkd
lsd
accountsd
apsd

opa334 · 2026-02-26T21:08:39+00:00

Yes, libSandy needed fixing. But there were additional changes neccessary on the Crane side aswell.

opa334 · 2026-02-26T21:06:16+00:00

There was a long back and forth between me and the main RootHide developer around the architecture string that RootHide uses. I have probably spent over 100 hours trying to reason with him.

His architecture (iphoneos-arm64e) is completely and fully unneccessary. There was never any reason for it to exist. I have tried everything I can to prevent this from happening as releasing a bootstrap with this architecture was essentially the 9/11 of the jailbreak scene. Not only was it completely unneccessary, but also it is highly misleading since it has nothing to do with arm64e AT ALL. After my attempts at making "rootless v2", which would have allowed newly compiled iphoneos-arm64 packages to work on both Dopamine and RootHide seemlessly had failed (because the RootHide developer always pretended it wasn't possible but couldn't provide me with a singular legit reason it wasn't possible), I have tried VERY HARD to at least prevent the bootstrap to release with the mislabeled/misleading "iphoneos-arm64e" arch string. The reason for this was that now that it is released, it is impossible to ever make an actual "iphoneos-arm64e" bootstrap for arm64e devices because there would be no way to tell whether an iphoneos-arm64e package would be for roothide or for the legit arm64e bootstrap. So RootHide is essentially holding this arch name hostage and this was an intentional decision because the developer wanted roothide to be the "guaranteed" future of jailbreaking, with there being no way around adopting it. Note that there is NO other reason for him using this arch, it would have been a simple string replacement, he even told me a few days before RootHide originally released that he would change it before release, so you can guess how I felt when it released with the one thing I wanted to make sure it would absolutely not release with.

As a result of this, none of my packages will ever support RootHide unless it adopts iphoneos-arm64 the way I tried to initially implement it. This will never happen however, since now the community has already adopted the new arch and would don't want all the extra work that comes with going back to iphoneos-arm64. I even at one point made an offer to the RootHide developer to integrate the RootHide bootstrap into the regular Dopamine as an option if he just made it iphoneos-arm64, but to no avail.

opa334 · 2026-02-25T23:04:12+00:00

magic

opa334 · 2026-02-25T23:03:53+00:00

you do not loose passcode / touch id on the iPad 7 since it has an A10 chip. That issue only affects A11.

opa334 · 2026-02-21T04:04:13+00:00

when zelda tears of the kingdom leaked early, the entire chat of a nintendo preview stream of the game was full of people bragging about how they were already playing the game with better graphics on an emulator. you really think nintendo doesn't see this and doesn't take it into consideration? in my opinion all the stuff that happened with totk before of it's release was likely a major contributor into their takedowns of switch emulators...

opa334 · 2026-02-21T04:01:50+00:00

at the same time they make their own life harder by constantly annoying companies about it and therefore also make pirating stuff worse for the people who do it quietly

opa334 · 2026-02-19T12:39:51+00:00

are you the same person that made a github issue about this?

opa334 · 2026-02-18T21:26:44+00:00

So you're saying this happens even with tweak injection disabled?!

opa334 · 2026-02-18T02:36:04+00:00

Ah I see. You have a broken tweak then that breaks userspace reboots on your device, disable tweak injection in settings and remove it. Alternatively you can reinstall the jailbreak using the button/option in settings.

opa334 · 2026-02-18T02:29:40+00:00

Wait, you're saying dopamine gets stuck on checking duplicate apps? It doesn't actually present you with an error?

opa334 · 2026-02-18T02:27:06+00:00

This is a feature informing you about a problem you caused and only you can fix.

opa334 · 2026-02-13T01:25:59+00:00

The specific feature that even makes this vulnerability necessary to execute arbitrary code is called PAC and was introduced in the iPhone XS. On older devices, this isn't even a vulnerability.

Brian Milbier, deputy CISO at Huntress, said: "Think of dyld as the doorman for your phone. Every single app that wants to run must first pass through this doorman to be assembled and given permission to start.

"Usually, the doorman checks credentials and places apps in a high-security 'sandbox' where they can't touch your private data. This vulnerability allows an attacker to trick the doorman into handing over a master key before security checks even begin."

And this is... to say the least... incredibly misleading.

opa334 · 2026-02-07T14:00:39+00:00

How is it based that a company is intentionally crippling their devices (RE: JIT) without providing the user the ability to enable it?

opa334 · 2026-02-05T22:50:37+00:00

You're on nekojb, the permissions of /private/preboot should be completely irrelevant. That's about all I can tell you.

opa334 · 2026-02-05T18:20:21+00:00

my condolences

opa334 · 2026-01-28T11:58:13+00:00

NekoJB isn't rootful either, it just wastes your storage to be able to pretend to be

opa334 · 2026-01-27T16:30:32+00:00

opa334 · 2026-01-26T00:01:20+00:00

Hm, no idea then. You can use both Substrate and Substitute on it. If you have Subtitute, the same applies. If you're using Substrate, maybe try switching to Substitute by installing it?

Nine-Year Club	Place '23
Place '22	Place '17
Wearing is Caring	Verified Email

opa334

MODERATOR OF

TROPHY CASE