(untitled)

how do you go about securely opening and reading PDFs, lain?

>>47370 I just download books on libgen. I never cared about it being secure or not, to be honest. Never had any problem so far.

I use a PDF reader that doesn't have much of an attack surface. No scripting support, etc. I don't think about it too much. If I was concerned for some reason, I would open it in an offline VM or maybe with live Linux on a spare laptop.

Do you mean something like avoiding detection/monitoring? Because checking if it's malicious is pretty trivial https://www.virustotal.com/gui/file/86a96ec03ba8242c1486456d67ee17f919128754846dbb3bdf5e836059091dba/behavior

>>47370 You can use "peepdf <file.pdf>". It will scan for all the objects and tell you which ones it thinks are dangerous. A dead giveaway is that if the PDFs contain JS code which, let's face it, most libgen PDFs are contaminated with. Non JS objects can also be malicious though. You can try converting the PDF to other formats and then back, e.g. pdf2ps or pdf2djvu.

>>47378 >A dead giveaway is that if the PDFs contain JS code which, let's face it, most libgen PDFs are contaminated with. How many did you scan? What was the output exactly? Didn't think so

Finally my bros at Elsevier and the Dystopian Police State Committee have managed to find a way to defeat the Freedom Rights and Crypto Denomination of the Cyberpunk Church! By dirtying PDFs with The One Interpreted Language They Fear, they will no longer be able to educate themselves and will slowly drift off into the murderous jaws of ignorance!

>>47379 >"Do my homework for me please" no need to get defensive now just because you download things from net haphazardously? Its not us that installed virii on your box

pdf2djvu raster images babey

