Is it possible to replace doubleh3lix with sockh3lix

[LuckyHeroes]

Hi JakeBlair420, would it be possible to replace meridian and doubleH3lix with sockH3lix, it jailbreaks 64bit devices in under a second and its more stable.

I had tried to edit the makefile to point to sockHelix to produce sockHelix.a but it hasnt got the arguments to compile c source code. I tried for many hours to create the necessary arguments but ultimately failed.

Xcode can sucessfully build the sockHelix project to an IPA, so i can assume i have all dependancies, i copied the sockhelix.a file xcode had made into your dep folder and changed the makefile to look for that file but ultimately the webpage just failed. I realised doublehelix has "#inDef HEADLESS" code to build without a GUI. With my limited c knowledge i wouldnt know if im putting the headless code it the correct part.

Ive been trying to research what debugging tools i can use to help me understand if the patch is loading sockH3lix and if it is where its failing.

Maybe a Developer thats interested in picking up this, it would be greatly appreciated.

[Siguza]

Well I have no idea what changes sockH3lix made. I only see that it was forked from tihmstar and not from me, so it's not gonna have any of the headless stuff or other fixes I made. Conceptually, the exploit is in this repo, in glue/src/v0rtex.m, and the only two imports from doubleH3lix are runLaunchDaemons and cb, both from glue/dep/doubleH3lix/doubleH3lix/jailbreak.mm.

[LuckyHeroes]

Well I have no idea what changes sockH3lix made. I only see that it was forked from tihmstar and not from me, so it's not gonna have any of the headless stuff or other fixes I made. Conceptually, the exploit is in this repo, in glue/src/v0rtex.m, and the only two imports from doubleH3lix are runLaunchDaemons and cb, both from glue/dep/doubleH3lix/doubleH3lix/jailbreak.mm.

Their readme states

v0rtex -> sock port with higher success rate.

From jakeajames repo Jakeajames sock_port

Thanks for the info, I had dug through this repo and found glue/src/v0rtex.m, I assumed it was part of the browser exploit, not the jailbreak. I'm going to dig though those imports and see if I can understand it further.

The idea I had was totallynotspyware to achieve the browser exploit then subsequently jailbreak in less than a second while being ~100% stable and as a bonus no resigning the jailbreak IPA. (For the legacy jailbreak community)

[Siguza]

I had a brief look at sockH3lix now, but they rearranged just about the entire code from doubleH3lix and made many style changes, so it's gonna be extremely hard to diff this. I do see that they changed a bunch of post-exploitation things, but I have no idea to what end.

You can try and replace just the exploit, but before you even go that far, I would try and verify that all the APIs needed are indeed reachable from WebContent.

[LuckyHeroes]

I had a brief look at sockH3lix now, but they rearranged just about the entire code from doubleH3lix and made many style changes, so it's gonna be extremely hard to diff this. I do see that they changed a bunch of post-exploitation things, but I have no idea to what end.

You can try and replace just the exploit, but before you even go that far, I would try and verify that all the APIs needed are indeed reachable from WebContent.

I had made an incorrect assumption that after the WebKit exploit ran, a headless binary of doubleH3lix was launched to complete the jailbreaking stage which isnt the case.

i think i need to replace the v0rtex exploit files in /glue/src with sockh3lix sock_port_exploit, call this from glue/src/main.mm and also include and compile sockh3lix into .a library so i can then run sockH3lix implementation of post exploitation.

EDIT: Im trying to figure out how to check if the API's are reachable from webcontent, ill post back once ive figured out a solution and the answer

[Siguza]

You could just replace the code in v0rtex.m to make a bunch of API calls and log the results.

Alternatively, you could try and start in unjailbroken state, sideload an app that exploits psychicpaper to be unsandboxed, and then manually calls sandbox_init("com.apple.WebKit.WebContent", SANDBOX_NAMED, ...) to enter the WebContent sandbox, then perform your checks from there.

[LuckyHeroes]

You could just replace the code in v0rtex.m to make a bunch of API calls and log the results.

Alternatively, you could try and start in unjailbroken state, sideload an app that exploits psychicpaper to be unsandboxed, and then manually calls sandbox_init("com.apple.WebKit.WebContent", SANDBOX_NAMED, ...) to enter the WebContent sandbox, then perform your checks from there.

