Fileinfo: junk in PE rich header signature

[PeterMatula]

We encountered junk data provided by retdec-fileinfo in PE rich header signature. E.g. for 2acd2ff9c70ba9398221cf2265b2fddaceae3e31a29883594bcce545f02be6a3:

Rich header signature    : 89de35fc89de359489de35b789de355989de355489de352689de34dd89de34a889de34b289de346589de341e
                           89de342289de343b89de336789de330389de332989de32c189de328289de32a389de324989de325189de3267
...

Samples:

• 2acd2ff9c70ba9398221cf2265b2fddaceae3e31a29883594bcce545f02be6a3
• 7f29a26f830eee42a80a1a35169d9f616ca9823e386316f5eccfe36f90a8fe4b

Investigate the reasons and try to prevent providing such junk data. The solution would be to either fix a bug causing this (if there is a bug) or reliably detect such cases and prevent them. It is however quite possible that file offsets are in fact pointing at existing "junk" data, try to come up with some solution anyway - e.g. heuristics, sanity checks - analyze and discuss with @PeterMatula.

[HoundThe]

I had a look at the sample and I think the Rich header analysis is wrong. I think the correct analysis would be: find the "Rich" that marks the end of the Rich header, grab an XOR key that follows the ending marker, and then continue to decrypt from the bottom up until you find decrypted "DanS" that marks the start/end of the Rich header. But currently, the analysis finds Rich and XOR key, but it decrypts everything in the space between DOS header/stub and ending "Rich" marker.

I've tried to make some quick implementation of this and it seems to give sane results without the junk. The current analysis returns the junk data even if it's not between the "DanS" and "Rich" markers. The code is a bit more complex and uncommented, so I'll take a deeper dive to confirm my suspicion.