🎯 Goal

Set up an Intel MacBook Pro (2013) as a dual-boot target machine with:

  • macOS (native)
  • a Linux distribution (native)

Long-term: use this laptop as a realistic attack target from my Apple Silicon MacBook Pro running Kali in Parallels.

This day wasn’t about exploitation — it was about infrastructure, compatibility, and recovery-first experimentation.

âś… What I Did

1) Attempted dual-boot setup on the Intel MacBook Pro (2013)

Plan (simple on paper):

  • keep macOS
  • add Linux in free space
  • use the machine as a native target

Reality:

  • the existing macOS (Yosemite) was too old for modern workflows
  • partitioning became messy
  • Linux was installed/removed, and macOS had to be removed as well
  • at one point the disk ended up effectively wiped (no macOS, no Linux)

2) Hit “macOS version hell” (Big Sur vs Catalina)

I aimed for macOS Catalina because it’s:

  • modern enough for tools
  • still comfortable on 2013 hardware

But Apple downgrade paths are not straightforward:

  • recovery doesn’t offer Catalina cleanly
  • installers are architecture- and model-dependent
  • “quick VM workaround” didn’t translate into an Intel-friendly solution

3) Ran into the real blocker: architecture (ARM64 vs amd64)

This became the core lesson:

  • Apple Silicon Mac = ARM64
  • Intel MacBook Pro 2013 = amd64 (x86_64)

Even when I could source installers:

  • cross-architecture shortcuts don’t exist at the OS install level
  • virtualization doesn’t magically make ARM installers work on Intel hardware (and vice versa)

đź”— Key Cybersecurity Connections

  • Lab infrastructure is part of cybersecurity skill
    • If I can’t build a stable target environment, my “attacks” are just toys.
  • Architecture awareness is foundational
    • Many real-world toolchains, images, and agents are architecture-specific.
  • Recovery-first thinking prevents self-inflicted outages
    • “Experiment safely” is a real operational skill.

⚠️ Challenges

  • macOS tooling limitations on old versions (Yosemite)
  • partitioning + reinstall loops on Apple hardware
  • architecture mismatch creating dead ends in workflows

🧠 What I Learned

  • amd64 (x86_64) and arm64 (AArch64) are different ecosystems.
  • Architecture constraints show up everywhere: installers, VMs, binaries, and even troubleshooting paths.
  • The correct mindset is: verify architecture early, then choose tools that match it.

⏭️ Next Steps

  • Get macOS into a stable state first (recovery anchor)
  • Choose a final Linux distro for the Intel target
  • Install Linux natively into clean GPT free space without damaging APFS
  • Prepare the target for lab use (network baseline, SSH, firewall posture)

đź’­ Reflection

Today wasn’t about “learning commands.” It was about learning constraints:

  • Apple workflows are restrictive
  • architecture matters at every layer
  • experiments are fine only if recovery is planned

This reinforced that lab setup is not a distraction — it’s a real competency.

âś… Lessons Learned

What worked

  • Prioritizing recovery and stability over “forcing it”
  • Respecting architecture boundaries

What broke

  • Assumptions about macOS downgrade/install availability
  • Expecting ARM-based workflows to translate to Intel hardware

Why it broke

  • Apple enforces OS/version paths tightly
  • ARM and amd64 are fundamentally different environments

Fix / takeaway

  • Always confirm architecture first
  • Plan recovery before experiments

  • Treat lab build quality as a first-class skill