Please note, these PDF files are invalid. In "afhacked2.pdf", "Pages" root is object 4; and "Parent" of 1st page refers, correctly, to object 4. But "Parent" of 2nd page refers to some rogue dictionary object 9. Which, though happens to have same content as object 4, doesn't belong to pages tree, and so it's not 2nd page's legitimate parent, but an impostor. Same picture, different object numbers, in "afhacked.pdf".
I asked someone to export a 2-pages PDF file from InDesign for me, and of course it has no such issues. I strongly suspect there was some messing around with internals, copy-pasting or similar. Though maybe a bug of particular ID version.
Why no other PDF consumer complained or even noticed? Well, e.g. offending line, instead of:
{ return $self->{'Parent'}->find_prop($prop); }
could be:
{ return find_prop($self->{'Parent'}, $prop); }
i.e. valid procedural Perl, and search for a "property" would bubble as intended, as opposed to aborted search in case of proposed patch. All depends on internal world-view and hierarchy of other apps. I didn't investigate thoroughly, but, staying with Perl:
perl -MCAM::PDF -E "CAM::PDF->new('afhacked2.pdf')->_buildNameTable(2)"
is OK. At first glance, this method bubbles up looking for resources, same as "find_prop". It just happens that Pages root or intermediate nodes don't have additional magick attached to them, as in PDF::API2. It's neither good nor bad, just design decision and simply a given, in my opinion. The lib serves its purpose. I can think of hundreds(?) of ways to break a "valid" PDF file, if tinkered with at low-level, so maybe even Adobe Reader would crash ungraciously. Perhaps it's too much "defensive" to anticipate everything which is tiny percent of cases, sometimes try/catch at library user side is OK. Maybe I'm wrong. And, yes, I did my lot of in-house patching to deal with in-flow of broken PDF files from same "dear" customers. It's just these patches are not universal.
