#development
1 messages Ā· Page 125 of 1
this specific thing seems like it doesn't work on 16.5.1
like it causes GFX panics apparently
so maybe <=A14 work on 16.5.1
Ah, weird, sometimes I'd get the occasional GFX panic, but it usually wouldn't happen
well once you get the ipa, appextensions should just be in the payload as PackageName/PlugIns/extension.appex
with an info.plist and a nib or other files
hence the name, extensions have to be built with a main app binary as well
i thought they were included but the extension won't show up in safari so i was confused
it is included.. dunno why it isnt showing up š¦
is this a trollstore limitation?
these show up for like a single frame
openyoutube and unagent
unagent is what i am trying to sideload
openyoutube is just another app extension im guessing is sideloaded with youtube++
does trollstore not support app extensions
i see it does not as they are system apps
interesting
do they work until reboot or do they not work
opa made a comment on this reddit saying they dont work
lol
not really surprised at that
yes, binaries in paths other than /var/containers/Bundle/ will not be sandboxed by default (such as preboot), but the kernel will refuse to execute binaries without unsandbox entitlements in /var/ (including /var/containers/), this is my test result on ios15. but I am not sure what the policy is for /Applications/ in rootfs since we cannot modify it on ios15.
do they not work because they aren't signed with the main binary or because of a system app incompatibility
if there's multiple binaries, ts should sign them all
i'd assume it's because of the system app registration
and due to the system policy of the kernel, the platform binary cannot spawn the binary in /var/, so the daemons/apps in /var/ will not be able to launch. this can be solved by re-signing the system binary.
and another interesting thing is that if the app is registered in /var/, then launchd will use xpcproxy to launch the app.
go figure
lol
seems like this app cant even change my user agent anyways so i guess it didnt matter anyways lol
anyone know if there is a tweak to change user agent on safari :p
on ios 16
possible for extensions to do this
it is i can't find any free one though
thats what i just built
doesn't work and seems to not work for anyone else in the app store reviews
not sure why though
probably something to do with ios 16
then you're probably limited to just browsermask
orion would be a much simpler solution i just got hyper fixated on using safari lol
also does anyone in here know if there is a vnc server that works on newer ios? veency exists but i'd be astounded if it still works after 6 years of no commits
screendump
but it's been patched up like 3 times over since the ios 14 release
a viable alternative is something like https://er.run/blackhole but that's paid with a trial
interesting
i use that UA switcher it absolutely works
what ios are u on wtf
17.4
i mean the commits are only from a few months ago
weird
well then it's working
what a dick move to give it a one star
the agent string isn't the only way to detect a device like they say
i was using a user agent checker and it wasn't showing any difference but ill try again
nor is it reliable
yeah it doesn't change for me :/
definitely works
a symlink to /usr/lib/TweakInject
you didnāt restart safariā¦
i did
did you even enable the extension?
then you definitely set it up wrong
ok
the message before it was fixed was jbroot/MobileSubstrate/DynamicLibraries, that's what i meant by "Library missing"
š I didn't modify this part, it should be consistent with the rootless ellekit. I just change /var/jb path to jbroot
got it
and ellekit builds off libhooker which is why we still have tweakinject 
wat
isn't ellekit fully compatible with libhooker functions
same with substrate and substitute
well i mean that you can quite literally use LHHookFunctions etc with ellekit
and the /usr/lib/TweakInject folder was just what libhooker used then symlinked for compat reasons
reboot fixed the app
unless youāre gonna roll this weed for me
its 4:30 brother u got bigger enemies than me
thatās later than usual
go to rehab
Proc soc on top
nebula do u know if ur tweak ding has the ability to use mute module in control center while the mute switch has its own function šš
currently if its set to force either way the mute module cant change mute status
@sonic totem ok so your idea did something, because now when panicking, instead of AMCC PLANE1 or AMCC PLANE2 it's always AMCC PLANE0

