starred/Docker-OSX-sickcodes
1
0
Fork 0
mirror of https://github.com/sickcodes/Docker-OSX.git synced 2026-01-14 07:33:30 +01:00
Code Issues 411 Packages Projects Releases Wiki Activity

[WIP] Pre-installed Docker image with ready to go disk #99

New Issue
Closed
opened 2025-12-29 05:22:08 +01:00 by adam · 5 comments
adam commented 2025-12-29 05:22:08 +01:00
Owner
Copy Link

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!

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!
adam added the enhancementhelp wanted labels 2025-12-29 05:22:08 +01:00
adam closed this issue 2025-12-29 05:22:08 +01:00
adam commented 2025-12-29 05:22:09 +01:00
Author
Owner
Copy Link

@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:

@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)
adam commented 2025-12-29 05:22:09 +01:00
Author
Owner
Copy Link

@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 (Dec 30, 2020): Thanks @coppercash I'll check those links out when I'm making the images :)
adam commented 2025-12-29 05:22:09 +01:00
Author
Owner
Copy Link

@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.

# 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.

.../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 :

# 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.

FYI: /tmp is writable in the Utility Disk

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:

# 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:

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!

# 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.
adam commented 2025-12-29 05:22:09 +01:00
Author
Owner
Copy Link

@sickcodes commented on GitHub (Jan 5, 2021):

The Dockerfile for hfsprogs:

RUN yes | sudo pacman -Syu base-devel --noconfirm \
    ; yes | sudo pacman -Scc \
    && git clone https://aur.archlinux.org/hfsprogs.git /home/arch/hfsprogs \
    && cd /home/arch/hfsprogs \
    && yes | makepkg -si

RUN mkfs.hfsplus -v Docker-OSX -D testing_disk.img
@sickcodes commented on GitHub (Jan 5, 2021): The Dockerfile for hfsprogs: ```Dockerfile RUN yes | sudo pacman -Syu base-devel --noconfirm \ ; yes | sudo pacman -Scc \ && git clone https://aur.archlinux.org/hfsprogs.git /home/arch/hfsprogs \ && cd /home/arch/hfsprogs \ && yes | makepkg -si RUN mkfs.hfsplus -v Docker-OSX -D testing_disk.img ```
adam commented 2025-12-29 05:22:10 +01:00
Author
Owner
Copy Link

@sickcodes commented on GitHub (Jan 24, 2021):

Competed!

@sickcodes commented on GitHub (Jan 24, 2021): Competed!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
documentation
enhancement
following upstream developments
good first issue
help wanted
invalid
pull-request
Mirrored from GitHub Pull Request
 question
No Label enhancement help wanted
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/Docker-OSX-sickcodes#99
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?