Tags: riftaway7-code/hackmate
Tags
fix: address Hommage's Discord test report — CPU version cap, USB enu… …meration, standalone recovery download - recovery.py: Monterey required 5th-gen+ CPUs, excluding Sandy Bridge/ Ivy Bridge/Haswell which Dortania's guide (and the community) confirm do support Monterey as their last version — corrected min_gen. - compat.py: Windows USB enumeration only listed disks that already had a lettered partition, so a blank/unpartitioned USB (or one Windows failed to auto-letter) silently never appeared in the list even though Get-Disk found it. Now falls back to a raw-disk entry, and _format_usb_windows/get_mount_path handle that identifier. - bridge.py, src/hackmate_gui.py, gui-flutter: added a standalone "Download Recovery" screen (Flutter + Tkinter) so fetching a recoveryOS image no longer requires going through the full build wizard or running macrecovery.py by hand. - i18n.py: translated the new menu entry for es/pt/zh. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019J2gBiNsTkHnPpfkisEHWP
fix: log checker gave wrong advice for recovery root_hash errors when… … SecureBootModel is already Disabled Fixes #57. The "Recovery image root hash check failed" finding always told users to disable SecureBootModel, even when their config.plist already had it Disabled. analyze_file now reads the sibling config.plist and corrects the advice to point at the actual likely causes (AMD kernel patch mismatch, DmgLoading/ScanPolicy, or a real hang after ExitBootServices) instead of repeating a step already done. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019J2gBiNsTkHnPpfkisEHWP
fix: correct CPU generation detection order and wizard auto-advance Hardware scan ran CPU detection before GPU detection, so CPU's fallback GPU lookup used unresolved data - broke generation detection for CPU names that don't match the i3/i5/i7/i9 regex (e.g. Pentium/Celeron), which cascaded into "no compatible macOS" for otherwise-supported boards. Also removed an auto-advance call that skipped the hardware review screen before the user could confirm detected specs.
fix: bundle the python backend into the Flutter GUI release zip
The zipped Flutter build only ever contained the Flutter app itself —
it worked in every test because I always ran it from inside the repo,
where src/bridge.py was reachable a few directories up. A real user
extracting the zip standalone had nothing for BridgeClient to find
("bridge is not running"). Now compiles bridge.py into its own
hackmate-bridge.exe and bundles it alongside gui_flutter.exe;
BridgeClient prefers that bundled exe when present, falling back to
spawning a system python against src/bridge.py for local dev via
`flutter run`. Verified by extracting the zip to a folder with no
repo files nearby and confirming it connects.
feat: package the Flutter and Tkinter GUIs as standalone Windows exes Adds a windowed, self-elevating HackMate-GUI.exe (Tkinter) alongside the existing HackMate.exe (TUI) — never packaged before, previously source-only. build-exe.yml now builds and attaches both plus a zipped Flutter Windows build to every release. Fixes updater.py's self-update check, which picked "whichever .exe comes first" from release assets; now matches the currently-running exe by name so it doesn't point Tkinter GUI users at the TUI exe or vice versa. Also adds Linux/macOS platform scaffolding to gui-flutter/ (untested on either, flagged as such in the README) and a python3-then-python fallback in the bridge client for those platforms.
feat: add Flutter GUI as a new frontend for the Python backend Adds gui-flutter/, a Material 3 desktop GUI driven by a new JSON-RPC bridge (src/bridge.py, src/build_runner.py) over the existing backend, alongside the current Tkinter GUI and TUI. Covers build history, log checking, EFI health check, disk map, restore, USB mapping, config editing, and the full guided/manual EFI build wizard. Relocates the manual hardware entry option tables from hackmate_gui.py into hardware.py so both frontends share one source of truth.
fix: validate and retry the unpinned HfsPlus.efi download Field-confirmed via a real boot log: HfsPlus.efi is fetched from a raw GitHub URL (OcBinaryData, master branch, no release asset to size-check against) with zero validation and a single attempt — unlike every other download in this codebase. A truncated or corrupted response got written straight to EFI/OC/Drivers/HfsPlus.efi, and OpenCore hung loading it at boot, right after loading OpenRuntime.efi and before the picker ever appeared. Adds compat.is_valid_pe_binary() (size + MZ header check, matching the MIN_EFI threshold already used to judge OpenCore files valid) and a 3-attempt retry, mirroring the pattern kexts.py already uses for the OpenCore zip itself. Same fix applied to both hackmate.py and hackmate_gui.py, which had identical duplicated logic. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013Wmz3DwAYCtN3ooXVEcCRx
fix: don't blind-inject SSDT-PLUG when DSDT can't be read at all Field-confirmed: a board with no readable DSDT (SSDTTime unreachable, DSDT extraction failed) got the bundled fallback SSDT-PLUG injected anyway, hardcoding \_SB.PR00 as a legacy Processor object. Boot hung right where ACPI tables load, before the picker ever appeared — most likely because that path/style doesn't match this board's real CPU object at all, and we had zero information to know either way. "DSDT not found" and "confirmed legacy Processor()" are different states; has_acpi0007 is now None (unknown) instead of False when no DSDT was read, and SSDT-PLUG reports an actionable error instead of guessing, same as the existing ACPI0007-detected case. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013Wmz3DwAYCtN3ooXVEcCRx
PreviousNext