You'll be able to use Docker-OSX to look for bugs in OSX, the iPhone emulator inside Xcode, your apps, etc.
Ideas:
Docker run straight to the Apple bash 5 or bash 3 Terminal, or both
Docker run straight into Xcode with IPA or Xcode project as an argument
Docker run with persist disk volume (supply the .img as an argument)
Docker run to fastlane?
Feel free to let me know ideas below!
Originally created by @sickcodes on GitHub (Dec 30, 2020).
For security research purposes, I will consider adding a ready-to-go disk later this week.
This is so that users can do security research on a virtualized instance.
For example, running their OSX applications inside containers, headlessly.
https://www.washingtonpost.com/technology/2020/12/29/apple-corellium-lawsuit/
You'll be able to use Docker-OSX to look for bugs in OSX, the iPhone emulator inside Xcode, your apps, etc.
Ideas:
- Docker run straight to the Apple bash 5 or bash 3 Terminal, or both
- Docker run straight into Xcode with IPA or Xcode project as an argument
- Docker run with persist disk volume (supply the .img as an argument)
- Docker run to fastlane?
Feel free to let me know ideas below!
Xcode has its own CI service called Xcode Bots.
Though it is not as popular as fastlane (and its document seems outdated), I see developers use it.
Perhaps it is also something should be in sight.
Here are some pages could be helpful:
@coppercash commented on GitHub (Dec 30, 2020):
Xcode has its own CI service called Xcode Bots.
Though it is not as popular as fastlane (and its document seems outdated), I see developers use it.
Perhaps it is also something should be in sight.
Here are some pages could be helpful:
* [Xcode Bots: Build Command Line Applications for Linux](https://medium.com/@martin.midori/xcode-bots-build-command-line-applications-for-linux-e66af16395a1)
* [Xcode Server for iOS: Getting Started](https://www.raywenderlich.com/12258400-xcode-server-for-ios-getting-started)
* [Xserverpy: Use Xcode bots from the CLI](https://medium.com/ios-os-x-development/xserverpy-use-xcode-bots-from-the-cli-945ab786ca94)
* [Xcode Server API Reference](https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/XcodeServerAPIReference/index.html)
* [buildasaurs / XcodeServer-API-Docs](https://github.com/buildasaurs/XcodeServer-API-Docs)
* [Xcode Server API deprecated? ](https://developer.apple.com/forums/thread/112194)
* [Xcode Server Tutorials](https://honzadvorsky.com/pages/xcode_server_tutorials/)
* [buildasaurs / Buildasaur](https://github.com/buildasaurs/Buildasaur)
* [buildasaurs / XcodeServerSDK](https://github.com/buildasaurs/XcodeServerSDK)
* [E-B-Smith / xcode-github](https://github.com/E-B-Smith/xcode-github)
Ideally, it would be best to SSH into the Utilities instance from the Arch container which would allow fully automated installation from the Arch container over SSH.
I have tried reverse SSH into the recovery utility shell, I can beging the SSH tunnel :
# OSX Commands# open Terminal Utility inside the QEMU guest.
ssh -R 5555:127.0.0.1:22 root@172.17.0.2
# Arch Commands# from the Docker container, SSH into localhost with the user and pass from the guest:
ssh root@127.0.0.1 -p 5555
...however, there is no passwd set for the guest terminal. An SSH public key for the arch container could be wget'ed inside OSX to /tmp, and then run the /usr/sbin/sshd bin setting a custom sshd_config with -f.
Run xdotool. These commands below are just the coordinates, but you can play with it using xdotool-gui.
# These are xdotool coordinates, can be used with Xfvb
# install
move mouse to 714 387
move mouse to 714 387
click mouse left button for 4 times then delay 0.1 seconds
move mouse to 1190 593
click mouse left button for 4 times then delay 0.1 seconds
sleep 10
move mouse to 952 725
click mouse left button for 4 times then delay 1 seconds
move mouse to 999 722
click mouse left button for 4 times then delay 1 seconds
move mouse to 1106 277
click mouse left button for 4 times then delay 1 seconds
move mouse to 875 581
click mouse left button for 4 times then delay 1 seconds
move mouse to 999 724
click mouse left button for 4 times then delay 1 seconds
Wait 23 mins
Possible solution prepare the jhfsplus disk outside the OSX guest. Seems futile without growing the p to 200G. If anyone has any suggestions, feel free to include!
# Arch Commands
qemu-img create -f qcow2 testing_disk.img 200G
parted testing_disk.img mktable gpt
# mkfs.hfsplus: testing_disk.img: partition is too small (minimum is 512 KB)
qemu-img resize testing_disk.img +10M
mkfs.hfsplus -J -D journal-dev -v Docker-OSX testing_disk.img
fsck.hfsplus -f testing_disk.img
Problem with the above mkfs is that it loses qcow2 format status... because it's not qcow anymore lol.
@sickcodes commented on GitHub (Jan 5, 2021):
Issues so far with automated installation (thoughts wanted!)
## Option 1: git push a compressed ready made disk to this repository.
JHFS+ can be fixed using hfsprogs. See for example: https://github.com/sickcodes/Docker-eyeOS#dockerhub
## Option 2: Automated disk wipe & partitioning through Termninal.
```bash
# OSX Commands
diskutil eraseVolume JHFS+ DockerOSX /dev/disk0
diskutil partitionDisk /dev/disk0 JHFS+ DockerOSX 99%
```
And then apparently you can execute one of the installation files. Most likely in `/System/Installer/`. I am yet to find it.
```bash
.../Install\ macOS*.app/Contents/MacOS/InstallAssistant \
--agreetolicense \
--nointeraction
```
Ideally, it would be best to SSH into the Utilities instance from the Arch container which would allow fully automated installation from the Arch container over SSH.
I have tried reverse SSH into the recovery utility shell, I can beging the SSH tunnel :
```bash
# OSX Commands
# open Terminal Utility inside the QEMU guest.
ssh -R 5555:127.0.0.1:22 root@172.17.0.2
```
```bash
# Arch Commands
# from the Docker container, SSH into localhost with the user and pass from the guest:
ssh root@127.0.0.1 -p 5555
```
...however, there is no passwd set for the guest terminal. An SSH public key for the arch container could be wget'ed inside OSX to /tmp, and then run the `/usr/sbin/sshd` bin setting a custom sshd_config with -f.
FYI: `/tmp` is writable in the Utility Disk
```bash
docker run \
--device /dev/kvm \
-e RAM=8 \
-p 50922:10022 \
-p 5555:5555 \
-v /tmp/.X11-unix:/tmp/.X11-unix \
-e "DISPLAY=${DISPLAY:-:0.0}" \
-e EXTRA='-netdev user,id=net1,hostfwd=tcp::5555-:5555,' \
sickcodes/docker-osx:latest
```
Notable: the recovery disk already has one port already open 10011?
Also tried:
```bash
# OSX Commands
sh -i >& /dev/tcp/172.17.0.2/5555 0>&1
# Arch Commands
nc -u -lvp 5555
```
## Option 3: Automated disk wipe & partitioning through Terminal.
Possible solution, autoclick through the setup:
Startx inside the container:
```bash
export DISPLAY=:99
nohup Xvfb :99 -screen 0 1920x1080x16 &
until [[ "$(xrandr --query)" ]]; do
sleep 0.5
done
nohup startx &
```
Run xdotool. These commands below are just the coordinates, but you can play with it using `xdotool-gui`.
```
# These are xdotool coordinates, can be used with Xfvb
# install
move mouse to 714 387
move mouse to 714 387
click mouse left button for 4 times then delay 0.1 seconds
move mouse to 1190 593
click mouse left button for 4 times then delay 0.1 seconds
sleep 10
move mouse to 952 725
click mouse left button for 4 times then delay 1 seconds
move mouse to 999 722
click mouse left button for 4 times then delay 1 seconds
move mouse to 1106 277
click mouse left button for 4 times then delay 1 seconds
move mouse to 875 581
click mouse left button for 4 times then delay 1 seconds
move mouse to 999 724
click mouse left button for 4 times then delay 1 seconds
Wait 23 mins
```
Possible solution prepare the jhfsplus disk outside the OSX guest. Seems futile without growing the p to 200G. If anyone has any suggestions, feel free to include!
```bash
# Arch Commands
qemu-img create -f qcow2 testing_disk.img 200G
parted testing_disk.img mktable gpt
# mkfs.hfsplus: testing_disk.img: partition is too small (minimum is 512 KB)
qemu-img resize testing_disk.img +10M
mkfs.hfsplus -J -D journal-dev -v Docker-OSX testing_disk.img
fsck.hfsplus -f testing_disk.img
```
Problem with the above mkfs is that it loses qcow2 format status... because it's not qcow anymore lol.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @sickcodes on GitHub (Dec 30, 2020).
For security research purposes, I will consider adding a ready-to-go disk later this week.
This is so that users can do security research on a virtualized instance.
For example, running their OSX applications inside containers, headlessly.
https://www.washingtonpost.com/technology/2020/12/29/apple-corellium-lawsuit/
You'll be able to use Docker-OSX to look for bugs in OSX, the iPhone emulator inside Xcode, your apps, etc.
Ideas:
Feel free to let me know ideas below!
@coppercash commented on GitHub (Dec 30, 2020):
Xcode has its own CI service called Xcode Bots.
Though it is not as popular as fastlane (and its document seems outdated), I see developers use it.
Perhaps it is also something should be in sight.
Here are some pages could be helpful:
@sickcodes commented on GitHub (Dec 30, 2020):
Thanks @coppercash I'll check those links out when I'm making the images :)
@sickcodes commented on GitHub (Jan 5, 2021):
Issues so far with automated installation (thoughts wanted!)
Option 1: git push a compressed ready made disk to this repository.
JHFS+ can be fixed using hfsprogs. See for example: https://github.com/sickcodes/Docker-eyeOS#dockerhub
Option 2: Automated disk wipe & partitioning through Termninal.
And then apparently you can execute one of the installation files. Most likely in
/System/Installer/. I am yet to find it.Ideally, it would be best to SSH into the Utilities instance from the Arch container which would allow fully automated installation from the Arch container over SSH.
I have tried reverse SSH into the recovery utility shell, I can beging the SSH tunnel :
...however, there is no passwd set for the guest terminal. An SSH public key for the arch container could be wget'ed inside OSX to /tmp, and then run the
/usr/sbin/sshdbin setting a custom sshd_config with -f.FYI:
/tmpis writable in the Utility DiskNotable: the recovery disk already has one port already open 10011?
Also tried:
Option 3: Automated disk wipe & partitioning through Terminal.
Possible solution, autoclick through the setup:
Startx inside the container:
Run xdotool. These commands below are just the coordinates, but you can play with it using
xdotool-gui.Possible solution prepare the jhfsplus disk outside the OSX guest. Seems futile without growing the p to 200G. If anyone has any suggestions, feel free to include!
Problem with the above mkfs is that it loses qcow2 format status... because it's not qcow anymore lol.
@sickcodes commented on GitHub (Jan 5, 2021):
The Dockerfile for hfsprogs:
@sickcodes commented on GitHub (Jan 24, 2021):
Competed!