Recover a Forgotten DMG Password on a MacBook

This guide applies to encrypted DMG files that the user owns or has explicitly authorized you to recover. The goal is to test password candidates locally based on known clues, with support for GPU acceleration, resuming interrupted searches, and verifying results.

Before starting, record:

• The DMG's absolute path, size, and modification time.
• Known password clues: prefix, suffix, length, character set, capitalization, dates, and symbol positions.
• Search ranges already completed.
• Whether the user permits GPU use.

Convert natural-language clues into explicit rules. For example:

Prefix: example
Suffix: 4–6 digits
Include leading zeros: yes
Capitalization: keep the prefix lowercase
Candidate count: 10^4 + 10^5 + 10^6 = 1,110,000

Distinguish between “the entire password is shorter than 6 characters” and “the suffix is shorter than 6 characters.” For “include uppercase and lowercase,” distinguish between capitalizing the first letter, capitalizing each segment, and varying the case of any letter.

Keep the original DMG unchanged. Store recovery data in a separate working directory with restricted permissions.

Use John the Ripper Jumbo with DMG support. First check the installed version and its capabilities; supported formats, OpenCL support, and options may differ between distributions. John Jumbo supports DMG and GPU computation, but this does not mean every Mac has a usable GPU backend. Project overview

"$JOHN" --list=build-info
"$JOHN" --list=formats
"$JOHN" --list=opencl-devices

Confirm that:

• The CPU format list includes dmg.
• If using the GPU, the format list includes dmg-opencl.
• OpenCL device enumeration lists an actual device.
• The search startup log confirms that the expected device is in use.

In a restricted execution environment, sandbox restrictions may prevent devices from being visible. Request GPU access as required by the environment, then enumerate devices again.

umask 077
"$DMG2JOHN" "$IMAGE" > "$WORK/image.john"

Check that extraction succeeded and retain diagnostic output.

The extracted file contains the parameters and encrypted data fragments needed to test candidate passwords, so it is usually much smaller than the original DMG. Its size is not fixed; a result of a few dozen KB in one case is not a general requirement.

Successful extraction does not prove that the verification process works correctly. Some DMG files and extractor versions may have compatibility issues. Where possible, use a similar test image with a known password to check both CPU and GPU verification. An upstream report describes successful extraction followed by failure to match the correct password. Compatibility issue

Test small sets of likely candidates first, then expand gradually.

During generation, record:

Candidate rules
Exact count
Deduplication rules
Character encoding
Candidate file path
Generation script or mask

Preserve leading zeros in digit combinations. When concatenating fragments, specify whether repetition is allowed and the maximum number of fragments to combine.

For small candidate sets, generate a wordlist; for larger searches, use masks supported by the tool. Before using a mask, inspect its candidates and count with --stdout to confirm that the rules match the user's intent. Option reference

Example using wordlist mode:

"$JOHN" \
  --format=dmg-opencl \
  --wordlist="$WORK/candidates.txt" \
  --session="$WORK/search-001" \
  --pot="$WORK/found.pot" \
  "$WORK/image.john" \
  > "$WORK/search-001.console.log" 2>&1

Use a unique name for each session. Keep the console log at a different path from the session .log file generated by John.

First measure a stable speed against the actual target, then estimate:

Estimated time remaining = remaining candidate count ÷ measured rate

The MacBook model, the DMG's key derivation parameters, candidate batches, and thermal conditions all affect speed. A GPU does not necessarily make a very small candidate set faster.

If automatic tuning causes a slow startup or oversized batches, adjust the work-group parameters. In one Apple Silicon test, --gws=8192 --lws=32 ran reliably; verify these settings again on other devices.

Prefer running one search task at a time on the same GPU.

Track each search round using one of these states:

prepared
running
paused
completed_without_match
matched_unverified
verified
failed

Reports should include the current rules, the completed search range, the measured speed, and whether a match was found.

Apply these criteria:

• A successful session launch only justifies reporting “started.”
• The presence of a recovery file does not prove that the task is still running.
• A process exiting does not prove that every candidate was tested.
• Only report a range as ruled out when the log confirms completion without a match.
• Classify an abnormal exit as a failure or interruption.

Filter out plaintext candidates and recovered passwords when reading logs.

To pause:

1. Stop any scheduling script that would automatically launch the next task.
2. Send a single SIGINT to the target John process.
3. Wait for the process to exit and save its recovery state.
4. Check the relevant processes again to confirm that the GPU search has stopped.

Identify processes using the PID recorded at startup, the full command line, or the exact session path. macOS ps output may be truncated; use -ww when needed. Avoid terminating processes in bulk based only on their name.

John supports resuming from session files; sending another interrupt signal may prevent it from saving its state in time. Stopping and resuming

"$JOHN" --restore="$WORK/search-001"

Before resuming, check whether the original session has already completed. Also check how any time limit set on the initial run affects resuming.

Read results through John's --show option rather than assuming that the hash representation in the pot file exactly matches the extracted file.

Write the password to a local file with permissions set to 0600. Then:

1. Consult the disk image tool's help on the current macOS version.
2. Use its interface for reading the password from standard input.
3. Attach the original DMG read-only, without mounting its file system.
4. On success, detach only the device returned by this operation.

Change the state to verified only after verification against the original file succeeds. Hide the password in tool output and chat by default, and give the user the location of the restricted local file.

The final report should state:

Target image
Exact search ranges completed
Ranges not yet completed
Whether any processes are currently running
Locations of recovery and result files
Whether the password was verified against the original DMG

No match means only that the tested candidates were incorrect. Retain the search inventory so the next agent can skip completed ranges.