TCP_TUNNEL - Hypercall and Guest side software

[jeppojeps]

I have prepared a "working" patch based on the alephresearch project https://github.com/jeppojeps/qemu-ios/tree/tcp_tunnel, I have added a register to the architecture and recycled the entire functionality.
"Working" for now means the QEMU patch compiles fine and the emulator keeps running as before. I still need to test the guest side.
I am finishing up the compilation of the binary guest side that should be adapted to make the correct ASM call.

i.e. in ARM 64 https://github.com/alephsecurity/xnu-qemu-arm64-tools/blob/master/tcp-tunnel/src/qemu-guest-services/general.c

we should recompile with iOS 4.2 SDK with something like

#include "hw/arm/guest-services/general.h"

int32_t guest_svcs_errno = 0;

void qemu_call(qemu_call_t *qcall)
{
    // Load the address of the QEMU_CALL register into r0
    asm volatile ("ldr r0, %[addr]"::[addr] "m" (qcall));

    // Perform the MSR instruction to write to the QEMU_CALL register
    asm volatile (
        "msr c15, 0, r0, c15, c15, 0\n\t"
        "isb"
    );

}

While I revamp my 2006 Mac Mini if someone wants to take a look. @devos50 if you want me to make a PR to a specific branch LMK, until it is working e2e I would not make any PR.

This software along with the patched emulator would allow to tunnel host-guest ports to any program in the guest i.e. bash

[devos50]

@jeppojeps that's great work, thanks! The fact that it compiles is already quite something. Indeed, it would be tremendously helpful to have the tunneling functionality working so there is some way to talk to the guest device through system calls. That would make debugging and other tasks much easier.

we should recompile with iOS 4.2 SDK with something like

The emulator is currently using iOS 2.1.1 and I am not sure about the backwards compatibility when compiling these binaries with newer IOS SDKs.

if you want me to make a PR to a specific branch LMK, until it is working e2e I would not make any PR.

If you wish, you can create a PR to another branch, say ipod_touch_2g_tunnel or so?

[jeppojeps]

I was able to compile the tunnel program on the mac mini for armv6 which should work on the emulator. I have to test it hopefully before 2024 I'll have some news. Yes please if you can make a tunnel branch it would be great!

…

On Sat, Dec 30, 2023, 13:21 Martijn de Vos ***@***.***> wrote: @jeppojeps <https://github.com/jeppojeps> that's great work, thanks! The fact that it compiles is already quite something. Indeed, it would be tremendously helpful to have the tunneling functionality working so there is some way to talk to the guest device through system calls. That would make debugging and other tasks much easier. we should recompile with iOS 4.2 SDK with something like The emulator is currently using iOS 2.1.1 and I am not sure about the backwards compatibility when compiling these binaries with newer IOS SDKs. if you want me to make a PR to a specific branch LMK, until it is working e2e I would not make any PR. If you wish, you can create a PR to another branch, say ipod_touch_2g_tunnel or so? — Reply to this email directly, view it on GitHub <#105 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB325SQ7JRSHQLN7WK7DD4DYMABKXAVCNFSM6AAAAABBEH62USVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZSGUYTONZVHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[devos50]

@jeppojeps cool! I just created the ipod_touch_2g_tunnel branch 👍

[devos50]

Small note, I just rebased the ipod_touch_2g branch on the latest QEMU release, so I also updated the ipod_touch_2g_tunnel branch.

[jeppojeps]

Awesome so I can pr directly.

…

On Sun, Dec 31, 2023, 15:44 Martijn de Vos ***@***.***> wrote: Small note, I just rebased the ipod_touch_2g branch on the latest QEMU release, so I also updated the ipod_touch_2g_tunnel branch. — Reply to this email directly, view it on GitHub <#105 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB325SVYBNQFVHQBKXNV2HTYMF25XAVCNFSM6AAAAABBEH62USVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZSHE3DKOJXGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jeppojeps]

OK so, first steps, the good news is that I can compile executables for the platform that are able to run, armv6 with iOS SDK 4.2. The kernel must be patched to skip code signatures checks of course.
So the tunnel executable works but it does not yet communicate, the syslog C api can be used to output messages into the console as visible in the screenshot. Indeed what I believe it's happening is that it get't restarted every 10 seconds by launchd.

[jeppojeps]

OK but now I can't really bind a socket, I progress just until the socket() call is done, I also put local-loopback, somehow we need to achieve network configuration.

Sun Sep 3 04:58:59 localhost configd[10] <Error>: Could not establish network configuration: Success!

@devos50 any idea, I saw among the logs that the network daemon though it is started

[jeppojeps]

On a separate side I have been advised we could try to use usbmuxd and map usb-over-tcp connection, the USB stack is initialized right?

[devos50]

@devos50 any idea, I saw among the logs that the network daemon though it is started

I'm not sure, I think I have disabled the network daemon for now and only start the very essential launch daemons. But even if I would start it, there would be no associated WiFi/Ethernet controller loaded in the device tree so I'm not even sure that this daemon would successfully initialise.

On a separate side I have been advised we could try to use usbmuxd and map usb-over-tcp connection, the USB stack is initialized right?

I think that's a good idea and it should be much easier than getting 802.11 up and running (even though I have some initial success with getting that up, although unstable). Unfortunately, I haven't started working on the USB stack but I could prioritise getting this working.

To get familiar with USB, one approach could be to try and boot the device into DFU mode, which requires USB communication. But I'm not sure how long this would take.

[jeppojeps]

OK so a couple of things, for the network with the tunnel, having the loopback stack would be more than enough
For the DFU let me point you here, we can look into it, I think we can recycle part of that code https://github.com/TrungNguyen1909/qemu-t8030/wiki/USB-and-Restore
In the code you find a usb-tcp device

[devos50]

Thanks for pointing that out! It seems like QEMU already has a lot of support for the USB hardware. I'll probably have a go at it today and keep you updated about this 👍.

[jeppojeps]

Great, let me know. Even if you setup the stack partially I can take care of putting the rest.

…

On Sat, Jan 13, 2024, 11:50 Martijn de Vos ***@***.***> wrote: Thanks for pointing that out! It seems like QEMU already has a lot of support for the USB hardware. I'll probably have a go at it today and keep you updated about this 👍. — Reply to this email directly, view it on GitHub <#105 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB325SUOICIRIV5PCD4SQCTYOJRIDAVCNFSM6AAAAABBEH62USVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQGQYTKNJYHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jeppojeps]

OK, I have a solution for accomplishing hypercalls

/*afl helper*/

target_ulong helper_aflCall(CPUArchState *env, target_ulong code, target_ulong a0, target_ulong a1) {
        // Log a message to a file in /tmp/
        if (code == 500) {
          FILE *logFile = fopen("/tmp/qemu_loga.txt", "a");  // Open for appending
          if (logFile != NULL) {
            CPUState *cs = env_cpu(env);
            ARMCPU *cpu = ARM_CPU(cs);
            hwaddr buf = env->regs[1];
%x -  0x41 - hwaddr %08x\n",code,a0,a1,buf);
            char buffer[4] = {0x41, 0x46, 0x4c, 0x00};
            code = cpu_memory_rw_debug(cs, buf, buffer, 0x4, 1); //this will write back 'AFL/0' into the guest buffer
          }
            fclose(logFile);
        }
}

[jeppojeps]

you should set r0 to 500 and call swi 80 into the guest then handle the hypercall into the SVC handler of TCG in /target/arm/translate.c