Fix ELF native binary extraction and repack for .bun section format#633
Fix ELF native binary extraction and repack for .bun section format#633VitalyOstanin wants to merge 3 commits intoPiebald-AI:mainfrom
Conversation
Newer Bun versions store embedded data in an ELF .bun section instead of the overlay. This adds fallback extraction from .bun section when hasOverlay is false, and writes back to .bun section during repack.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds Changes
Sequence Diagram(s)sequenceDiagram
rect rgba(200,200,255,0.5)
participant CLI as CLI/Invoker
end
rect rgba(200,255,200,0.5)
participant Parser as ELF Parser
participant Repacker as repackELF
participant FS as FileSystem
end
CLI->>Parser: parse ELF (getBunData)
alt overlay present
Parser-->>CLI: return bunData (overlay)
else .bun section present
Parser-->>CLI: return bunData and sectionHeaderSize
else none
Parser-->>CLI: throw "ELF binary has no overlay data and no .bun section"
end
CLI->>Repacker: repackELF(elfBinary, binPath, newBunBuffer, outputPath, sectionHeaderSize?)
alt sectionHeaderSize provided
Repacker->>Repacker: buildSectionData(newBunBuffer, sectionHeaderSize)
Repacker->>FS: write temp output file
Repacker->>Parser: reparse output and verify .bun section size
Repacker->>FS: restore permissions & rename temp -> outputPath
else no sectionHeaderSize
Repacker->>Repacker: construct overlay (bunData + size)
Repacker->>FS: atomicWriteBinary(outputPath)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/nativeInstallation.ts`:
- Around line 1164-1182: The repackELF flow (in repackELF where buildSectionData
produces newSectionData and bunSection is modified before
atomicWriteBinary(elfBinary, outputPath, binPath)) can corrupt the ELF if new
data exceeds the original section size; add explicit size checks and safe
expansion: before assigning bunSection.content, compare newSectionData.length to
Number(bunSection.size) and log/debug a clear warning if larger; attempt to call
a node-lief ELF section expansion API if available (documented on the node-lief
binding) to grow the section (similar idea to MachO.extendSegment()); if no
expansion API exists, wrap the write/atomicWriteBinary calls in try/catch and
validate sizes before and after elfBinary.write()/atomicWriteBinary to ensure
the section grew (throw/rollback on mismatch), and apply the same pattern to the
PE repack code that sets virtualSize/size (e.g., repackPE) so both formats
validate and handle expansion safely.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 55c30304-757f-418c-89fc-5bea66e67e30
📒 Files selected for processing (1)
src/nativeInstallation.ts
PR review raised concern about ELF binary corruption when new .bun section data exceeds original size (no explicit expansion API like MachO's extendSegment). Investigation: - node-lief has no ELF section expansion API (checked programmatically) - LIEF handles section relocation automatically during write() — verified by expanding .bun section by 1KB, writing, re-parsing, and confirming the content length matches Changes: - Log debug warning when new data exceeds original section size - Re-parse written binary and verify .bun section size matches expected length; throw on mismatch to prevent silent corruption - PE repack not changed (out of scope per maintainer)
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/nativeInstallation.ts`:
- Around line 1187-1200: The code writes the patched ELF into place via
atomicWriteBinary(elfBinary, outputPath, binPath) before verifying, so a failed
verification can leave a broken outputPath; instead, write the modified binary
to the temporary path (binPath) first, parse/verify that temp file with
LIEF.parse(binPath) and confirm the .bun section size matches newSectionData,
and only after successful verification perform the atomic rename/move to
outputPath (or call the existing atomic rename step). Update repackELF so
verification uses verifyBinary = LIEF.parse(binPath) and verifySection before
performing the final rename; keep references to atomicWriteBinary, outputPath,
binPath, repackELF, verifySection, and newSectionData to locate the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f18aff40-4088-48fd-8f4d-347b21ac9eec
📒 Files selected for processing (1)
src/nativeInstallation.ts
PR review: verification ran after atomicWriteBinary had already renamed the file into place, leaving a bad binary on disk if validation failed. Now: write to temp, verify .bun section in temp, only then chmod+rename to final path. Temp file is cleaned up on verification failure.
|
Closing in favor of #644. Thank you anyway @VitalyOstanin! |
Summary
Newer Bun versions (used in Claude Code 2.1.84+ on Linux) store embedded data in an ELF
.bunsection instead of the overlay. LIEF reportshasOverlay: falsefor these binaries, causingextractClaudeJsFromNativeInstallationto fail with "Failed to extract claude.js from native installation".Changes
getBunData(): when ELF has no overlay, check for.bunsection and extract using the existingextractBunDataFromSection()(same code path as PE)repackELF()to write back to.bunsection whensectionHeaderSizeis present (indicating data came from a section, not overlay)sectionHeaderSizethrough torepackELF()inrepackNativeInstallation()Testing
.bunsection, 129MB).bunsection (not overlay) and is read by Bun at runtimeRelated Issues
Relates to #589 (alternative approach — this fix works within LIEF instead of bypassing it)
Summary by CodeRabbit
New Features
Bug Fixes