Open jeppojeps opened 1 year ago
Hi! That would be great to fix! For trying to launch the bash
executable, I tried creating a launchd script that would execute bash
on startup. Unfortunately, I got a bus error
when trying to load the binary and I have no idea why or how to resolve that. If you can help explore this, running bash
could be of immense help in further debugging and emulation!
On a sidenote, I'm currently working on getting the iPod Touch 2G kernel up and running, and I have made quite a bit of progress there (but not to the point where I can launch launchd
) 👍. Maybe bash would work fine on that device?
I don't know which version of bash you tried. What I will try in sequence is either an old bsd zsh static binary. Or likely I may just create a few functions and compile it from scratch, a rescue shell basically. But I guess the toolchain I should use it's either an old BSD or very unlikely to find a Uber old Mac with it's Xcode running.
Will keep you posted.
On Sun, Jul 2, 2023, 6:15 PM Martijn de Vos @.***> wrote:
Hi! That would be great to fix! For trying to launch the bash executable, I tried creating a launchd script that would execute bash on startup. Unfortunately, I got a bus error when trying to load the binary and I have no idea why or how to resolve that. If you can help explore this, running bash could be of immense help in further debugging and emulation!
On a sidenote, I'm currently working on getting the iPod Touch 2G kernel up and running, and I have made quite a bit of progress there (but not to the point where I can launch launchd) 👍. Maybe bash would work fine on that device?
— Reply to this email directly, view it on GitHub https://github.com/devos50/qemu-ios/issues/43#issuecomment-1616718399, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB325SV2JP27ANDGNEXC4S3XOGNCRANCNFSM6AAAAAAZ3LVUTY . You are receiving this because you authored the thread.Message ID: @.***>
I have been thinking about this matter, and I have a partial solution, I'd inject code from the XNU kernel with _thread_create_running and then _pthread_set_self(NULL) would make the program resist to userspace startup eventually. And not get lost through the Mac kernel. What I am trying to understand is how to symbolicate the kernelcache, cause it seems that it shouln't be encrypted or easy to decipher.
also I have found a plausible issue, bash can't really work if you haven't abstracted stdin,stdout,stderr, since I see the function ipod_touch_sdio_ops it looks like you have your own way to output to the terminal but is your bash executable aware of that?
some other experiments, I have patched a few binaries here and there including kext and the Calculator, it seems that when I patch the kext to execute a QEMU hypercall that I have codified i.e. svc 0x33 I get that mysterious BUS ERROR you were mentioning, while if I call svc from the Calculator it makes it crash. This is likely something related to Mac vs. XNU transition, and my hunch is that bash suffers the same issue
@jeppojeps thanks for helping out on this issue! I'm not sure if the binary is aware of that (and nor was I) as I found the bash executable somewhere randomly on the Internet. Would you be able to further investigate this? This might also be an issue for the iPod Touch 2G.
I am looking into it, do you have the reference on how to call some useful syscalls such as posix_spawn() or execve()? The other issue is making a toolchain to recompile that binary 😢
Do you mean doing syscalls from QEMU? No, I haven't figured that out unfortunately but that would be extremely helpful, also for debugging purposes.
I started looking into setting up a toolchain a long time ago, but quickly gave up as there is almost zero development support for the iPod Touch 1G. This is also one of the main motivations why I'm currently focussing on the iPod Touch 2G instead.
Yeah, syscall interface is another issue, cause if I try to write sth even a shellcode I need to know what to call. Funny enough svc calls seem masked either in kext of user space apps. I patched around a few binaries. Every svc call you inject it masks to 0x80. Likely there's some Mac interface. Unfortunately I don't own that device, I have a 2g and further. For example if we can inject a kernel thread.
I need to debug the physical device to understand a bit more.
Cheers.
On Wed, Aug 2, 2023, 10:13 Martijn de Vos @.***> wrote:
Do you mean doing syscalls from QEMU? No, I haven't figured that out unfortunately but that would be extremely helpful, also for debugging purposes.
I started looking into setting up a toolchain a long time ago, but quickly gave up as there is almost zero development support for the iPod Touch 1G. This is also one of the main motivations why I'm currently focussing on the iPod Touch 2G instead.
— Reply to this email directly, view it on GitHub https://github.com/devos50/qemu-ios/issues/43#issuecomment-1661720133, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB325SX5M2ZMB3XNUKFPYF3XTIDZDANCNFSM6AAAAAAZ3LVUTY . You are receiving this because you were mentioned.Message ID: @.***>
Oh also, there's an exploit, but is in the USB stack IIRC, I don't know if you boot up that component, it's a UAF done by GeoHot a long ago
I tried yesterday very quickly to get the emulator in DFU mode but I had to do some more reverse engineering for that. I don't have the USB up and running yet. Using an exploit to access particular kernel features might be a good idea indeed!
Unfortunately, I'm not very much expertised with QEMU - I know how to setup peripherals etc but there is a lot I still don't understand, and the documentation is very scarce. In this blog post it seems they are using some special opcode to achieve communication between the host and guest, which might also be worthwhile to explore.
I remember that. I was never able to make it work properly. Worth a shot on an older iOS. Anyways we can really patch any binary and make every instruction do whatever we want. But it needs to be engineered a bit.
Will keep you poster.
On Thu, Aug 3, 2023, 12:23 Martijn de Vos @.***> wrote:
I tried yesterday very quickly to get the emulator in DFU mode but I had to do some more reverse engineering for that. I don't have the USB up and running yet. Using an exploit to access particular kernel features might be a good idea indeed!
Unfortunately, I'm not very much expertised with QEMU - I know how to setup peripherals etc but there is a lot I still don't understand, and the documentation is very scarce. In this blog post https://alephsecurity.com/2020/03/29/xnu-qemu-tcp-tunnel/ it seems they are using some special opcode to achieve communication between the host and guest, which might also be worthwhile to explore.
— Reply to this email directly, view it on GitHub https://github.com/devos50/qemu-ios/issues/43#issuecomment-1663729868, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB325SRKOD5Y5DT54XF464TXTN33RANCNFSM6AAAAAAZ3LVUTY . You are receiving this because you were mentioned.Message ID: @.***>
Hello! I opened the writeable filesystem .dmg and found already bash and launchd, if you describe a bit the process where you were stuck I may have some cycles to devote.