Repository navigation
Fix fSELF program header offset for SPRXPatcher ELFs - #11
Merged
Merged
Conversation
Contributor
Author
|
RPCS3 accepted the fixes for this with PR 19906. Confirmed by the Refresher dev that this PR + upstream RPCS3 fix solves the problem. Merging into AxeHax. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
FakeEncryptGameEbootStep assumes the program header table starts right after the ELF header. This is correct for original, untouched EBOOTs, but ELFs patched via SPRXPatcher have such table moved at the end of the file and thus the offset needs to be recomputed correctly and the table data copied at the right place. This has never been a problem so far on either PS3 or RPCS3 as it was ignored, but recent RPCS3 upstream changes now rely on it effectively making it now unusable on newer RPCS3 releases.
This is a fix on the end of AxeHax tooling (and should be used on Refresher as well) but to actually work properly the RPCS3 upstream needs to still implement some changes that I have submitted in the PRs that is at fault, as for the "right" way to handle it both need to implement these changes unless upstream decides to just revert everything.