Thanks for the great write-up, certainly has challenged me to dive deeper down the rabbit hole. Reading your article make me realise i dont have the understanding (yet?). i thought i could view WebKit crash logs by tailing ondeviceconsole

Checklist:

1. Understand how to setup a debug environment (jailed/jailbroken) ~attached Xcode to device, com.apple.WebKit.WebContent crash logs show. ~TODO: debugging from psychicpaper! ^ Enter WebConent Sandox with psychicpaper - Use a Logging Framework to output logs?
2. Call the necessary APIs from sock_port_exploit.c in v0rtex.m ~ TotallyNotSpyware build complete with extra calls to API's from sock_port_exploit, running local webserver and testing on device.
3. Determine if those APIs are reachable ~ TotallyNotSpyware completes the jailbreaking process with (sockH3lix sock_port_exploit) API's loaded in src/v0rtex.m ~ How to determine that an API has been loaded with NSLog (Xcode) or logging framework API (step 1),
4. Replace the exploit

oh i see now

default 12:34:32.542905 +0100 com.apple.WebKit.WebContent TIC TCP Conn Destroyed [1:0x100240c30] default 12:34:42.527510 +0100 com.apple.WebKit.WebContent we out here default 12:34:42.527966 +0100 com.apple.WebKit.WebContent v1.17 default 12:34:42.528996 +0100 com.apple.WebKit.WebContent HELLOOOOOOOO FROM V0rTeX!!!! !!!! !!!! !!!!! k stop now

[LuckyHeroes]

xcode wouldnt allow me to attach the debugger to com.apple.WebKit.WebContent, i read ages ago you can inject the debugger into an app (for disassembly/RE with IDA), i wonder if it possible to do that for a system app (while jailbroken)

[Siguza]

It can certainly be done in one way or another, but a jailbroken environment is not a good testing ground for exploits because the sandbox is often torn down either partially or entirely.

[LuckyHeroes]

It can certainly be done in one way or another, but a jailbroken environment is not a good testing ground for exploits because the sandbox is often torn down either partially or entirely.

Hi siguza thanks for your advise, im making progress, albeit slowly.. i cant yet figure out how to perform debugging within webcontent sandbox so im going forward blind for the moment.

so the route im taking for now is just replacing the exploit, sockH3lix has made lots of changes even to thimstar's offsetfinder64 as you previously observed, which mean more compiling yay!

EDIT:

