SabreTools.Serialization.Deserializers.PortableExecutable.ParseBaseRelocationTable can time out on large enough relocation tables, causing an otherwise valid and fully read executable to fail to give any info #7

New Issue

claunia · 2026-01-29T21:16:28Z

claunia commented

2026-01-29 21:16:28 +00:00

Originally created by @HeroponRikiBestest on GitHub (Jun 28, 2025).

On an executable with a large enough relocation table, InfoPrint will time out and completely fail to parse an executable it otherwise might. On this particular example, the .reloc section is fairly large, and only increments about 122 bytes at a time, from starting position 3829760 to endOffset 3985408. I can get through it in a debugger if I disable "Allow property evaluations and other implicit function calls" entirely or just jack up the evaluation timeout; or, if I simply comment out the part of https://github.com/SabreTools/SabreTools.Serialization/blob/main/SabreTools.Serialization/Deserializers/PortableExecutable.cs that calls for this check at d3e61b42dd/SabreTools.Serialization/Deserializers/PortableExecutable.cs (L156) .

Regardless of the proper solution, I would imagine it might be good to have a try-catch here, since if it fails, I'd imagine it would be best if it still returns the rest of the executable info. I don't know how you'd feel about that, though.

Simply running as normal:

InfoPrint game.exe 
Checking possible path: game.exe
Attempting to print info for game.exe
File format found: Executable
Either Executable is not supported or something went wrong during parsing!

Running with that check commented out:

InfoPrint.log

Sample:
game.exe from http://redump.org/disc/125414/ http://redump.org/disc/125415/

Originally created by @HeroponRikiBestest on GitHub (Jun 28, 2025). On an executable with a large enough relocation table, InfoPrint will time out and completely fail to parse an executable it otherwise might. On this particular example, the .reloc section is fairly large, and only increments about 122 bytes at a time, from starting position 3829760 to endOffset 3985408. I can get through it in a debugger if I disable "Allow property evaluations and other implicit function calls" entirely or just jack up the evaluation timeout; or, if I simply comment out the part of https://github.com/SabreTools/SabreTools.Serialization/blob/main/SabreTools.Serialization/Deserializers/PortableExecutable.cs that calls for this check at https://github.com/SabreTools/SabreTools.Serialization/blob/d3e61b42dd41c7d43496a0dde7e57be7accd32f7/SabreTools.Serialization/Deserializers/PortableExecutable.cs#L156 . Regardless of the proper solution, I would imagine it might be good to have a try-catch here, since if it fails, I'd imagine it would be best if it still returns the rest of the executable info. I don't know how you'd feel about that, though. Simply running as normal: ``` InfoPrint game.exe Checking possible path: game.exe Attempting to print info for game.exe File format found: Executable Either Executable is not supported or something went wrong during parsing! ``` Running with that check commented out: [InfoPrint.log](https://github.com/user-attachments/files/20958771/InfoPrint.log) Sample: [game.exe](https://github.com/user-attachments/files/20958766/game.zip) from http://redump.org/disc/125414/ http://redump.org/disc/125415/

claunia closed this issue

2026-01-29 21:16:28 +00:00

claunia commented

2026-01-29 21:16:28 +00:00

@HeroponRikiBestest commented on GitHub (Jun 28, 2025):

This is also the cause of https://github.com/SabreTools/BinaryObjectScanner/issues/371

Sample: joan.exe from http://redump.org/disc/125206/

@HeroponRikiBestest commented on GitHub (Jun 28, 2025): This is also the cause of https://github.com/SabreTools/BinaryObjectScanner/issues/371 Sample: [joan.exe](https://github.com/user-attachments/files/20958858/joan.zip) from http://redump.org/disc/125206/

claunia commented

2026-01-29 21:16:29 +00:00

@mnadareski commented on GitHub (Jun 29, 2025):

Actual issues:

Table doesn't always fill entire section
Reading outside of the section accidentally causes "too large" tables
Too large table causes overreading of data
Blocks are supposed to be DWORD-aligned

Solutions:

First empty block will return
Align to boundary manually

@mnadareski commented on GitHub (Jun 29, 2025): Actual issues: - Table doesn't always fill entire section - Reading outside of the section accidentally causes "too large" tables - Too large table causes overreading of data - Blocks are supposed to be DWORD-aligned Solutions: - First empty block will return - Align to boundary manually

claunia referenced this issue

2026-01-29 21:16:42 +00:00

[PR #7] [MERGED] Deserializer base #29

claunia referenced this issue

2026-01-29 21:16:42 +00:00

[PR #7] Deserializer base #31

Sign in to join this conversation.