qemu-ios
qemu-ios copied to clipboard
devos50
Tcp tunnel
@devos50 take a look and try compilation and running of normal flows, with some luck in the next days I'll start to debug the user space
I got it to compile 🎉. However, it looks like the commit history diverted from the target branch (probably because I rebased the ipod_touch_2g branch and force-pushed my changes). However, cherry-picking https://github.com/devos50/qemu-ios/pull/119/commits/3ed141cd1a199ddf17b3835e577a95f359555c22 on top of the ipod_touch_2g seems to work correctly.
I'm really looking forward to seeing if you can get the guest side running!
Yeah I figured there were some small changes, I finally have a macmini, accessible remotely, it has been a great fatigue, ssh does not even support 2048bit keys...I was able to compile a few test binaries, tomorrow, hopefully I will try the tunnel and netcat.
Will keep you posted.
Il giorno mar 9 gen 2024 alle ore 20:51 Martijn de Vos < @.***> ha scritto:
I got it to compile 🎉. However, it looks like the commit history diverted from the target branch (probably because I rebased the ipod_touch_2g branch and force-pushed my changes). However, cherry-picking 3ed141c https://github.com/devos50/qemu-ios/commit/3ed141cd1a199ddf17b3835e577a95f359555c22 on top of the ipod_touch_2g seems to work correctly.
I'm really looking forward to seeing if you can get the guest side running!
— Reply to this email directly, view it on GitHub https://github.com/devos50/qemu-ios/pull/119#issuecomment-1883684490, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB325SXE34SHGVMPSWQKUJTYNWNV7AVCNFSM6AAAAABBQP4X56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBTGY4DINBZGA . You are receiving this because you authored the thread.Message ID: @.***>
OK so, extra analysis, the architecture of the tcp-tunnel also requires a custom injected driver in the kernel, that they have used for multiple purposes. I don't discard the idea, but for fuzzing and for basic host-to-guest communication it requires a bit of extra time. Especially with respect to I/O and bash the usb approach seems more straightforward, given that the firmware already has a driver for that.
the architecture of the tcp-tunnel also requires a custom injected driver in the kernel, that they have used for multiple purposes.
I see. I have a bit of progress on the USB side though, mostly using a modified version of this code. I am able to send some bytes to the guest from my own Python script through a TCP socket. The guest USB should be fine now and the next step would be to setup another VM that acts as host. I did notice that the iPhone 6 emulator also implemented functionality for the guest to act as host, but that project and code is much more complicated. For now I guess the most important thing is to get a communication channel between the iPod Touch emulator and idevicerestore functional. I'll keep you posted!
BTW, I saw on X that you managed to do a basic system call, great stuff! 🎉
yeah, to be precise I executed /bin/bash -c ls / I had to import the right .so and everything but as you can see it works. To give more help, some of the binaries are from redsn0w and some others compiled by myself
When you get some basic communication, we can attach the shell. BTW I think I will be able soon to release a fuzzer. Keeping fingers crossed. I found a way to use the swi 0x80 interface and intercept a custom syscall. That would generate a QEMU_HELPER that will be able to return data into the guest.
On Wed, Jan 24, 2024 at 9:24 AM Martijn de Vos @.***> wrote:
the architecture of the tcp-tunnel also requires a custom injected driver in the kernel, that they have used for multiple purposes.
I see. I have a bit of progress on the USB side though, mostly using a modified version of this code https://github.com/danzatt/QEMU-s5l89xx-port/blob/master/hw/s5l8900_usb_otg.c. I am able to send some bytes to the guest from my own Python script through a TCP socket. The guest USB should be fine now and the next step would be to setup another VM that acts as host. I did notice that the iPhone 6 emulator also implemented functionality for the guest to act as host, but that project and code is much more complicated. For now I guess the most important thing is to get a communication channel between the iPod Touch emulator and idevicerestore functional. I'll keep you posted!
BTW, I saw on X that you managed to do a basic system call, great stuff! 🎉
— Reply to this email directly, view it on GitHub https://github.com/devos50/qemu-ios/pull/119#issuecomment-1907623609, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB325SXBXAA66FWIRM7L63TYQDAMVAVCNFSM6AAAAABBQP4X56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBXGYZDGNRQHE . You are receiving this because you authored the thread.Message ID: @.***>
-- [image: photo-logo] https://img.newoldstamp.com/r/542504/p [image: linkedin] https://img.newoldstamp.com/r/542504/linkedin [image: twitter_x] https://img.newoldstamp.com/r/542504/twitter_x [image: facebook] https://img.newoldstamp.com/r/542504/facebook Antonio Nappa, Ph.D. Application Analysis Team Leader @.*** https://img.newoldstamp.com/r/542504/e?id=1 844-601-6760 +1 415-992-8922 <+1+415-992-8922> Connect on LinkedIn https://img.newoldstamp.com/r/542504/c?id=1 [image: banner] https://img.newoldstamp.com/r/542504/b
So what I found out is that it is possible to mask interrupts through swi 0x80, hence you can load r0 with an arbitrary value, i.e. 500 and call swi 0x80 as you would on Intel call int 0x80. Henceforth that is how I have made communication work e2e between guest and host. Though the helper function uses cpu_rw_debug or alike to write directly in guest memory through the buffer address that I put in r1 while calling the syscall. This effectively implements an hypercall.