Very interesting
The writeback is still happening though
Presumably
AMCC = Apple Memory Cache Controller
yeah
seems that way, yes
even though I'm constantly reading it in a while true loop in a seperate thread
perhaps at some interval it's forcibly written back?
although interestingly
it says the panicked task is my task
Actually it would normally say that
yeah
maybe I can somehow freeze the AMCC
how much time passes between the write and the panic
or is it instant?
pretty much instant yeah
it would not
a standardized API to get the root path
roothide has it's own thing
I will get to that really soon
dma_perform(^{
uint64_t thing = 0xfffffff00832be94 + get_kernel_slide();
dma_writevirt32_premapped(thing, (uint32_t *)&mov_x2_afce);
dma_writevirt32_premapped(thing+4, (uint32_t *)&paciza_x2);
dma_writevirt32_premapped(thing+8, (uint32_t *)&str_x2_x0);
dma_writevirt32_premapped(thing+12, (uint32_t *)&ret);
});
uuid_generate_time(ourbuf);
ksigned_afce = (void *)kread64_kfd((uint64_t)ourbuf);
NSLog(@"Signed afce: %p",ksigned_afce);
pthread_cancel(posixThreadID);
asm("IC IALLU");
(I overwrite uuid_generate_time)
the IC IALLU is to invalidate all the instruction caches
although I'm not even sure whether or not that instruction works in userspace yet
can't think of anything rn
Rootless V2 will likely have a "libroot" that jailbreaks ship
then there will be a .a that people can link (This is very small and only handles finding libroot and dlopening it) and preprocessor macros to convert paths
and this will be integrated into theos
I have no clue how roothide does anything currently
void *preventwritebackthread(void *notusing) {
NSLog(@"Entered the writeback prevention thread!");
uint64_t _uuid_generate_time_addr = 0xfffffff00832be94 + get_kernel_slide();
uint64_t start = 0xfffffff00832be94;
uint64_t end = 0xfffffff00832c018; // Also static for testing purposes.
uint64_t size = end - start;
NSLog(@"Size: %d",size);
sleep(1);
void *gotome = malloc(size);
bool hasalreadyprinted = false;
while(true) {
kreadbuf_kfd(_uuid_generate_time_addr, gotome, size);
}
}
wait
I forgot to remove a sleep
I bet that's the issue lmfao
@willow lance save us
lmao what
Iāve interested in this bug for a several years and I want to find it!
Because of this bug is faster than any other bugs
nvm š
for the record, this is mostly an experiment
I just want to see if I can sign a pointer in the kernel lmao
if I can then kcall
if not then
oh well
the problem is we don't know if there is any way to revert the writes without panicing
so even if you could get kcall it wouldn't be for very long š
well invalidating the cache should do that
invalidating the cache marks everything as "invalid" which means they can't be written back, so the cache gets reset without writing to the DRAM
(or read from)
(or written to)
technically roothide and rootless (even after rootless v2 is implemented) will be different things in regards to what paths they use to my knowledge
roothide will still be it's own strap
and AARCH64 conventiently has the instruction IC IALLU which invalidates all instruction caches
it's still a separate thing to rootless even after rootless v2
which (should) theoretically make it so it doesn't get written back and the cache is reset
RootHide and rootless v2 are not the same things whatsoever
I think you have a misunderstanding of what roothide is
Dopamine 2.0 does not do anything to hide the jailbreak on it's own
That will only be used by external packages
The bootstrap itself has it's own idea of what the root path is
yes
Yeah but after the arch merge is done I think it should be an option
how did y'all manage to get it to last for anytime at all?
I even offered tuan to integrate it as an option into Dopamine later
I can't get it to do anything lmao
no one has gotten it to last except boris
ah I see
wait is a rootless v2 strap able to load rootless v1 packages?
then what are you doing? I'm confused.
or do we need to rebuild all our packages?
roothide no
rootless yes
on traditional rootless setups yes, roothide no
yeah I haven't done roothide
this time I got a kernel data abort, what?
(nor do I care too)
thats neat then
won't get some thing of people hacling packages to work on the new format and getting bugs
I'm assuming rootless v2 packages don't work on a rootless v1 strap (aka current dopamine/pailra1n)
Real
anyways I should probably just suck it up and just figure out why the is_table is empty on daemons lol
RH is the nuclear option for when nothing else works, so I guess it would be nice to have as an option
relative humidity?
He fell off in other ways anyway 
I'm just kidding
We gonna be voting next year smh
Better start researching this stuff
and youāre gonna vote Tory ofc
fucking poshie
if this is the case, do we need to add smth to the Depends to prevent v2 packages from being installed on an old strap?
looks good
ugh we're making another jb standard?
Does that mean I have to adjust my (in progress) jb?
it will only require minimal changes
alright
i hope this is the last time it changes though, the amount of fragmentation is getting a little annoying
should probably delete that message before the whitenames see it...
so iphoneos-arm64 roothide will still be an option?
and it will be backwards compatible, rootless v2 packages will still work on rootless v1
oh alright cool
(just not on roothide)
oh neat
Excuse me
so its backwards compatible both ways
How am I posh
Posh
uhm
I appear to be getting a kernel data abort near the address I'm writing to for some reason
isn't that a good sign?
no
no
RH has had its own fork of theos, that's why the adaption rate isn't that great
Overwrite stuff with 0x41 and see if it appears in panic logs 
I will PR rootless v2 into theos when it's done
0xfffffff0118c7e94 this is where I'm writing to
0xfffffff0112db548: this is where I'm getting the kernel data abort
idk if they're related
sorta yeah
for non-bootstrap packages yes
I really just hope this is the last time this happens, it's getting annoying with all the arch changes, hard to keep up :P
Still like 0x600000 away
So Iām not sure
but wouldn't it be like a kernel instruction abort, if it was something related to what I was doing?
Yes āundefined kernel instructionā I believe is the panic log youāre looking for
yeah
If you overwrite with a bad instr
I think it will be the same
ideally people that already updated for rootless will only need to recompile
@tepid olive I canāt remember for certain but I feel like kernel data abort can happen with kfd
yeah that's probably the issue lol
If you can reliably trigger it though then itās probably not
yeah it happens everytime
I wonder if it's because I write and constantly read at the same time?
maybe it doesn't like that
yeah
Then I doubt thatās the issue
should I try just overwriting stuff with 41 to see what happens lol
Agreed
Or like some magic value
Also Iām surprised Iāve never seen you around, you seem to know your stuff š
How long have you been working with iOS?