Caveat:
There is a hand-written assembly routine called genesis, which is used to link the Mach-O on JIT memory` before it can be used.

does this mean that only the doubleh3lix binary works?

[Siguza]

genesis was originally not open source, but I did push it in 2021: glue/dep/jit/genesis.S

[LuckyHeroes]

genesis was originally not open source, but I did push it in 2021: glue/dep/jit/genesis.S

i think ive found a guide that uses PsychicPaper for debugging, im gunna set it up now :) !! chain3

[LuckyHeroes]

genesis was originally not open source, but I did push it in 2021: glue/dep/jit/genesis.S

Hi Siguza, im getting a sandbox violation after replacing the exploit (just the source code).

I've removed all traces of v0rtex code in /glue/src and in main.mm i've removed everything apart from main(). Inside that function i added a simple NSLog, the console outputs it as expected.

but then ive copied over sock_port_exploit and its dependencies, it compiles fine but the console shows a sandbox violation without even calling a single function or including anything from the new exploit.

default 21:53:32.418191 +0100 kernel SandboxViolation: com.apple.WebKit(239) deny(1) mach-register com.apple.WebKit.WebContent.gsEvents

either some function is being called other than main() in main.mm or the compiler/payload/iOS knows ahead of time what api's are needed. I need to research further.

am i wrong in thinking that main.mm main() is the only function being called on launch.

EDIT:

i ran it again while jailbroken and now ive received a crash default 22:29:51.681381 +0100 ReportCrash Notice: This report is abbreviated for syslog inclusion because it could not be saved to disk. Symbolication may be possible by manually cleaning up and including the Binary Image section of a full report from this same device -- good luck! default 22:29:51.682269 +0100 ReportCrash Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Triggered by Thread: 0 default 22:29:51.683206 +0100 ReportCrash Application Specific Information: abort() called

default 22:29:51.708776 +0100 ReportCrash Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libsystem_kernel.dylib 0x000000018bce1014 0x18bcc2000 + 126996 1 libsystem_pthread.dylib 0x000000018bdab264 0x18bda6000 + 21092 2 libsystem_c.dylib 0x000000018bc559c4 0x18bbf4000 + 399812 3 GraphicsServices 0x000000018e62ccd0 0x18e621000 + 48336 4 GraphicsServices 0x000000018e62bbe8 0x18e621000 + 44008 5 UIKit 0x0000000193096804 0x192e02000 + 2705412 6 UIKit 0x0000000192e76c68 0x192e02000 + 478312 7 trebuchetmemes 0x00000003ef69bef8 0x3ef694000 + 32504 8 trebuchetmemes 0x00000003ef69bca4 0x3ef694000 + 31908 9 ??? 0x000000018c02e2a8 0 + 6643966632 10 ??? 0xde1bc0dede1ac0de 0 + -2442146309476794146 default 22:29:51.709316 +0100 ReportCrash Thread 1: 0 libsystem_kernel.dylib 0x000000018bce1a88 0x18bcc2000 + 129672 1 libsystem_pthread.dylib 0x000000018bda6fd0 0x18bda6000 + 4048 2 libsystem_pthread.dylib 0x000000018bda6cac 0x18bda6000 + 3244 default 22:29:51.710163 +0100 ReportCrash Thread 2: 0 libsystem_kernel.dylib 0x000000018bce1a88 0x18bcc2000 + 129672 1 libsystem_pthread.dylib 0x000000018bda71a4 0x18bda6000 + 4516 2 libsystem_pthread.dylib 0x000000018bda6cac 0x18bda6000 + 3244 default 22:29:51.710252 +0100 ReportCrash Thread 3: 0 libsystem_pthread.dylib 0x000000018bda6ca8 0x18bda6000 + 3240 default 22:29:51.710832 +0100 ReportCrash Thread 4 name: com.apple.uikit.eventfetch-thread Thread 4: 0 libsystem_kernel.dylib 0x000000018bcc3224 0x18bcc2000 + 4644 1 libsystem_kernel.dylib 0x000000018bcc309c 0x18bcc2000 + 4252 2 CoreFoundation 0x000000018cc94e90 0x18cbba000 + 896656 3 CoreFoundation 0x000000018cc92ae4 0x18cbba000 + 887524 4 CoreFoundation 0x000000018cbc2da4 0x18cbba000 + 36260 5 Foundation 0x000000018d6dddb4 0x18d6d1000 + 52660 6 Foundation 0x000000018d6feb84 0x18d6d1000 + 187268 7 UIKit 0x0000000193800830 0x192e02000 + 10479664 8 Foundation 0x000000018d7db318 0x18d6d1000 + 1090328 9 libsystem_pthread.dylib 0x000000018bda968c 0x18bda6000 + 13964 10 libsystem_pthread.dylib 0x000000018bda959c 0x18bda6000 + 13724 11 libsystem_pthread.dylib 0x000000018bda6cb4 0x18bda6000 + 3252 default 22:29:51.711101 +0100 ReportCrash Thread 0 crashed with ARM Thread State (64-bit): x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x000000000000000c x4: 0x000000000000000b x5: 0x0000000000000018 x6: 0x0000000000000000 x7: 0x0000000000000d60 x8: 0x0000000008000000 x9: 0x0000000004000000 x10: 0x0000000000000000 x11: 0x0000000000000fff x12: 0x0000000100397000 x13: 0x0000000000004a26 x14: 0x0000000040044605 x15: 0x0000000000004a26 x16: 0x0000000000000148 x17: 0x000000018cbe1c10 x18: 0x0000000000000000 x19: 0x0000000000000006 x20: 0x00000001b2533b40 x21: 0x000000000000044c x22: 0x00000001b25332b4 x23: 0x00000001b25332b0 x24: 0x00000001b258d9c0 x25: 0x000000010035d630 x26: 0x000000019394f229 x27: 0x0000000100135130 x28: 0x0000000100135638 fp: 0x000000011384b060 lr: 0x000000018bdab264 sp: 0x000000011384b040 pc: 0x000000018bce1014 cpsr: 0x00000000