I think most of your issues are equating "QEMU = vmware player" or something like this. If you're curious, you can see Xcode debugging an ARM64 app from the App Store here - all of their inspection tools work out of the box! Planning on releasing by end of month (hopefully) for $100/year, aimed primarily at bug bounty hunters and pentesters, though there's nothing stopping you from just using it to play an iOS-specific game or somesuch. It currently supports most non-Swift apps and a small number of Swift apps once I have proper Swift support, pretty much everything should Just Work (TM).
So I wrote a translation layer that does ARM64 emulation of the app, while translating calls from ARM->Native libraries and vice versa.
Apple's iOS Simulator ships x86_64 binaries for all the iOS frameworks, so you need to build your application specifically for the Simulator in order for it to run obviously a no-go for most cases, e.g.
Click next to install the driver.This is really awesome for kernel exploitation and such, but for more practical application testing, I've been working on an alternative solution for the last two months.
Right click ‘Unknown device’ then select Update Drivers>Browse my computer for drivers>D:\NetKVM\w10\ARM64. Select ACPU ARM64-based PC>Microsoft ACPI-Compliant System>PCI Express Root Complex>Unknown device. Select View>Devices by Connection in the top menu bar. Reboot, then open Device Manager in Windows. To enable Internet access, once you have opened your desktop, open up a Command Prompt terminal as Administrator: You’ll notice that Windows doesn’t have Internet access at first.
Save the settings, and select Reset in the main BIOS menu to test out your new resolution. This may change in the future, but we have to use ramfb for now. It’s limited to a relatively small resolution, due to standard VGA for ARM64 not being supported, and having to use ramfb instead. Then, set your display resolution up to 1440x900 in Device Manager > OVMF Platform Configuration (or any other resolution you want to use). When QEMU first starts up, select the window and press ESC before it starts booting. device qemu-xhci \ -device usb-kbd \ -device usb-tablet \ -drive file =disk.qcow2,if =none,id =windows \ -device nvme,drive =windows,serial = "dummyserial" \ -nic user,model =virtio \ -drive file = "virtio.iso",media =cdrom,if =none,id =drivers \ -device usb-storage,drive =drivers \ -monitor stdio \ -device ramfb \ -drive file =pflash0.img,format =raw,if =pflash,readonly =on \ -drive file =pflash1.img,format =raw,if =pflash \
Qemu-system-aarch64 \ -accel hvf \ -cpu host \ -smp 4 -m 2048 \ -M virt,highmem =off Use your favorite text editor to create start.sh:
Qemu-img snapshot disk.qcow2 -a SNAPSHOT_NAME to revert to a snapshot.ĭownload the LATEST VirtIO driver ISO for Windows.įinally. Qemu-img snapshot disk.qcow2 -l to list snapshots, and If something goes wrong and you need to revert to a snapshot, just do Remember to take another differently-named snapshot after installation is complete (I like to name mine clean_install). Qemu-img snapshot disk.qcow2 -c brand_new That way, we won’t have to redownload the VHDX file. We are going to take a snapshot of our QCOW2 file, just in case anything goes wrong during installation. Once it’s done, delete the original VHDX file, as we no longer need it. Now you just wait this might take a while. Remember to change Windows.vhdx to the path to your own vhdx file. Qemu-img convert -O qcow2 Windows.vhdx disk.qcow2 We want to convert it to a QCOW2 file, so we can take snapshots of it and compress it. Now that you’ve built QEMU, the Windows VHDX is probably done downloading. Dd if =/dev/zero of =pflash0.img bs =1m count =64ĭd if =/dev/zero of =pflash1.img bs =1m count =64ĭd if =QEMU_EFI.fd of =pflash0.img conv =notruncĭd if =QEMU_VARS.fd of =pflash1.img conv =notrunc