but I have background in Nintendo Switch RE
I need to step up my game
Ah i see
Was gonna say
Learning all that in two weeks would be a challenge
yes it would've been, thankfully I already had AARCH64 ASM memorized
I've also read like alot of iOS security research writeups in the past 2 weeks
Some of the *OS internals books, the Fugu15 writeup, coolstar's jailbreak presentation, the PACMAN writeup
uh
some other stuff
a bunch of Project Zero writeups
Thereās a KTRR one
Yup
Siguza has a repo for this
oh yeah and I've also read through some XNU source and the KTRW source as well as Fugu15 source, Fugu14 source and async_wake source, taurine source, undecimus source
Wow nice work
Learning a lot very quickly then
and I think voucher_swap source?
I really need to get into kernel exploitation
PAC is my worst enemy
Even just messing around with kfd + PPLRW
that's the big thing I've gathered so far lmao
PAC you only need if you want to kcall
I have been feeling like that aswell
But I don't have the time for it lol
Yeah but you already know what youāre doing :P
eh, the only kcall I need ever is kalloc, which you can easily do by abusing some random kernel structures/ user clients
I need to familiarise myself with how stable r/w and PPLRW works
like OOL mach messages
guys I know how to uninstall ios
Yea agreed
Unless you need kcall for a subsequent PPL bypass
I mean in my first week of doing this, I achieved iOS 16 arm64e trustcache injection
thank ye
Did you take a page out of the existing Dopamine source?
eh actually more DNAJB
actually KpwnZ has been working with me alot
There were some trustcache offset changes between 15/16 iirc
I see
yeah, I also had to ask them how to patchfind the pmap_image4_trust_caches offset
because I searched for days
that doesn't even exist anymore
Apparently I was looking in the right place, just being dumb and accidentally ruling it out
yes I know I just call it that
Made what?
because that's what it used to be called
KPF
Ah very nice

it probably is because I read and write at the same time
except there's no other time to start the thread
I would need to time it to perfectly line up when I finish writing
wait what
I get kernel data abort even when I don't do them at the same time???
oh
wait
it doesn't seem to like me precalculating the ECC hashes
AlfieJB eta s0n
@marble perch so would it be fair to say/confirm that RootHide will transition to rootless v2 based on what has been said here or is that still not finalized and could change depending on how things go?
nevermind???
lemme try just jumping to this address and seeing what's there
how can i get flex to select something that it cant?
i tried looking through headers but i cant find what i need
it's literally just a random place in memory lmao
to both you and @unique wedge: would I be in the clear to announce this now that this is seemingly definitely happening
that's the goal
You click on it even if it donāt select it then you open views and find it there
Click full hierarchy ?
its like it ignores the status bar stuff entirely
what the fuck is this decompilation lmao
i did, not there
is it possible to diff headers?
Idrk then š¤·āāļø
i just wanna remove these damn page dots
get the header from a previous version, get the header from a current version, and then use a text diff online tool
Oh god I have a lot to read !
@radiant idol when do you sleep ?
or just use the linux command diff
Arenāt you in GMT+4
EST
Ohhh
Right now I'm also not sure of all the things that uh PPL protects
I know it protects page tables
If the PPL bypass still hasn't been tested fully on 16.5.1 <=A14, and public help with testing is still available, @ember cypress has offered to test with their iPhone 12PM on 16.5.1. I'm not familiar with the current state of testing, so apologies if this isn't necessary
I know it protects the trust cache
why does flex not work well on ipads
I know it protects entitlements and certain task properties
what?
Page Protection Layer

