Show HN: IPA, a GUI for exploring inner details of PDFs (opens in new tab)

Mutool is the one I suggest to people. The easiest way to understand a PDF is to decompress it and then just read the contents.

    mutool clean -d in.pdf out.pdf

At that point you’ll realise that a PDF is mostly just a list of objects and that those objects can reference each other. After that you’ll journey through the spec understanding what each type of object does and what the fields in it control. The graphics stream itself is just a stack based co-ordinates drawing system that’s easy to follow too.

By way of an example. Here's an object that represents a Page. You can see the dimensions in the MediaBox. The contents themselves are contained at object "9 0 obj" ("9 0 R" is the pointer to it):

    2 0 obj
    <<
      /Type /Page
      /MediaBox [ 0 0 612 792 ]
      /Contents 9 0 R
    >>
    endobj

Meanwhile "9 0 obj" has the drawing instructions. They seem a little weird at first glance but you see the values ".23999999 0 0 -.23999999 0 792" each get pushed on the stack and then "cm" pops them to interpret them as the transformation matrix.

    9 0 obj
    <<
      /Length 18266
    >>
    stream
    .23999999 0 0 -.23999999 0 792 cm
    q
    0 0 2551 3301 re
    ...

The depth and detail of all of the different possible things that can be represented in a PDF is insane. But understanding the structure above is all you need to begin your journey!

EDIT The rest of your journey is contained in this epic document: https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...

I am the author of PDFSyntax, thanks for mentioning it!

The HTML output is like a pretty print where you can read view objects and follow links to other objects.

Since I have added a new command (disasm) that is CLI oriented and displays a greppable summary of the structure. Here is an explanation: https://github.com/desgeeko/pdfsyntax/blob/main/docs/disasse...

Thanks for the list, the idea behind my tool was to try to code something that might fit an analyst that would take a fast look at the PDF. I'm also trying to figure out some fast heuristics to mark/highlight some peculiar stuff on the file itself.

Now regarding the tools you mentioned, I haven't checked out all of them, but part of them are interesting (and more mature, speaking of testing and compatibility). However some (at least the ones I was trying) are very basic, and they don't allow the "Save object as.." or uncompress it. I like the feature of displaying the PDF for preview :)

The venerable PDFedit[1] more or less forces you to confront the internal structure of the PDF file as well.

[1] http://pdfedit.cz/en/index.html

Recommend just letting people have their one day in the sun. We’ve become less the site of builders as the red team for testing your launch.

Sweet, currently working on PDF signature stuff so I'm sure I'll find some stuff handy :)

Do be careful with iText products—they license their stuff under AGPL but their interpretation of AGPL is pretty extreme. If you talk to their team they'll tell you that ~everything your company makes should be AGPL-licensed if you use iText anywhere [0]:

> You may not deploy it on a network without disclosing the full source code of your own applications under the AGPL license. You must distribute all source code, including your own product and web-based applications.

They also have this delightful nagware encoded as a base64 string that spits this out in your logs [1]:

> You are using iText under the AGPL.

> If this is your intention, you have published your own source code as AGPL software too. Please let us know where to find your source code by sending a mail to agpl@apryse.com We'd be honored to add it to our list of AGPL projects built on top of iText and we'll explain how to remove this message from your error logs.

> If this wasn't your intention, you are probably using iText in a non-free environment. In this case, please contact us by filling out this form: http://itextpdf.com/sales If you are a customer, we'll explain how to install your license key to avoid this message. If you're not a customer, we'll explain the benefits of becoming a customer.

For using RUPS on a local computer you're probably safe, but I avoid the company because everything about their approach to the AGPL suggests that they chose it as a marketing technique for their paid products (with an extremely strong desire that it never be used commercially without pay), not out of a serious commitment to free software.

[0] https://itextpdf.com/how-buy/AGPLv3-license

[1] https://github.com/itext/itext-dotnet/blob/develop/itext/ite...

Thanks, it seems a great product too :) Do you have any particular feature that you share that product for?

Nice! My tool should be runnable in the browser thanks to wasm compatibility with Rust + egui :) Btw I've just tried it, and it's a little bit buggy in Safari with a 504kb PDF (lots of objects though). Apart from that, is there a way to export the raw stream? Is there any reason of do you print all the raw streams as a text?

Thanks! Immediate paradigm might be a little bit scary if you used to play with Qt, but looks easy to manage and it's really interactive

That demo page told me everything I needed to know about not using that framework. There's no right-click to copy the text, and there's similarly no context menu to open links in a new tab, or copy their URL

:D Well, I'm sure that half of reverse engineering community needs to thank you, and Zynamics for the important contribution for tools of static analysis. I just take the occasion to thank you for being an inspiration with such awesome tools like in BinNavi, BinDiff, and ultimately PDF dissector. When I was reading that it got discontinued, I just had that idea and started to reason about something focused on analysis, and applying some approaches we've already seen for the binary analysis tools.

My tool (PDFSyntax[1], mentioned in this thread) is a Python library that is able to both inspect and transform PDF files.

Depending on your transformation use case, you may write an incremental update with only a few bytes at the end of the original file instead of rewriting it entirely. To my knowledge this feature of the PDF specification is often overlooked and not a lot of libraries implements it.

It is a work in progress and I have not developed functions for images yet, though.

[1] https://github.com/desgeeko/pdfsyntax

I’ve used pikepdf[1] for text processing before. To use it for the task you outline, you’ll probably need to thoroughly investigate how bitmaps can be represented in PDFs. (Or maybe not, if you only need to deal with a known finite set of PDFs or PDF producers.)

[1] https://pikepdf.readthedocs.io/en/latest/

I've been using several Python libraries for working with PDFs. At least one of them allows you to walk the AST. (will look up in a bit and edit this comment)

I'd suggest you to code something along popular libraries for PDF manipulation. I've used pdf-rs for the tool.

argh, that's too bad, feel free to open an issue, what's happening in the console? It's panicking, isn't it? Feel free to contact me via email if you prefer

This is probably a simple find-and-replace task, so I wouldn't bother with proper PDF parsing or libraries. I would:

1. Use pdftk to uncompress it: pdftk input.pdf output uncompressed.pdf uncompress

2. Look at the PDF code (it's text based) to find the image insertion code.

3. Replace all instances of the image insertion code with strings of spaces the same length (there's a table of object byte offsets at the end that you don't want to mess up).

4. Use pdftk to compress it again: pdftk edited.pdf output output.pdf compress

I have a script that does this to remove pen strokes of particular colours so I can e.g. strip out marking rubric on test solutions written on a tablet.

Get the PDF 1.7 spec from https://pdfa.org/resource/pdf-specification-archive/. You're looking for the "Do" operator invoking a named image object defined elsewhere with "/Subtype /Image". See section 4.8, particularly the example on p343. Or, if it's badly done, it might instead be an inline image using the "BI" operator (a bit later in the same section).

I've had good experience with pypdf, if you're willing to do a little coding.

If you're OK doing it manually (not scripted), Inkscape can do this.

You could try one of Adobe's PDF APIs or script their software locally.

If you sign the file, you should be able to verify that the signature still matches the file.

How could a PDF be tampered with in your own bucket?