A PDF that crash Adobe Reader, just a little discovery that i want to share.
The PDF can be downloaded here: https://github.com/JonnyBanana/PDF_Scroll_ASCII_Crasher/releases/tag/v1
Like many things, this too, was discovered by accident....
I was intent on creating graphics made entirely of ASCII characters, and in the various steps to make them "marketable,"
one involved converting them from .html to .pdf files.
Once I opened the pdf to see its contents, I immediately noticed that something was wrong....
The pdf was displayed very slowly and if I tried to scroll down the page the program would start to glitch,
and when I tried to close the pdf the program (Adobe Reader, to be precise) immediately crashed.
Interesting...
However, maybe it is a case...
I try again, same result...
Mmmm, maybe it's my computer...
I try again with a laptop, again same result...
Well it was not my computer.
And so I accindentally discovered a way to crash Adobe Reader,
a likely good start to unearth more serious vulnerabilities...
So I want to share this little discovery with other geeks and researchers,
so that they can (maybe) get something good out of it.
In the "PDF" folder you can find the pdf that crashes Adobe Reader.
For better understanding I will include all the exact steps I took to create the pdf,
starting with the .png image i started from.
-1 Downlaod this png:
https://github.com/JonnyBanana/PDF_Scroll_ASCII_Crasher/blob/main/CASE%20STUDY/Hand_pointing_gun_meme.png
-2 Convert the png to Ascii here (download it as html file):
https://manytools.org/hacker-tools/convert-images-to-ascii-art/
-3 Convert the html file to pdf here: https://www.sejda.com/html-to-pdf
-4 Open the pdf and scroll up and down a couple of times, and try to close the program,
at this point the application should crash (see video below).
-1 According to my tests, the glitch resides esclusively in Adobe Reader.
In my tests, I tried to use the pdf with the following programs:
- Adobe Reader (works)
- Foxit PDF Reader (doesn't work)
- Sumatra PDF (doesn't work)
- Wondershare PDF Element (doesn't work)
-2 This technique does not work very well, in the sense that it does not completely crash the system every time. Depending on the target machine, and the circumstances, it can cause major slowdowns in the program, up to and including a total crash. In my tests sometimes it was enough to try to close the pdf, other times I had to do several scrolls up and down (best if you use the middle mouse scroll), other times it happened by doing a few clicks here and there, what is certain is that each time the program has an obvious difficulty loading the data visualization. I would also add that in my opinion it works best when the pdf is opened full screen, but still it can work in other circumstances.
-3 The technique does work with differents images and formats (see more detailed analysis below).
-4 The technique does not work with just any Img to ASCII Converter(see more detailed analysis below)..
In my tests, I tried to use the pdf with the following converters:
- https://manytools.org/hacker-tools/convert-images-to-ascii-art/
(works, note that this site supports conversion from png file to ASCII file in html format) - https://www.text-image.com/convert/ascii.html
(doesn't work, this site doesn't allow direct conversion to html, so it needs two more steps:
you have to copy the output to text file (odt, txt, etc.) , and then convert it to html file.
-5 The technique does not work with just any HTML to PDF Converter (see more detailed analysis below)..
In my tests, I tried to use the pdf with the following converters:
- https://www.sejda.com/it/html-to-pdf (works)
- https://convertio.co/it/html-pdf/ (doesn't work)
-6 This type of attack (if you can call it that) can be easily automated through shortcuts.
Adobe Reader Scroll Shortcuts
-
Press Ctrl + Shift + H to initiate auto-scroll in Adobe Reader
-
Adjust the scroll speed using the up and down arrow keys
-
Press the minus key (-) to change the scroll direction
-
Press Ctrl + Shift + H to stop auto-scroll
In my brief tests, I used 3 different images (png, jpg):
Initially I started with the image 1, from which my studies started.
Analyzing the ASCII characters in the image shows that it contains the following characters:
@ & # B G J P Y 5 7 ? ! ~ ^ :
Although I think the trick is more in the html code (also because If you directly convert a document file (odt, txt, etc.) to pdf, the technique doesn't work, it necessarily requires converting to html file as well), I wanted to try different images anyway, to see if there was any correlation between the characters used.
And so I switched to the image 2.
Analyzing the ASCII characters in the image shows that it contains the following characters:
@ * . # ( / , & %
A simple cross-check shows that the two images use the following characters in common:
@ # &
I then noticed that the img/ASCII converter fills the background (both the black ones and the transparent ones) with the @ character. And so I used the image 3 image (a high-resolution black background), And I realized that the technique works even using only the @ character, so I deduce that it is enough to use only one special character for the whole thing to work.
So it's time to try with other characters, let's try with a normal character, for example the aletter.
Then i replaced (directly from this html file) all the @ with the letter a.
The result was this html file,
hich I subsequently converted into this pdf.
The technique works this way as well, although I must say that it is more difficult to get the program to start crashing. It follows, then, that the trick works regardless of the character used, but that it works slightly better with special characters, especially when mixed together.
As a final thing, at the "font" level, i tried increasing the number of characters (which when converted to html format are contained within tags), to see if i could fatigue the program further, so as to cause increasingly efficient crashes. But if you even try to double the number of characters (and thus "span" tags) by manually editing the html file, when you try to convert it to pdf, the conversion program goes into error, making the last step impossible.
In any case, I considered analyzing the conversion to html more than anything else, as I think the bulk to understand is there.
The HTMl files for this test can be viewed here
As mentioned above I used two different image to ASCII converters, and only this one worked. In fact, i'm pretty much certain that both would have worked, and that the difference is that this converter does not allow downloading the converted file to html format, and so the problem occurs later in the conversion from text file to html.
As for the conversion settings, I simply set the output width (in characters) to 200, a.k.a. "the maximum level".
Other converters allow larger widhts, but the one in the converter I used is more than enough to make the trick work.
Otherwise, there is not much to add here ...
In my tests, I used 2 different HTML to PDF Converters:
It is enough to open the two files to notice the huge differences at the graphic level.
Conversion by sejda.com (image reduced by 50%)
Conversion by convertio.co (image reduced by 50%)
Apparently the conversion of the convertio.co websitesite, in this case, is pretty lousy...
As far as the two files are concerned, not much can be said, this is because
when you look at a PDF file with notepad (or similar) the program automatically converts
multi-byte characters to single 8-bit characters.
But still you can see some differences in the files, in those few "human redeable" parts.
Inside the PDF converted by sejda.com
Inside the PDF converted by convertio.co
The two PDF files can be viewed/downloaded here:
So let us see the differences between the two converters I used in my tests.
You can see the two HTML files here:
Let's start by analyzing the file that works for the purpose, which is file 1.
Basically, the converter inserts each ASCII character inside a "span" tag.
As you can see from the screenshot below some "span" tags are in error, this is because they contain the & character, which in html language is a special character that is used to create other characters, to make a long story short, in the HTML language to use the term & you use the entity code "&", while the & character is used (in combination with others) to display other special characters.
More info here: https://www.whatsmyip.org/html-characters/
Definitely interesting, but we know from previous tests (done only with the letter @) that it can't be the real answer, although I have to say that files that have these kinds of errors seem to work better, maybe it's good to keep track of them anyway...
Taken by curiosity i couldn't resist and immediately edited the html file to create an injection of wrong "span" tags (thanks to the & character), as you can see here.
In addition, it is good to remember that the character & is one of the 3 common characters in the ASCII files I tested (@ # &).
Then, as usual, converted to pdf.
Also works this time, but I didn't notice any particular improvement....
Here are the CSS rules that are inserted into the file by this converter:
display:inline-block;
white-space:pre;
letter-spacing:0;
line-height:1.4;
font-family:'Consolas','BitstreamVeraSansMono','CourierNew',Courier,monospace;
font-size:12px;
border-width:1px;
border-style:solid;
border-color:lightgray;
Now let's analyze file 2. For this file, I had to perform an extra step (as mentioned above), which was to download my ASCII file in TXT format, and then convert it to html here: https://convertio.co/it/txt-html/
The HTML file can be viewed here.
It is noticeable right away that the differences in the code between the two files are several.
Let's start by saying that it seems to be converted in a much finer way than previously used.
The CSS rules are much more than that, and there are also very important rules
(that were not there in the previous one) for displaying the file correctly.
I'm talking about @media screen and @media print (line 30, 104).
The "@media" attribute allows us to set a style sheet for each media on which our page will be displayed.
The "screen" value is obviously for optimization on different types of screens, while the "print" value is for print optimization.
In addition, this converter adds a set of js functions (from line 190 to 216) , some designed to optimize visualization.
These facts gives us (probably) the explanation of why this converter is not suitable for this attack.
Having come this far, i'm increasingly certain that the glitch happens because
of css rules (perhaps because they can be improved?) added during conversion.
I was then reminded of the only css attack I know of, which is
the CSS webkit filter DoS attack created by pwnsdx.
More info Here:
https://github.com/JonnyBanana/safari-ie-reaper.github.io
But so how exactly does this kind of attack work?
In much the same way as found above, here again we have
(purposely poorly written) css rules that crash a target, in this case a browser.
The CSS code tries to apply a CSS effect known as backdrop-filter to a series of DIV's.
Backdrop-filter is a relative new CSS property and works by blurring or color shifting
to the area behind an element. This is a heavy processing task...
The attack uses a weakness in the -webkit-backdrop-filter CSS property,
which uses 3D acceleration to process elements behind them.
By using nested divs with that property, all graphic resources are quickly
consumed, and freeze the browser, or in some cases causes kernel panic the OS.
This vulnerability has been, in part, mitigated, but I know for a fact that it
still works, especially on older machines.
And so I immediately attempted an HTML to PDF conversion that contained this attack.
HTML file: here
PDF: here
But, as you can see from the screenshot below, unfortunately it did not work, this is because
the file size exceeds the limit of Adobe Reader, which I found out to be 200 x 200 inch.
More info: here
I then attempted to scale the pdf to a size acceptable to Adobe.
Again I decided to rely on online tools , in particular I used these two:
As for the first converter, the conversion was successful, and "Adobe's
size error" disappeared, but still the attack does not work at all.
While as for the conversion to SodaPDF, I can say, after several attempts,
that even after the hypothetical conversion the "Adobe's size error" remains,
although clearly you can see in the file that there was some resizing work done,
although it would look pretty scrappy...
The two (resized) PDf can be viewed here::
In any case, it can be concluded by saying that this type of attack does not work when converted to PDF.
Since trying a similar attack didn't work, I decided to take a closer look at the css code of the
file that gave me the most satisfaction, the trick then should be encapsulated in these few lines?
I don't know, but I decided to play with it a little bit...
Let's try to analyze the css rules for a moment:
- display The display property specifies the display behavior (the type of rendering box) of an element.
- white-space The white-space CSS property sets how white space inside an element is handled.
- letter-spacing The letter-spacing CSS property sets the horizontal spacing behavior between text characters.
- line-height The line-height CSS property sets the height of a line box. It's commonly used to set the distance between lines of text.
- font-family The font-family property specifies the font for an element.
- font-size The font-size property sets the size of a font.
- border-width The CSS border-width properties allow you to specify width of an element's border.
- border-style The CSS border-style properties allow you to specify style of an element's border
- border-color The CSS border-color properties allow you to specify color of an element's border
I start by eliminating a couple of css properties that surely can't make a difference,
namely font-family and border-color (probably border-style should also be aliminated,
but since some borders are made of ASCII characters, for example the one made of dots,
i decided to keep it, for now). That leaves us with these lines of codeThat leaves us
with these lines of code:
display:inline-block;
white-space:pre;
letter-spacing:0;
line-height:1.4;
font-size:12px;
border-width:1px;
border-style:solid;
The display propiety accepts lots of values, in this case
the css rules use the in-line block value.
So I tried playing with the propieties a little bit by
changing some of them, which
i thought were more relevant, to see what happened.
Here you can try a demo to better understand how the "display" propiety works.
The display propiety has so many values available, I have tried most of them:
- inline-block (Is the main rule that I had previously used)
- inline (works, It would also seem to be a little better than the propiety block)
- block (also works)
- flex (this is interesting, it triggers a file truncation error, but it still works!)
- grid (impossible to convert to pdf, I made several attempts)
- inline-flex (same error as "flex", also works)
- inline-grid (same erros as "grid")
- inline-table (same error as "flex", but it seems to work in a weaker way)
- list-item (also works)
- run-in (also works)
- table (same error as "flex", also works)
- table-caption (also works)
- table-column-group (dont work, blank pdf)
- table-header-group (also works, same error as "flex")
- table-footer-group (also works, same error as "flex")
- table-row-group (same error as "flex", also works)
- table-cell (same error as "flex", also works)
- table-column (same error as "flex", also works)
- table-row (same error as "flex", also works)
- none (untested, as useless for the purpose)
- initial (also works)
- inherit (interesting, also works well even when the pdf has the screen resized)
These attempts led me to discover another small glitch, specifically using the flex and inherit values.
- flex = Displays an element as a block-level flex container
- inherit = Inherits this property from its parent element
In particular, both of these values, in addition to crashing the application,
sometimes left the Adobe window open in a crash (black screen).
Also, as you can see the process is not detected by the Windows task manager,
which would then appear to be already finished.
Then I used Process Monitor to better visualize the process, while running the glitch.
The process(es) shows up on ProcMon, but if you try to access it the program tells us
that it is unable to locate associted event in the visible items, this makes me assume
that the process has been killed, but for some reason the glitch persists, sounds interesting...
In any case at the moment I'm more interested in finding a combination of CSS/HTML rules that
will optimize the crash, in case I'll come back later to analyze the processes.
The inherit attribute, in addition to the glitch I just mentioned, has also been shown to work
well with the resized Adobe Reader window, which is why I decided to use this rule in subsequent tests,
to see if mixing it with other rules I can find the deadly combination I am looking for.
All the pdf's of the tests I did with this propiety can be found here.
The white-space propiety accepts 6 differents values:
normal, nowrap, pre, pre-wrap, pre-line, and break-spaces.
I exclude the normal value because it is irrelevant,
and also the pre value, because it was the one that had been used before.
and try to see what happens with the others.
Here you can try a demo to better understand how the "white-space" propiety works.
- nowrap (it gives truncation error, but works)
- pre-wrap (It seems to work more effectively)
- pre-line (It seems to work more effectively)
- break-spaces (also works)
The nowrap value is the first file in my tests that goes into
truncation error, but still manages to crash the application,
however other than that I have not noticed any particular improvement.
While using the pre-wrap and pre-line values, i noticed that they seem
to work more effectively than the previous ones, especially the pre-wrap value.
With the two values named above, one immediately notices an increase in Adobe's difficulty
in displaying the file, in fact in my tests it often took only a slight scroll to make it crash,
and sometimes even just opening the file and trying to close it.
But then why would they seem to work better?
If we analyze the table below, we see that pre values preserve lines
(that's how they manage not to go into truncation error, while those that collapse send Adobe into error).
The pre and pre-wrap values also preserve spaces and tabs ,perhaps that is why pre-wrap seems
to work better than pre-line. I will therefore use the pre-wrap value in future tests.
Actually this attribute also has global variables, but I have not tested them at the moment,
as i am satisfied with the pre-wrap value, and then i have already invested enough time so...
All the pdf's of the tests I did with this propiety can be found here.
The letter-spacing propiety accepts 3 differents types of values:
Keyword Values, Lenght Values, and Global Values.
Initially I tested all the combinations with the Keyboard & Global values, but I didn't notice
any particular improvement, so I played around a bit with the Lenght Values.
I then began to do several tests with letter spacings in both pixels and percentages
(both positive and negative numbers), initially priming the pixel measurements,
because they turn out to beless responsive than those expressed in %, at least in HTML,
as far as Adobe is concerned I intend to find out... Also, I mixed different fonts measurements(in px)
to see what was going on, and got some interesting results (although I haven't yet gotten what I'm looking for).
I really made many attempts which you can see here:
https://github.com/JonnyBanana/PDF_Scroll_ASCII_Crasher/tree/main/CASE%20STUDY/letter-spacing%20%26%20font-size
I really tried everything: inserting tiny fonts and multiplying divs (but I had conversion problems),
mixing wrong rules, with negative numbers, so that fonts overlapped, etc.
However, a couple of interesting glitches came out.
For example with this mix of rules:
display:inherit;
white-space:pre-wrap;
letter-spacing:-1px;
line-height:1.4;
font-size:1px;
border-width:1px;
border-style:solid;
The result is shown in the gif below:
As you can see the program immediately goes into glitch, displaying a red line that
automatically scrolls down, this allows the attack to always work even without mouse intervention!
In my tests it was always enough to wait a few seconds, and the crash happens simply by trying to close the application.
It also sometimes goes into a kind of loop, and starts over again with the red line scroll.
And so I was able to optimize the attachment a bit, although I would like more...
This PDF can be found here:
https://github.com/JonnyBanana/PDF_Scroll_ASCII_Crasher/blob/main/CASE%20STUDY/letter-spacing%20%26%20font-size/-1px-fontsize1px.pdf
Also trying with this mix of rules:
display:inherit;
white-space:pre-wrap;
letter-spacing:1000px;
line-height:1.4;
font-size:100px;
border-width:1px;
border-style:solid;
The previously recounted glitch recurred (black screen , persistent, process closed),
and clicking with the mouse to try to close the program I noticed that it opened a folder located
exactly down there. This gave me connfirmation of what I suspected, which was that the process
was closed, but the screen persisted even after closing the program, as a graphical glitch.
In subsequent tests I will use these two rule mixes,
mixing them further with other rules, and let's see what happens...
We then turn to the line-height property, that accept a lot of values types.
Fortunately, there is an inadvisable type of values in this propiety, namely em (%) values, which create character overlap.
More info here: https://developer.mozilla.org/en-US/docs/Web/CSS/line-height
And so, because I have already invested a lot of s time in testing, I decided to opt to play exclusively with % values.
The result, however, did not enhance the glitches, so I moved on, but I will still keep the em measures in this propiety,
since it is well known that one should not use them...
All the pdf's of the tests I did with this propiety can be found here.
All that remains then is to play around a bit with the border-width & border-style attributes.
The border-width atibute accepts a lots of values:
Since there are so many possibilities for now I will focus on playing on measurements in px , in em, and in cm.
So I made several attempts, which can be seen here:
https://github.com/JonnyBanana/PDF_Scroll_ASCII_Crasher/tree/main/CASE%20STUDY/border
Several graphic glitches have come out, and it is interesting to see
how with each change the graphic result is very different.
Here are some examples of the strangest ones:
__________________________________________________________________________________
However, apart from a lot of different graphic effects, i have not noticed any improvements over previous vesions,
the attack works (almost)all the time, and if you leave the pdf open for a few seconds the chances of success
rise to almost 100%. But unfortunately i have not yet achieved the effect i am looking for (instant crash of the app,
or better yet kernel panic of the system).
So I decide not to go further down this road, as there are too many possibilities to test,
better to study Adobe's defense systems a bit more. As you can easily imagine Adobe uses a sandbox to open files,
and examine them in a protected environment. But what else?
The info I was looking for can be found here: https://helpx.adobe.com/acrobat/using/overview-security-acrobat-pdfs.html
As you can see Adobe uses several protection techniques, this one is particularly interesting for the purpose:
https://helpx.adobe.com/acrobat/using/protected-view-feature-pdfs-windows.html#protected_view_feature_for_pdfs_windows_only
As you might imagine several "sandbox" measures are used. , which are turned on by default, but can still be turned off manually (or by script).
Sandbox protections enabled by default
Unfortunately, even after deactivating the sanbox protections I did not get , even this time, the desired result.
Sandbox protections deactivated
The only other security policy that I found interesting for the purpose is protection to javascript scripts:
https://helpx.adobe.com/acrobat/using/javascripts-pdfs-security-risk.html#javascripts_in_pdfs_as_a_security_risk
Adobe also has the "Enhanced security settings" enabled by default:
https://helpx.adobe.com/acrobat/using/enhanced-security-setting-pdfs.html#enhanced_security_setting_for_pdfs
Enhanced security setting enabled by default
Adobe's website states:
PDFs have evolved from static pages to complex documents with features such as interactive forms, multimedia content, scripting, and other capabilities. These features leave PDFs vulnerable to malicious scripts or actions that can damage your computer or steal data. Enhanced security lets you protect your computer against these threats by blocking or selectively permitting actions for trusted locations and files.
When enhanced security is enabled and a PDF tries to complete a restricted action from an untrusted location or file, a security warning appears. The type of warning depends on the action and your version of Acrobat or Reader. (See Security warnings.)
However, it must be said that by default I was not getting any security warning.
But still I decide to disable this protection as well, and also add the files i use for testing to the list of safe files.
Enhanced security setting deactivated
After this last move, security warnings appear, and the attack is a bit mitigated,
but not completely, and also the opening of the file occurs much more slowly, line by line,
thus making the attack less effective, but it's still work.
The only interesting thing for the purpose left is javascript protection:
https://helpx.adobe.com/acrobat/using/javascripts-pdfs-security-risk.html#javascripts_in_pdfs_as_a_security_risk
One could easily create a JavaScript script that loops over a visualization of a carefully selected
set of ascii characters (section "Some reasoning about the Image Files"").
But frankly, programming in javascript is pretty lousy for me....
Besides, i've already spent a lot of time on boring tests and i don't feel like getting bored again.
It may be that i will do it in the future, maybe...
First of all, as you can see, Adobe has created a temp file in the \AppData\local\Temp\acrord32_sbx\ folder.
And it reads the information from that file, I think it's sandbox protection.
An example of Adobe's temp file can be seen here:
https://github.com/JonnyBanana/PDF_Scroll_ASCII_Crasher/blob/main/CASE%20STUDY/sec/A9sl8bw3_40h7ca_62o.tmp
But of course the content of the file is unreadable.
I then applied some filters, to see at the registry and process level how Adobe behaves.
As you can see it initially opens the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice.
This path contains information about the default application used to open URL addresses of type "http". For example,
if you click on an "http" link in a document or on a Web site, the operating system will use the application specified
in this registry key to open the link. Changing this registry key may allow you to choose a different application
to open "http" links instead of the default one.For example, the Windows default browser settings are in this path.
The \Prodig subfolder contains information about the default application used to open URL addresses of type "http". For example,
if you click on an "http" link in a document or on a Web site, the operating system will use the application specified
in this registry key to open the link. Changing this registry key may allow you to choose a different application to open
"http" links instead of the default one.
After that, set a set of keys in the path HKEY_CURRENT_USER\Control Panel\Cursors\CursorBaseSize
The registry key you mentioned, \HKEY_CURRENT_USER\Control Panel\Cursors
contains information about the mouse cursor configuration for the current user.
For example, this registry key might contain information about the size and type of mouse cursor that will be used,
as well as on the position of the cursor on the screen.
I think that the Adobe Reader program uses the registry key \HKEY_CURRENT_USER\Control Panel\Cursors\CursorBaseSize
to store information about the mouse cursor size used by the user.
This information could be used by the program to ensure that the mouse cursor is displayed correctly when using the program
In fact having used so many ASCII characters I have dozens of such queries open.
So it would be interesting to play a little bit with this specific registry key and see what happens...
Another thing I went to see is how Adobe launches pdf files, and apparently it does it with the following command:
"C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --type=renderer /prefetch:1 "PATH_TO_PDF\file.pdf"
Adobe uses the "--type=renderer" and "/prefetch:1" command options to open pdf files.
It is likely that the Adobe Reader program uses the "--type=renderer" option to initiate a rendering process to display the contents
of a PDF file. In this way, the program can ensure that the content of the PDF file is displayed correctly and optimally for the user.
The "/prefetch:1" option could be used to start loading the content of the PDF file before the user actually opens it, in order to
reduce loading time and provide a better viewing experience. In general, using these options allows the Adobe Reader program to
efficiently handle PDF files and provide a good viewing experience for the user.
I then tried to launch the pdf by completely eliminating the two options:
start "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" "%USERPROFILE%\Desktop\Scroll_ASCII_Crasher.pdf"
But it didn't work, this is probably because calling the file C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe
via start command probably still reproduces the two options dubbed above, since you have to call the Adobe executable,
which will still open the pdf again with the two options.
I then did some testing with the --type option
Here are some of the values supported by the --type" option:
--type=renderer": starts a rendering process.
--type=gpu-process": starts a GPU process
--type=utility": starts a utility process
--type=zygote": starts a zygote process "--type=ppapi": starts a pp process
--type=browser": starts the main browser process
--type=gpu-broker": starts a GPU broker process
--type=crashpad-handler": starts an error-handling process
--type=nacl-loader": starts a loading process for Native Client
--type=service-manager": starts a service management process
--type=network": starts a network process
--type=ppapi-broker": starts a broker process for Pepper
--type=ppapi-flash": starts a Pepper flash process
--type=extension": starts an extension process
--type=profile-import": starts a profile import process
--type=service": starts a service process.
--type=audio-service": starts an audio service process
--type=cdm": starts a digital content management process
--type=gpu-sandbox": starts a GPU sandbox process
--type=in-process-gpu": starts an embedded GPU process
--type=installer": starts an installation process
--type=network-service": starts a network service process
--type=oobe": starts an initial configuration process
--type=profile-resetter": starts a profile resetting process
--type=renderer-sandbox": starts a rendering sandbox process
--type=sandboxed-process": starts a sandbox process
--type=snapshot-service": starts a snapshot service process
--type=speech-service": starts a speech recognition service process
--type=tracing": starts a tracing process
--type=viz-service": starts a visualization service process.
I've only tried a few, but you'd have to do some attempts in the future, there's to say that not all of them
are accepted as Adobe commands, but as already mentioned I did just a couple of attempts to see what happened.
While the /prefetch: option does not accept any parameter (at least from what they say on Google, confirmed later by GPT Chat),
or rather it only accepts the path to the file to be launched, but no numeric parameters, neither true nor false (1 & 0),
so it is very strange that it has parameter 1, it could be an error...
The last interesting thing I noticed were a number of BUFFER OVERFLOWS, on different dll: ntdl.dll, KernelBase.dll, kernel32.dll, and more.
In fact, with a simple google search you can find several examples of buffer overflows to Adobe dlls.
Some Examples:
https://vulners.com/saint/SAINT:87E25D27930DA4EC4B02D093DE63B91E
https://support.ixiacom.com/strikes/exploits/clientside/cve_2014_8457_adobe_reader_rectangle_bo.xml
I will return in the future to analyze the dlls that I have pinned precedently.
In the end I wasn't able to optimize the attack to the extent they hope, but I learned several interesting things and that's enough...
Anyway, I posted this study here on Github more for me than anything else (to remember the steps, etc.),
and then because maybe someone can find interesting insights to do something good with it.
If I have time I will come back to it in the future, especially on the dlls, and process analysis.
All the files i used for the tests can be found in the "CASE STUDY" folder.