Maybe this will help you
@marble perch to avoid miscommunication, do you want to summarize everything to tuancc
what's going on? š¤ļø
@unique wedge this looks like a good tl;dr of what the plan is though
rootless v2?
opa hasn't released it yet, and I don't know much about the specifics of it
what if we had a rootless v2 thread?
Might be nice to have a spot for discussion about it, especially if its still being worked on
what does the mean "using rootless v2"?
using iphoneos-arm64 with the definable root path
rootless v2 is just about the tweak package, it has nothing to do with bootstrap..
it does though because RootHide currently uses iphoneos-arm64e
weāre using iphoneos-arm64e on 17, no?
wat
since basically no 17.x arm64 devices
sounded like that plan was dropped/postponed last I heard
but rootless v2 has nothing to do with arch, right?
this stupid arch naming scheme is such a pain
also I donāt even think thatās supposed to be public 
itās in proc discord so
in todo iirc
pretty sure thatās private
help, it just randomly started doing this
anyways w/e forget i said anything
why is there another debate about arch? some people suggest using arch with a suffix, and some want to switch to iphoneos-arm64, but this all depends on how to do it after rootless v2 is released
donāt worry about what i was talking about, it was quickly disregarded among the team when it was first brought up
@radiant idol ?
sort of, but either way the goal is to move RootHide away from iphoneos-arm64e, and if itās possible to use rootless v2 to move to iphoneos-arm64 then thatās ideal
your lib isnt connected properly, i dont have time to diagnose this right now
but the implementation of rootless v2 has not been finalized yet, how can I evaluate what to do next?
rh will definitely provide rootless v2 compatibility, just like it is currently compatible with most rootless v1 packages, but in what way it will be implemented, I can only figure it out after the implementation of rootless v2 is finalized.
I've already read this 
Read it again
I have a question, assuming rh and rootless v2 share iphoneos-arm64, if rootless v2 switches to iphoneos-arm64e in the future ios version, should rh be also compatible with iphoneos-arm64e packages ?
how many times are we gonna change the arch bruh
not all rootless devices are arm64e
moving forward everything should be iphoneos-arm64
iPadās, Apple TVās, a HomePod
but hayden said it might be possible to switch to iphoneos-arm64e in a future ios version
Iāve looked at that and thatās likely being scrapped due to cross arch issues
I'm confused now
agree
roothide already burned the iphoneos-arm64e arch, trying to reuse it would be a pain
idk im not the one in charge of this
it's burned, idk why people would think it isnt
presumably something along the lines of itās still early on and most tweaks can just move to iphoneos-arm64 and ditch their legacy RootHide counterparts
I just dont get why some people are so insistent on changing core aspects of jailbreaking
how many times can we change the arch
I mean arch would make sense if it was actually used properly
but it hasnāt since like iPhoneOS 3 or iOS 7 depending on how you look at it
why did they even do that anyways
thats a whole another story
thatās still partially a mystery today
arm64e is just apple's name for the v8.3 revision of armv8 lmfao
(more like itās a mess but whatever)
why make it a different arch
look at the theos server
and
from:nightwinddev iphoneos-arm64e
grab a cup of popcorn
and read
I've got better things to do
rip
like switching disassemblers
to cutter
because ghidra sucks because it's written in Java and Java sucks
nope, wrong
but java doesn't suck
never touched c# really
java isn't as slow as people think it is
Self promo
it has a bad binding system but it does exist
C# has a good one
although I guess you could make the argument that Java is more cross platform
java is fine
but nowadays with .NET Core, C# is just as cross platform
one nice thing about cutter though is that it automatically identifies classes
and their names somehow
Iām confused what you mean by this
yes i don't want to be in rush now
It depends on the implementation of rootless v2, if it provides less compatibility, or full compatibility is difficult, then using a separate arch may be a better choice
I guess my point is to suggest that we should make an announcement that that is the plan in order to potentially reduce the number of developers who are hardcore adopting iphoneos-arm64e as if it is the definitive future when itās probably not
the goal of rootless v2 is that it will be fully compatible regardless of root path with all packages that are updated for rootless v2
so what should they do now, or wait and do nothing
basically as long as the package is updated to support rootless v2, it should technologically be able to support current traditional rootless and updated RootHide
I mean the rootless v2 compatibility with rh, they are not just differences in root paths
honestly imo right now they should work on packages that support iphoneos-arm64 and iphoneos-arm64e
we know RootHide is more than just what rootless v2 will offer
the point is that the goal is that RootHide can use rootless v2 and support all rootless v2 packages
there are some differences in rh, 1) path expression in the configuration file, 2) bootstrap's access to rootfs 3) the way tweak and bootstrap interact with paths 4) PATH environment variable 5) jailbreak root path that is re-randomized every time 6) tweak the persistent storage of paths
so I said that only after the implementation of rootless v2 is finalized, then we can evaluate how to make it compatible with rh
this does not depend on rh, but on the implementation of rootless v2 and the degree of developer support for rootless v2. you must know that not every developer will use theos, so I believe that rh will still have to consider the compatible with rootless v1 for a long time
you would love symlinks
what does symlinks have to do with any of this
this isn't true
Dopamine 2.0 will support existing rootless packages
oh bad, there is another problem there, dependencies package.
for example, now I have ported libsandy/preferenceloader to rh, and some tweaks that have been updated for rh already work correctly based on them. so what should we do when rh is compatible with rootless v2?
hey @naive kraken hope you don't mind me asking a question, but why in Dopamine, do you launch jailbreakd using XPC messages to launchd instead of launchctl? Is there a specific reason, or is it just personal preference
launchctl doesn't launch in this state
codesigning is still active
besides y'all are living in the past
Huh, I wonder why my jailbreakd loads fine with launchctl lmao
before jailbreakd is started, the signature of the bootstrap binary has not been loaded into the trustcache, so launchctl is not available
jailbreakd??? what do you mean
oh I just have a seperate launchctl binary embedded into my bundle that gets signed with the main binary with trollstore lol
well actually, mine's called Jupiter, but
you get the point
iirc you're switching to launchd right?
#development message did i misunderstand 
jailbreak app->load basebin into trustcache->start jailbreakd using xpc->load bootstrap binaries into trustcache in jailbreakd->launchctl available now
or is bootstrap here not the procursus bootstrap but some other thing
yeah that's what I do pretty much lmao
Except I'm still trying to figure out why my daemons ipc_space is empty, like, are its mach ports managed by launchd or something?
(I have read some things that say that, but I could just be misunderstanding)
all it's referring to is that you won't need to use /var/jb - /var/jb is still what will likely be used unless there's a need to change it for whatever reason
mines called launchd
ah I see
that's a good idea, I was only doing it this way to keep with the standard dopamine set lol
random question: does dnajt use jailbreakd or launchd
jbd
I should probably use launchd though
šµāš« this is too confusing and I haven't kept up with it
welcome to my life
I assume you insert a hook dylib into trustcache, use opainject to inject into launchd, and do stuff from there, right?
anything to do with rootless v2/roothide/archs is the hardest thing to follow in existence
Also I don't think I'm supposed to be compiling jbd with theos
not that that's related
Like I mean what are the benefits of using launchd over jbd?
launchd is pid 1 and the "parent" of userland in iOS
sandbox
this is true.
jbd is no longer feasible in iOS 16
Yeah I may have noticed that
too many processes can't contact it
standards are a foreign concept at this point
but WebContent cannot even contact launchd on iOS 16 -_-
is it known yet what webcontent can contact
nothing would be my guess
WebContent can't contact anything, isn't it like the most locked down userspace process
has it's own pac stuff and everything
so basically webcontent injection is just dead?
yeah
not really
you could still make it work
it'd just be very hacky
does bootstraps automatic tweak injection require a decrypted ipa to have the tweak be injected?
I guess it's time for the hacky solution
maybe it works over raw mach, I haven't tried that yet
because it's one specific check that fails
it might be something where WebContent can send messages but cannot receieve them
because im seeing no logs at all with NSLog, even in %ctor
and because of XPC being bidirectional it fails
just patch it out, isn't WebContent's PAC bruteforcable if you have root access?
oh true
we should still maintain compatibility with existing rh tweaks, obviously it's difficult to ask everyone to rebuild all packages at once
that's just probably not going to happen and is not reasonably feasible
leave the daemons alone
I don't think it is yet
iirc it isn't
but not all rootless v1 packages will be updated to rootless v2 immediately. If the rh user installs a rootless v2 dependency package(such as libsandy), the installed rh tweak may be broken, and if this tweak has not been updated for rootless v2, then users will not be able to use this tweak in anyway
I think you're confused
rootless v2 and rootless v1 are iphoneos-arm64
current roothide is iphoneos-arm64e
balls
so in this case rh users will not be able to smoothly migrate to rh v2, they will have to completely uninstall the installed environment and reinstall and configure everything
and there is still a problem. If a dependent package has not been updated for rootless v2 (some dependent packages may be closed source), then developers will not be able to update to rootless v2 for tweak
pretty much any dependency package that has been updated for rootless is actively maintained
so that really isn't an issue other than maybe the first little bit
that's gonna happen no matter what
either way the goal is to move off of iphoneos-arm64e - even if the arch was just changed to iphoneos-arm64-rh and nothing else it would still be the same way
Someone give me the cliff notes once this discussion finishes pls, I donāt want to read allat
Ok š
if we get a new arch i vote for this one
rootless is not changing arch-wise
do tweaks (bootstrap using ellekit) work with signed apps from app store or do I have to decrypt the ipa and install it through TS? When I tried making a tweak with a filter for an app, it doesn't seem to be "injected" or ran
there is appstore tweak injcetion
any logs?
and you enabled tweak injection into the specific app?
not that im seeing
yes, through bootstrap
idk if im creating the tweak incorrectly, I do see that these modules are loaded in the app though:
roothideinit.dylib
bootstrap.dylib
libroothide.dylib
libinjector.dylib
roothidepatch.dylib
but I dont see any mention of my tweak there, unless thats intentional?
i think it should be called iphoneos-x86
NƵ
iphoneos-ppc wen
Theoretical question: in order for other places in the world to access the EU side-loading, would it require the use of basic bypasses (profiles, supervision,etc) or would it require the use of exploits (Kernel, CoreTrust,BootRoom,etc)?
(which makes it practically useless, except if they only check for stuff at install time and not at every launch)
Every launch sounds brutal
appstore
CVE-2024-23208 PoC
Damnnn
You have to use the same team ID
If youāre manually injecting
i got the pointer address to a swift ivar, however when trying to use the address explorer in flex the app crashes
anyone knows whatās wrong there?
I think thatās just a swift L
whatās the type of the ivar
šš
Yeah it isn't lmao