Probably the only good defense advice is >>47372. Open it on an airgapped machine. This way the worst that can happen is rm -rf /*

>>47383 >pdf2djvu This is what I use, I usually get size saving on PDFs which aren't excessively compressed, or vectorized. For most documents I usually use the --fg-colors=black flag and for vectorized files I sometimes have to increase the DPI to get a nice looking conversion. I've downloaded or converted ~25 books since I started doing this and I've only had three greater than 10mb, with none greater than 20mb. I do this on the machine I use connected to the internet and then transfer these files via USB to my air-gapped system. Of course it's better to download Djvu directly, and this is often possible.

>>47385 That's cool. I tried converting a few which, more often than not, would compress beautifully. Are you aware of any DJVU exploits?

>>47386 Djvu is effectively just a large JPEG image with an attached plaintext file. It's not an executable, so there are no known exploits, just as there aren't for JPEGs, or plaintext files. The process of converting from PDF however, could be exploited because PDFs are an executable format.

>create a VM and disable the network >convert PDF pages to pictures with image magick >take pictures off VM and delete VM its actually pretty simple, you don't even really need a fancy program or something. granted, you lose some of the ergonomics of a PDF (PDFs are soykaf technology anyways, bloated ass format, easy vector for malware ), but this is generally the best way to do it if you want maximum security

Like >>47372 said, I just read PDFs with a viewer that doesn't even support javascript, then it doesn't matter if I'm downloading from libgen or the internet archive. Tried for fun to verify on virustotal for fun my PDFs (almost all pirated from z-library or random forums) and nothing malicious was found.

>>47392 I basically do this on an airgapped OpenBSD machine, but also rebuild a PDF from the images (full script: https://termbin.com/qv0v). The only issue being the generated PDFs are huge in comparison. >>47386 I would prefer a nicer method like DJVU, but have read about some possible exploits. Guess it boils down to trusting the conversion method/implementation.

>>47396 nice, i actually do a the exact same thing, but add 1 more addition. I run the image PDF through OCR to get some of the text back, and it works actually very well. You're right, the PDF files become huge (500 page PDF that is 10 MB may become 150+ MB in size), but I'll gladly take the extra size for the additional safety layer. Either way, even after conversion its always good to view the PDF in some reader with no network connection and no javascript execution capabilities

>>47396 >I would prefer a nicer method like DJVU, but have read about some possible exploits. I'd be very interested in hearing more about these exploits for obvious reasons. I'm not aware of any.

Convert them to PDF/A in a network-disabled ephemeral VM.

How can you be sure that your obscure freetard command line program displays or converts PDFs in a secure way? Isn't your computer infected the moment a thumbnailer renders a cover icon for file manager? Is disabled javascript execution the only requirement (e.g. not using Adobe Reader, or disabling javascript in settings)?

>>47424 You move the file to a VM, through your terminal, and scan its objects using a tool. You convert it in the VM as well and send it back.

>>47424 use a VM with no GUI or disable the thumbnailing, cut the network, convert PDF pages to images. I'm not sure how my freetard program can infect a fuarrrking PNG unless your PNG reader is fuarrrked, but it would need to know to embed a malware payload in a reader it has no idea about. the amount of exploits you would need to break through this is extremely unlikely

>>47426 What software do you propose for sanitizing? Have you checked it's vulnerabilities lately?

>>47429 first off, all you need is a single program, ImageMagick. Secondly, it literally does not matter how infected or vulnerable my ImageMagick program is. Unless they have infected it with multiple vulnerabilites that can detect which OS im running in which VM and which virtualization software im using, and can break out of a jailed ImageMagick, in a harded virtual machine, in a command line interface, then there is almost 0 chance they can infect the host machine. And if they somehow embed the PNGs with malware, they would need to know exactly which image opener im using on the host. And if i thought that might be the case, i could always convert the PNGs to JPEGs to bust the malware. This still doesnt render it impossible to do this, but effectively it becomes so impractical that i would just be easier to look for a browser vulnerability than to perform this insane chain of events required

What about mobile devices? There's a virustotal client for android, but considering that 1)You cannot trust virustotal. It's simple to avoid the scan and the file will be marked as clean. 2)Virustotal uses console versions of malware detecting software. 3)Even if you decide to trust VT, you don't have options like VM's without network interfaces, with a clean snapshot you can revert to (some malware also has VM detection, so it will likely not even work as it really should). (Things listed are pretty much known to everyone I guess, but repeating them will not harm for sure) I don't see any greeen flag to even trying to open a H4kUrNeighbor_(2).pdf file on the device you are actually using, also from what I know, there are no sandbox-mode pdf solutions whatsoever. So my idea is, take an old device, restore it to factory settings, remove physically wifi chip or do the same on software level, remove mic/cam if paranoid. (Basically making an e-reader lol, fuarrrk it, at least you will have fun tearing down an old phone/tablet. Also ebook readers are vulnerable too). And still I would be very skeptical about it's "security". Once you are done with this, enjoy you spooky pdf, anon. The post should've been much shorter. Also, as an alternative to VirusTotal I found hybrid analysis (https://www.hybrid-analysis.com/), but it has some problemes. For example if a pdf file has IP addresses in it, it will mark the file as suspicious. Even one line on the blank pdf document is enough for this. Again, you shouldn't rely on this services.

Zathura works pretty fine for most of my cases. Since it supports sandboxing via seccomp, I think it's secure enough for my needs. If you need even more than that, just use Tails or Qubes at that point.

This thread scares me. I just read 3.14rated pedofiles and loaded them in Okular (on Linux) and preview (on macOS) daily. I'm a normal person, and I can't afford so many programming books in hardcover because they costs a lot here. Am I to worry? Can Okular OR preview even run javascript and stuff? How can I know that a pdf is unsafe? From what I read on, they have static and dynamic content. Can I just disable dynamic content in my pdf readers and I'm all safe?

>>47407 I don't quite recall, but it might've been a vulnerability in certain DJVU readers rather than the format itself. Regardless, I generally trust my own simple implementation more than an arbitrarily complex one (like a specialized compression algo).

>>47468 If you run the files through virus scanners like say... virustotal and it's a decade old with no malware signature matches when you rescan, it's unlikely to be able to affect any current reader version even if it were to be malicious. It's a bit more touchy if the scanner never saw the file before and you have no idea when it was created.

>>47459 Yes, even with static analysis services you still have to steer. If you're that worried then just convert it to an inert format with a command line tool in jail. Is that what this forum is about? Time-wasting tech paranoia?

>>47516 What kind of format? >Is that what this forum is about? Time-wasting tech paranoia? Don't judge the whole forum only by one post. Also, since when pretending to have more security on a mobile device is equal to paranoia? As long as I can do such a simple thing as reading a pdf file without being concerned about its security, I don't really mind wasting some time. I also stated that the whole process doesn't even give you a guarantee to be safe from everything. Everyone is free to do what he thinks is the right way, and I was expecting other ideas since the problem may be relevant. You don't always have access to a laptop/pc and may want to read something on the go.

Would grep -ai 'javascript' file.pdf be enough to find out if a pdf has js or not?

>>47372 This, if you're that concerned op, VM it.

>how do you go about securely opening and reading PDFs, why wouldn't you just saying "reading" or "viewing"? do you have such buumer brain damage that you cannot imagine PDF without thinking of an analogy of a book or a file that you double click in windows?

>>47872 what are you even talking about

>>47822 yeah probably, as long as there's no foul play. maybe also try 'script' . but knowing JS there's likely to be some esoteric other way that requires knowing how PDF is actually defined in order to counter... I'm sure someone mentioned it already, since it's the obvious answer: you should try a VM. super easy to setup with virtualbox if u don't already know how. the only thing better than that would be an offline raspberry pi that you connect to over ethernet to view with VNC. I do something similar when I'm paranoid about native linux games I've pirated.

`strings sketchy.pdf > sketchy.txt` ? Sure, it's ugly, but seems like the least amount of attack surface. I see a single CVE for strings back in 2006.

>>47934 strings doesn't do a particularly good job at extracting graphs and images.

>>47378 >You can try converting the PDF to other formats and then back, e.g. pdf2ps or pdf2djvu. Why is this safe when the reader and converter use the same library?

i don't fear any government agency and read what I please; not a single entity is able to tell me what I can and can't read.

>>47461 seconding Zathura: it doesn't load JS so there's less to go wrong with it. There are very rare vulns that do use XREF without JS, but these are recursive buffer overflow crap and are very rare in the wild. https://blog.didierstevens.com/programs/pdf-tools/ pdfid allows for identification of PDF JS used

Wow lainons, I didn't realize double clicking on a PDF was so dangerous.

>>48872 dunno about pdf2ps, but pdf2djvu only recognizes a really small subset of the PDF standard. Literally only text and raster images get copied over to the resulting djvu file.

>>47370 I just cat it to my matrix printer bro

>>47393 What sort of PDF viewer would you recommend? Looking for something really minimal

>>48920 Adobe Acrobat 9.0

>>47382 >"Do my homework for me please" I tried and it didn't work. That's why I'm calling bullshit. If you're not lying then it should be easy for your to copy and paste the output.

>>47407 Not much research has been done on djvu libraries. I suspect our MemeBSD friend is just making things up. What a surprise. https://ddg.gg?q=site:cvedetails.com+djvu >>47424 >How can you be sure that your obscure freetard command line program displays or converts PDFs in a secure way? If you want to go full autism then you can do the Qubes thing which is use a VM to convert from PDF to bitmap and then outside the VM convert bitmap back to PDF. The assumption being that bitmap format is so trivial that whatever the compromised conversion VM spits out it will not be able to compromise the bitmap parser. https://blog.invisiblethings.org/2013/02/21/converting-untrusted-pdfs-into-trusted.html >The obvious disadvantage of converting a PDF to an RGB representation is that one looses text search You can add text search back to converted PDFs with tesseract. This is the command I use tesseract --psm 1 -l eng in.jpg out pdf

>>48940 Based and HP-pilled, but tesseract results are pretty variable in quality.

>>48940 What is the point of "trusting" a machine in this model? Are you afraid that it may track how many pages you read per hour, and then magically exfiltrate this information? If you don't want it to hop from a compromised VM to host you can just use physical isolation.

>>48943 >Are you afraid that it may track how many pages you read per hour, and then magically exfiltrate this information? Complex file parsing code can have bugs which can be exploited by carefully crafted files to execute arbitrary code when you open them. >What is the point of "trusting" a machine in this model? The assumption is that the machine which is converting the PDF may have been compromised by such a bug. Therefor you need a second machine to convert the simple format back into a PDF you can trust without simply reinserting the exploit.

>>48942 >tesseract results are pretty variable in quality I haven't had any issues but I mostly use it for converting screenshots of webpages into searchable/copy-pastable PDFs for offline reading and archive purposes.

>>48945 Actually one issue is that it sometimes ignores spaces which can be annoying when you copy and paste a sentence to save a quote or something.

>>48944 So it's only relevant when you're trying to convert a pdf to a bitmap for someone who can't open a pdf in a secure way?

>>48947 >So it's only relevant when you're trying to convert a pdf to a bitmap It's relevant when converting a PDF to anything including pixels on your screen.

>>48949 Open the file on an airgapped machine/VM and it isn't relevant since the attacker can't exfiltrate anything from it. If he wants to change what you see on your screen or cause a crash so you wouldn't read the pdf he can just give you garbage instead of the pdf you want.

>>48950 >Open the file on an airgapped machine/VM That is an alternative solution.

>>48951 Which involves an airgapped machine/VM and unnecessary steps just to downgrade your pdfs

>>48952 It depends on your requirements. Just because you don't need to store sanitized PDFs or distribute them to other people who don't have the skills or resources to setup an airgap doesn't mean that's true for everyone else in the thread. https://www.simplypsychology.org/theory-of-mind.html

>>48953 It doesn't matter if anyone here wants to distribute pdfs, you literally said "It's relevant when converting a PDF to anything including pixels on your screen." which is false as it's only relevant when you need to "distribute them to other people who don't have the skills or resources to setup an airgap"

>>48954 I thought >>48947 was asking if vulnerabilities in PDF parsers are only relevant when converting to another format. The answer is that vulnerabilities can also be exploited when opening the PDF to look at it. If you meant something else then I don't know, learn english I guess.

>>48955 You were wrong to think that. >>48951 doesn't make any sense in this context, too, since it's not a solution to converting a pdf.

>>48958 > >>48951 doesn't make any sense in this context, too, since it's not a solution to converting a pdf. >>48951 is an alternative to converting the PDF. >you were wrong to misunderstand me This level of autism is just embarrassing.

>>48959 Yes you were wrong to misunderstand me, I wasn't asking how those exploits might work. Opening a pdf on an airgapped machine/VM is not an alternative solution to converting a pdf but converting a pdf and then opening is an alternative solution to opening a pdf, >>48951 makes no sense if the former is your context.

>>48961 Not an argument

>>48959 >This level of autism is just embarrassing. He's just butthurt because you insulted openbsd. Repent and say 20 hail Theos.

>>48905 >pdf2djvu only recognizes a really small subset of the PDF standard Doesn't it have to read the potentially unsafe stuff before it can know what to ignore? Do you know if pdftotext (poppler-utils) is also safe?

Is Atril + Linux a good combo? I torrent a ton of books and gave some to a friend and he said that he had trojans on them. I figure as it was an exe that I should be fine but I do worry. Any thoughts?

>>49662 He was using Windows btw.

>>49662 Does the rule of don't open exe files if you don't know what it is not apply to everyone?

>>49662 Book.exe?? Lololol

Initial MemeBSD poster here. >>47424 >How can you be sure that your obscure freetard command line program displays or converts PDFs in a secure way? You hit the nail on the head. But there's more to consider than the safety of the program: its environment and its output are both distinct from the program itself. While it might produce properly-sanitized output, it's unreasonable to expect a perfectly-secure implementation. That separation's especially important for some applications: when you can't just read the PDF in a disposable VM. AFAIK, e-readers can't be secured to the same degree as a workstation. Same goes for if you're distributing an untrusted document to those with a less-technical background. >>48940 >I suspect our MemeBSD friend is just making things up. Certainly not intentionally. Here's an example (kudos to your DDG dork): https://www.cvedetails.com/cve/CVE-2021-22204/ And sincerely thanks for discussing the Qubes way. Food for thought.