how lol
It is a kernel exploit
so it'd actually be powerful enough for physrw?
But one is a race condition the other is a memory management error. They are exploited in very different ways.
True, i was only referring to the actual impact tho
š
Idk, MDC and KFD are also kexploits but idk what difference there is
MDC can't physrw
:p
KFD is a physical use after free that uses a uaf that points to physical memory to set up krw primitives
MDC is a race condition in the vmap layer of iOS that allows you to write to read-only mapping. it doesn't do anything else
if you want to learn more about the MDC bug, ian beer has a talk about it
one part that i'm curious about is what kernel data structures actually have pointers to physical memory addresses
all of kfd is related to the l3 page table
And technically what we've just seen isn't an exploit so to speak. It's just proof that it can be exploited
Man
Execute code with kernel privileges?
That's different than both kfd and MDC
That's called a LPE
I think
is it an LPE or a krw
Fairly sure it's an LPE
MDC's was executing code with kernel privileges according to apple
I could make it work on iOS rn
some things extra needed
But idk what the exploit is useful for
trollstore install (i guess)
@sonic totem what does apple mean by code with kernel privileges? Just root, or is it like code running in the context of the kernel
I'm assuming it's just root
If it's code running in the kernel, you likely need root for it to work, however if it is code running in the kernel it could be useful for jailbreak on older versions
and i aint wrong, they both say the same impact š
You literally cannot arbitrarily execute kernel code without a PAC bypass
Idk what itās on abour
Hold on Iām playing guitar
Yeah I know, I was thinking that it was maybe abusing something to run code in the kernel
Something that the compiler missed PAC instructions on
this thing
Then again, I wouldn't be surprised if apple screwed up the entry to begin with. They screwed up their own description of PPL.
Because this does happen sometimes tbf
apple classified being able to run code that can access kernel memory as that, I think
What, that's so stupid
Running code with kernel privileges is different than kernel memory access lol
whatās with this
apple loves to hide
very normal
they silently patch landa in 16.7
I see
without even a second RC either
Interesting
apple is just wierd
That doesnāt mean itās useful for TrollStore btw
It could very likely be that it requires root privileges
we donāt know
until the exploit becomes public
if not we have other exploits as well
The exploit is public wtf are you talking about
which ones lol, google hasn't made the kernel bug public yet
forget about that
never gonna happen
and even if they did, we dunno if it's powerful enough for krw
@sonic totem if this is krw, this could be good for krw handoff, as it appears it works only using a file descriptor
A PROOF OF CONCEPT for a bug patched in macOS 14.3/iOS 17.3 has been released
IMPORTANT: A proof of concept DOES NOT equal an exploit, all it is is proof that the vulnerability can likely be exploited.
Also to note: this bug only exists in 17.0-17.2.1 - also no, DO NOT UPDATEā¦
read the important bit
it aint an exploit
Oh it doesnāt exist in 16.x?!
Also Iām a security engineer so shut up
It is an exploit, a poc means it was exploited
A poc is proof that it can be exploited
Uh no
No?
A PoC means that it was triggered
I guess I have a misunderstanding
Ah yea, thatās right
I mean handoff is handoff
Iām not gonna do any work with it because it isnāt useful for me
Yeah
Oof
Itās interesting either way
It was introduced in 17.0 so yeah
The manipulation with an unknown input leads to a memory corruption vulnerability. Using CWE to declare the problem leads to CWE-119. The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.
Itās krw
Thatās⦠not accurate afaik
Itās a use-after-free
Oh, Google has mislead me
is it a P-UAF tho
No
cause isn't physical UAF needed for krw?
What's the difference?
Oh also
a pUAF specifically deals with physical addresses
Nvm
No
Theyāre just
Easier to exploit
Good to know
What does this mean
An attacker that has already achieved kernel code execution may be able to bypass kernel memory mitigations.
What does Apple mean by that lol
PPL bypass
It could be
if u find a ppl bypass do you need to also find a sptm bypass for a15+ devices on ios 17+?
those devices don't have ppl if they have sptm
oh
Sort of, SPTM replaced the PPL binary in a15+ in 17.0+
ppl isn't a binary
so lets say we found like a krw for ios 17.0.1+ and a ppl bypass too
Isn't it a hardware feature controlled by one?
PPL is a micro kernel running inside of the kernel
we gotta find a sptm bypass for devices above a15?
Only it can access certain parts of memory
i wouldnāt be so sure
real
Darwin iPhone 22.2.0 Darwin Kernel Version 22.2.0: Mon Nov 28 20:09:56 PST 2022; root:xnu-8792.62.2~1/RELEASE_ARM64_T8120 iPhone15,3 arm Darwin
š
š„
SƩrotonine?
Seratonine yeah
Lit
Dopatonin
Dopaxine
wen eta
ios 18 untether wen eta
i fone
i fone
https://www.reddit.com/r/jailbreak/comments/1ah2c8w/ rate my setup Nathan š
bang
Ty
including a15 on 17.0+
once someone gets krw with that poc, hopefully, im gonna try and get serotonin working
My friend with 11 pro max is on 17.0
doubt that'll happen
you should use krw to get keyboard tweaks working
easy
Wonāt become krw
zone_require 
damn
Yeah lmao
Zone_require is fine when all you need to do is get a kalloc though
Well if youāre just trying to abuse something to allocate some kernel memory, it doesnāt matter
uh, how so
the issue here is you can trigger the uaf but can't reliably fill that exact spot in memory with controlled data
https://github.com/fmyyss/XNU_KERNEL_RESEARCH/tree/main/CVE-2024-23208 some nerd sent this in pale server
is this anything new or no
i've seen that link like 39 times today
sick
But task_for_pid on ios16 does not work. I started a process as root with task-for-pid_allow. But the task_for_pid function always gives me -1 and I don't see any error logs
I doubt
that'll happen
are traditional (not puaf) uafs even worth trying to work on anymore? I was thinking about it and it doesn't seem worth it to trial and error with kalloc_type
like that apple blog post about sockpuppet showed that almost deterministic exploit was reduced to 8% reliability because of kalloc_type
Wait so if you delete the ppl binary will you bypass PPL?

I love how 120Hz iPhones max out at 80 Hz 
Where are the pac and ktrr binaries?!
Delete them!!
make mud splasher
Nexus16
bootloops its coming
@hasty ruin honest response
The dang PowerPoint transition
now fiore has a tweak idea
bootloop master
Customize the iOS Nexus Bootloop Experience
challenge: unlock 80 Hz lock for ProMotion iPhones

there's 2 ways you can force 120 Hz in iOS
I hate when people ask me to do stuff like this because I donāt have the physical resources for that
but they never stay
rip
has anybody done forcing certain Hz on macs yet
only works on my device 
I don't think so
I'm not manually injecting, I made a tweak that has a filter for the bundle id of the app, and I enabled tweaking for that app. It's just that it doesn't seem to be hooking anything, and I'm not seeing any logs.
average BeReal. tweak
Can you listen to NSDistributedNotificationCenter.defaultCenter without hooking layoutSubviews ?
what does that have to do with layoutSubviews
all you have to do is add an observer for what you want
why are you hooking layoutSubviews lol
So I can throw it inside ctor ?
yeah but battery bim boom bye bye
It did not work without layoutS unfortunately
I would like to avoid it too
But
ĀÆ_(ć)_/ĀÆ
i can see why i guess
if you're looking at an ancestor then yeah subviews might come into play
Are you serious?
This is fraud, we need to file a class action lawsuit against Apple 
I mean the display supports 120 Hz and the latest update supposedly finally goes up to 120 Hz
so I guess it's not an issue anymore
They have been lying for 2 years if the latest update goes up to 120 hz, what about the previous ones?
I think they fixed it in 17.2 or 17.3
are you fr
I'm actually for real lol
you can use this chinese app to test
it has a Hz measurement pip window
once you start screen recording you'll see it start to hit 120 Hz but without it you'll see like 80 max on the homepage and in apps
and you can also easily tell š¤·āāļø
?? since when does Xcode do this
@sonic totem I might know why the constant reading didn't work
I did it in a while true loop, so it still has to evaluate whether true is true
I should've done it in a for(;;) loop
Because that doesn't have to evaluate anything
Is there a solution for this? Like is there an example tweak I could base of off to actaully test? I know bootstrap is being injected in the app, it's just that my tweak for whatever reason isn't despite the bundle id being in the plist
Yeah quite possibly
Wait what?
I thought it was showing two devices called āAlfieā
Itās letting me run it as arm64/arm64e?
Another thing is that I used virtual addresses to read it, using mapped physical addresses would be faster
Although dereferencing also probably takes some time
Now that I booted Arch
new issuesā¢ļø
error: '/home/bibi_fire/theos/sdks/iPhoneOS13.7.sdk/usr/include/mach-o/module.map' as a module map name is deprecated, rename it to module.modulemap [-Werror,-Wdeprecated-module-dot-map]
Funā¢ļø
Maybe rename it to module.modulemap
Thats what I'm doing
wait @sonic totem what if the compiler is inserting cache maintenance instructions into my code?
I have absolutely no idea
I can check with ghidra
But your program shouldn't interact with kernel cache immediately
the cache is a general CPU cache
L2 specifically
but compilers might insert the instructions to ensure execution order
Yeah idek what I was saying here lol
I was only half-focused
most modern compilers most likely will insert cache instructions
i believe itās due to ensuring proper execution
but idk
-O0 supremacy
mods :/
@sonic totem I've encountered a new error
*panic
pmap_enter_options_internal: page locked down
now why that's happening: idk
probably
/* The regular old kernel is not allowed to remap PPL pages. */
if (__improbable(ppattr_pa_test_monitor(pa))) {
panic("%s: page belongs to PPL, "
"pmap=%p, v=0x%llx, pa=%p, prot=0x%x, fault_type=0x%x, flags=0x%x, wired=%u, options=0x%x",
__FUNCTION__,
pmap, v, (void*)pa, prot, fault_type, flags, wired, options);
}
if (__improbable(pvh_get_flags(pai_to_pvh(pai)) & PVH_FLAG_LOCKDOWN_MASK)) {
panic("%s: page locked down, "
"pmap=%p, v=0x%llx, pa=%p, prot=0x%x, fault_type=0x%x, flags=0x%x, wired=%u, options=0x%x",
__FUNCTION__,
pmap, v, (void *)pa, prot, fault_type, flags, wired, options);
}
So you need PPLRW
It does
even if I put it in dma_perform, the same thing happens
are the PPLRW pages allowed to be accessed by DMA in the first place though?
weird
you sure the DMA operation has sufficent permissions in the first place?
or am i asking a dumb question
Well, I mean unless I somehow have to like
uh
read data with MMIO
but afaik you can only write data with that
oh right
have you tried reading from any paticular MMIO registers?
You setup PPLRW using DMA haxx and then your process can write to all PPL-protected memory
but this isn't only PPL protected
it's also KTRR lockdowned
* Marking a pv_head_table entry with any bit in this mask denotes that this page
* has been locked down by the PPL. Locked down pages can't have new mappings
* created or existing mappings removed, and all existing mappings will have been
* converted to read-only. This essentially makes the page immutable.
yeah that's what i was about to say, the pages are read only unfortuantly
but then how did oct0xor
who?
boris
Extra haxx needed
seems so
well
although I was writing before
what happened lmao
NSLog(@"Entered the writeback prevention thread!");
uint64_t _uuid_generate_time_addr = vtophys_kfd(0xfffffff00832be94 + get_kernel_slide());
uint64_t start = 0xfffffff00832be94;
uint64_t end = 0xfffffff00832c018; // Also static for testing purposes.
uint64_t size = end - start;
NSLog(@"Size: %d",size);
// sleep(1);
bool hasalreadyprinted = false;
dma_perform(^{
for(;;) {
physread64_mapped(_uuid_generate_time_addr);
physread64_mapped(_uuid_generate_time_addr+sizeof(uint64_t));
}
});
return 0; // Shouldn't ever be reached.
}
``` unless this is causing it?
this means no new mappings can be created for that page right?
not a bad idea
try to make incremental modifications though, so you can track it if any issues rise
yeah
also to avoid bricking the test device 
what firmware?
16.2
nice
I'm seeing if I can get this working for my upcoming jailbreak
but can't you already write to cache with the KTTR bypass
yes, that's what I'm trying to do
oh
it gets flushed way too fast though
so I'm trying to do this to constantly read from those addresses to prevent them from being flushed
(once it gets flushed, AMCC blocks it and panic)
but while it's in the cache



