mirror of
https://github.com/NationalSecurityAgency/ghidra.git
synced 2026-08-08 07:40:39 -09:00
scaling images
This commit is contained in:
caheckman
@@ -146,7 +146,7 @@ task buildDecompilerHelpPdf(type: Exec) {
|
||||
echo '** Checking if required executables are installed. **'
|
||||
which fop 2>&1
|
||||
which xsltproc 2>&1
|
||||
rm -f decompileplugin.fo decompileplugin.pdf 2>&1
|
||||
rm -f decompileplugin.fo decompileplugin.pdf decompileplugin_withscaling.xml 2>&1
|
||||
rm -rf ./images 2>&1
|
||||
mkdir -p ./images 2>&1
|
||||
cp $installHelpPoint/topics/DecompilePlugin/images/*.png ./images 2>&1
|
||||
@@ -154,7 +154,8 @@ task buildDecompilerHelpPdf(type: Exec) {
|
||||
cp $installHelpPoint/shared/*.png ./images 2>&1
|
||||
|
||||
echo '** Building decompileplugin.fo **'
|
||||
xsltproc --output ./decompileplugin.fo decompileplugin_pdf.xsl decompileplugin.xml 2>&1
|
||||
xsltproc --output ./decompileplugin_withscaling.xml --stringparam profile.condition "withscaling" /usr/share/sgml/docbook/xsl-stylesheets/profiling/profile.xsl decompileplugin.xml 2>&1
|
||||
xsltproc --output ./decompileplugin.fo decompileplugin_pdf.xsl decompileplugin_withscaling.xml 2>&1
|
||||
|
||||
echo '** Building decompileplugin.pdf **'
|
||||
fop decompileplugin.fo decompileplugin.pdf 2>&1
|
||||
|
||||
@@ -8,7 +8,8 @@
|
||||
<title>Decompiler</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="images/DecompWindow.png" width="100%" contentwidth="11.0in" contentdepth="4.301in" align="center"/>
|
||||
<imagedata condition="noscaling" fileref="images/DecompWindow.png" width="100%" contentwidth="1000px" contentdepth="391px" align="center"/>
|
||||
<imagedata condition="withscaling" fileref="images/DecompWindow.png" width="100%" contentwidth="6.0in" contentdepth="2.346in" align="center"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
<section id="Overview">
|
||||
@@ -42,10 +43,10 @@
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="ShowWindow">
|
||||
<title>Showing the Decompiler Window</title>
|
||||
<sect2 id="TriggerDecompilation">
|
||||
<title>Decompiling a Function</title>
|
||||
<para>
|
||||
From the Code Browser, either:
|
||||
From the Code Browser, to open a Decompiler window, either:
|
||||
<informalexample>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem>
|
||||
@@ -64,10 +65,21 @@
|
||||
<emphasis>current address</emphasis>. The address is set typically by left-clicking in the Listing window,
|
||||
or invoking the <emphasis>Goto</emphasis> command (pressing the 'g' key) and manually entering
|
||||
the address or some other label, but the Decompiler window
|
||||
follows any type of navigation in the Code Browser. Navigating to a new address
|
||||
or making a change to the underlying Program causes the the window to (re)decompile and display
|
||||
the new function.
|
||||
follows any type of navigation in the Code Browser, triggering decompilation of the new function
|
||||
being displayed.
|
||||
</para>
|
||||
<tip>
|
||||
Any change to the function or Program made while using Ghidra causes the window to automatically
|
||||
redecompile the function it is displaying, to incorporate the new information. Changes include (but
|
||||
aren't limited to):
|
||||
<itemizedlist mark='none'>
|
||||
<listitem><link linkend="ActionRenameVariable">Renaming Variables</link></listitem>
|
||||
<listitem><link linkend="ActionRetypeVariable">Setting Data-types</link></listitem>
|
||||
<listitem><link linkend="ActionComments">Commenting</link></listitem>
|
||||
<listitem><link linkend="ActionEditSignature">Setting a Function's Prototype</link></listitem>
|
||||
</itemizedlist>
|
||||
Users can control decompilation in a wide variety of ways, see <xref linkend="DecompilerAnnotations"/>.
|
||||
</tip>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="Capabilities">
|
||||
@@ -78,19 +90,18 @@
|
||||
<informalexample>
|
||||
<itemizedlist mark='bullet'>
|
||||
<listitem>
|
||||
<emphasis role="bold">Recovers Expressions</emphasis>: The
|
||||
<emphasis role="bold">Recovering Expressions</emphasis>: The
|
||||
decompiler does full data-flow analysis which allows it to
|
||||
perform slicing on functions. The most tangible benefit to the
|
||||
user is that complicated expressions, which have been split into
|
||||
perform slicing on functions: complicated expressions, which have been split into
|
||||
distinct operations/instructions and then mixed together with
|
||||
other instructions by the compiling/optimizing process, are
|
||||
reconstituted into a single expression again by the decompiler.
|
||||
reconstituted back into a single line.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis role="bold">Recovers High-Level Scoped
|
||||
<emphasis role="bold">Recovering High-Level Scoped
|
||||
Variables</emphasis>: The decompiler understands how compilers
|
||||
use processor stacks and registers to implement variables with
|
||||
different scopes within a function. Data-flow allows it to
|
||||
different scopes within a function. Data-flow analysis allows it to
|
||||
follow what was originally a single variable as it moves from
|
||||
the stack, into a register, into a different register, etc. Thus
|
||||
it can effectively recover the original programs concept of a
|
||||
@@ -98,13 +109,13 @@
|
||||
in the output.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis role="bold">Recovers Function Parameters</emphasis>:
|
||||
<emphasis role="bold">Recovering Function Parameters</emphasis>:
|
||||
The decompiler understands the parameter passing conventions of
|
||||
the compiler and can reconstruct the form of the original
|
||||
function call.
|
||||
the compiler and can reconstruct the original form of
|
||||
function calls.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis role="bold">Uses Data-type, Name, and Signature
|
||||
<emphasis role="bold">Using Data-type, Name, and Signature
|
||||
Annotations</emphasis>: The decompiler automatically pulls in
|
||||
all the different data types and variable names that the user
|
||||
has applied to functions, and the C output is altered to reflect
|
||||
@@ -114,18 +125,15 @@
|
||||
appropriate quoted strings, etc.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis role="bold">Performs Local Data-type
|
||||
Propagation</emphasis>: In the absence of information, the
|
||||
decompiler does its best to fill in information from what it
|
||||
does know. Variables whose data-type has not been explicitly
|
||||
labeled by the user can often by recovered by seeing how the
|
||||
variable is used or by allowing the known data-types to
|
||||
propagate.
|
||||
<emphasis role="bold">Propagating Local Data-types</emphasis>:
|
||||
The decompiler infers the data-type of unlabeled variables
|
||||
by propagating information from other sources throughout a function.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis role="bold">Can be used to Automatically Recover
|
||||
Structure Fields</emphasis>: The decompiler can be leveraged to
|
||||
recover references to a structure.
|
||||
<emphasis role="bold">Recovering Structure Definitions</emphasis>:
|
||||
The decompiler can be used to create structures that match the usage
|
||||
pattern of particular functions and variables, automatically discovering
|
||||
component offsets and data-types.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</informalexample>
|
||||
@@ -3305,7 +3313,8 @@
|
||||
<para>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="images/EditFunctionSignature.png" width="100%" contentwidth="7.568in" contentdepth="5.874in" align="center"/>
|
||||
<imagedata condition="noscaling" fileref="images/EditFunctionSignature.png" width="100%" contentwidth="688px" contentdepth="534px" align="center"/>
|
||||
<imagedata condition="withscaling" fileref="images/EditFunctionSignature.png" width="100%" contentwidth="5.375in" contentdepth="4.172in" align="center"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
The dialog provides detailed control over elements like
|
||||
@@ -3373,7 +3382,8 @@
|
||||
variable <emphasis>a</emphasis> is selected when Def-Use is chosen.
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="images/Defuse.png" width="100%" contentwidth="3.8462in" contentdepth="2.8558in" align="center"/>
|
||||
<imagedata condition="noscaling" fileref="images/Defuse.png" width="100%" contentwidth="400px" contentdepth="297px" align="center"/>
|
||||
<imagedata condition="withscaling" fileref="images/Defuse.png" width="100%" contentwidth="3.125in" contentdepth="2.320in" align="center"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</para></listitem>
|
||||
@@ -3391,7 +3401,8 @@
|
||||
<emphasis>max_alpha</emphasis>, is selected when Forward Slice is chosen.
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="images/ForwardSlice.png" width="100%" contentwidth="4.8077in" contentdepth="2.6923in" align="center"/>
|
||||
<imagedata condition="noscaling" fileref="images/ForwardSlice.png" width="100%" contentwidth="500px" contentdepth="280px" align="center"/>
|
||||
<imagedata condition="withscaling" fileref="images/ForwardSlice.png" width="100%" contentwidth="3.906in" contentdepth="2.187in" align="center"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</para></listitem>
|
||||
@@ -3604,7 +3615,7 @@
|
||||
</para>
|
||||
<para>
|
||||
The action brings up a dialog prepopulated with the
|
||||
current name of the field. Editing and confirming this dialog immediately changes
|
||||
current name of the field. Editing and confirming this dialog immediately changes the
|
||||
field's name in its corresponding structure definition. The dialog enforces unique field names.
|
||||
</para>
|
||||
<para>
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
<div class="titlepage"><div><div><h1 class="title">
|
||||
<a name="DecompilerIntro"></a>Decompiler</h1></div></div></div>
|
||||
|
||||
<div class="mediaobject" align="center"><table border="0" summary="manufactured viewport for HTML img" style="cellpadding: 0; cellspacing: 0;" width="100%"><tr><td align="center"><img src="images/DecompWindow.png" align="middle" width="990" height="387"></td></tr></table></div>
|
||||
<div class="mediaobject" align="center"><table border="0" summary="manufactured viewport for HTML img" style="cellpadding: 0; cellspacing: 0;" width="100%"><tr><td align="center"><img src="images/DecompWindow.png" align="middle" width="1000" height="391"></td></tr></table></div>
|
||||
<div class="section">
|
||||
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
|
||||
<a name="Overview"></a>Overview</h2></div></div></div>
|
||||
@@ -54,10 +54,10 @@
|
||||
|
||||
<div class="sect2">
|
||||
<div class="titlepage"><div><div><h3 class="title">
|
||||
<a name="ShowWindow"></a>Showing the Decompiler Window</h3></div></div></div>
|
||||
<a name="TriggerDecompilation"></a>Decompiling a Function</h3></div></div></div>
|
||||
|
||||
<p>
|
||||
From the Code Browser, either:
|
||||
From the Code Browser, to open a Decompiler window, either:
|
||||
</p>
|
||||
<div class="informalexample">
|
||||
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: bullet; ">
|
||||
@@ -78,10 +78,27 @@
|
||||
<span class="emphasis"><em>current address</em></span>. The address is set typically by left-clicking in the Listing window,
|
||||
or invoking the <span class="emphasis"><em>Goto</em></span> command (pressing the 'g' key) and manually entering
|
||||
the address or some other label, but the Decompiler window
|
||||
follows any type of navigation in the Code Browser. Navigating to a new address
|
||||
or making a change to the underlying Program causes the the window to (re)decompile and display
|
||||
the new function.
|
||||
follows any type of navigation in the Code Browser, triggering decompilation of the new function
|
||||
being displayed.
|
||||
</p>
|
||||
<div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Tip">
|
||||
<tr>
|
||||
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="../../shared/tip.png"></td>
|
||||
<th align="left"></th>
|
||||
</tr>
|
||||
<tr><td align="left" valign="top">
|
||||
Any change to the function or Program made while using Ghidra causes the window to automatically
|
||||
redecompile the function it is displaying, to incorporate the new information. Changes include (but
|
||||
aren't limited to):
|
||||
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: none; ">
|
||||
<li class="listitem" style="list-style-type: none"><a class="link" href="DecompilerWindow.html#ActionRenameVariable" title="Rename Variable">Renaming Variables</a></li>
|
||||
<li class="listitem" style="list-style-type: none"><a class="link" href="DecompilerWindow.html#ActionRetypeVariable" title="Retype Variable">Setting Data-types</a></li>
|
||||
<li class="listitem" style="list-style-type: none"><a class="link" href="DecompilerWindow.html#ActionComments" title="Comments">Commenting</a></li>
|
||||
<li class="listitem" style="list-style-type: none"><a class="link" href="DecompilerWindow.html#ActionEditSignature" title="Edit Function Signature">Setting a Function's Prototype</a></li>
|
||||
</ul></div>
|
||||
Users can control decompilation in a wide variety of ways, see <a class="xref" href="DecompilerAnnotations.html" title="Program Annotations Affecting the Decompiler"><i>Program Annotations Affecting the Decompiler</i></a>.
|
||||
</td></tr>
|
||||
</table></div>
|
||||
</div>
|
||||
|
||||
<div class="sect2">
|
||||
@@ -95,19 +112,18 @@
|
||||
<div class="informalexample">
|
||||
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: bullet; ">
|
||||
<li class="listitem" style="list-style-type: disc">
|
||||
<span class="bold"><strong>Recovers Expressions</strong></span>: The
|
||||
<span class="bold"><strong>Recovering Expressions</strong></span>: The
|
||||
decompiler does full data-flow analysis which allows it to
|
||||
perform slicing on functions. The most tangible benefit to the
|
||||
user is that complicated expressions, which have been split into
|
||||
perform slicing on functions: complicated expressions, which have been split into
|
||||
distinct operations/instructions and then mixed together with
|
||||
other instructions by the compiling/optimizing process, are
|
||||
reconstituted into a single expression again by the decompiler.
|
||||
reconstituted back into a single line.
|
||||
</li>
|
||||
<li class="listitem" style="list-style-type: disc">
|
||||
<span class="bold"><strong>Recovers High-Level Scoped
|
||||
<span class="bold"><strong>Recovering High-Level Scoped
|
||||
Variables</strong></span>: The decompiler understands how compilers
|
||||
use processor stacks and registers to implement variables with
|
||||
different scopes within a function. Data-flow allows it to
|
||||
different scopes within a function. Data-flow analysis allows it to
|
||||
follow what was originally a single variable as it moves from
|
||||
the stack, into a register, into a different register, etc. Thus
|
||||
it can effectively recover the original programs concept of a
|
||||
@@ -115,13 +131,13 @@
|
||||
in the output.
|
||||
</li>
|
||||
<li class="listitem" style="list-style-type: disc">
|
||||
<span class="bold"><strong>Recovers Function Parameters</strong></span>:
|
||||
<span class="bold"><strong>Recovering Function Parameters</strong></span>:
|
||||
The decompiler understands the parameter passing conventions of
|
||||
the compiler and can reconstruct the form of the original
|
||||
function call.
|
||||
the compiler and can reconstruct the original form of
|
||||
function calls.
|
||||
</li>
|
||||
<li class="listitem" style="list-style-type: disc">
|
||||
<span class="bold"><strong>Uses Data-type, Name, and Signature
|
||||
<span class="bold"><strong>Using Data-type, Name, and Signature
|
||||
Annotations</strong></span>: The decompiler automatically pulls in
|
||||
all the different data types and variable names that the user
|
||||
has applied to functions, and the C output is altered to reflect
|
||||
@@ -131,18 +147,15 @@
|
||||
appropriate quoted strings, etc.
|
||||
</li>
|
||||
<li class="listitem" style="list-style-type: disc">
|
||||
<span class="bold"><strong>Performs Local Data-type
|
||||
Propagation</strong></span>: In the absence of information, the
|
||||
decompiler does its best to fill in information from what it
|
||||
does know. Variables whose data-type has not been explicitly
|
||||
labeled by the user can often by recovered by seeing how the
|
||||
variable is used or by allowing the known data-types to
|
||||
propagate.
|
||||
<span class="bold"><strong>Propagating Local Data-types</strong></span>:
|
||||
The decompiler infers the data-type of unlabeled variables
|
||||
by propagating information from other sources throughout a function.
|
||||
</li>
|
||||
<li class="listitem" style="list-style-type: disc">
|
||||
<span class="bold"><strong>Can be used to Automatically Recover
|
||||
Structure Fields</strong></span>: The decompiler can be leveraged to
|
||||
recover references to a structure.
|
||||
<span class="bold"><strong>Recovering Structure Definitions</strong></span>:
|
||||
The decompiler can be used to create structures that match the usage
|
||||
pattern of particular functions and variables, automatically discovering
|
||||
component offsets and data-types.
|
||||
</li>
|
||||
</ul></div>
|
||||
</div>
|
||||
|
||||
@@ -612,7 +612,7 @@
|
||||
</p>
|
||||
<p>
|
||||
</p>
|
||||
<div class="mediaobject" align="center"><table border="0" summary="manufactured viewport for HTML img" style="cellpadding: 0; cellspacing: 0;" width="100%"><tr><td align="center"><img src="images/EditFunctionSignature.png" align="middle" width="681" height="529"></td></tr></table></div>
|
||||
<div class="mediaobject" align="center"><table border="0" summary="manufactured viewport for HTML img" style="cellpadding: 0; cellspacing: 0;" width="100%"><tr><td align="center"><img src="images/EditFunctionSignature.png" align="middle" width="688" height="534"></td></tr></table></div>
|
||||
<p>
|
||||
The dialog provides detailed control over elements like
|
||||
</p>
|
||||
@@ -683,7 +683,7 @@
|
||||
In the following example, the token representing the first write to the
|
||||
variable <span class="emphasis"><em>a</em></span> is selected when Def-Use is chosen.
|
||||
</p>
|
||||
<div class="mediaobject" align="center"><table border="0" summary="manufactured viewport for HTML img" style="cellpadding: 0; cellspacing: 0;" width="100%"><tr><td align="center"><img src="images/Defuse.png" align="middle" width="346" height="257"></td></tr></table></div>
|
||||
<div class="mediaobject" align="center"><table border="0" summary="manufactured viewport for HTML img" style="cellpadding: 0; cellspacing: 0;" width="100%"><tr><td align="center"><img src="images/Defuse.png" align="middle" width="400" height="297"></td></tr></table></div>
|
||||
<p>
|
||||
</p>
|
||||
</dd>
|
||||
@@ -699,7 +699,7 @@
|
||||
In the following example, the token <span class="emphasis"><em>b</em></span>, the output of
|
||||
<span class="emphasis"><em>max_alpha</em></span>, is selected when Forward Slice is chosen.
|
||||
</p>
|
||||
<div class="mediaobject" align="center"><table border="0" summary="manufactured viewport for HTML img" style="cellpadding: 0; cellspacing: 0;" width="100%"><tr><td align="center"><img src="images/ForwardSlice.png" align="middle" width="433" height="242"></td></tr></table></div>
|
||||
<div class="mediaobject" align="center"><table border="0" summary="manufactured viewport for HTML img" style="cellpadding: 0; cellspacing: 0;" width="100%"><tr><td align="center"><img src="images/ForwardSlice.png" align="middle" width="500" height="280"></td></tr></table></div>
|
||||
<p>
|
||||
</p>
|
||||
</dd>
|
||||
@@ -914,7 +914,7 @@
|
||||
</p>
|
||||
<p>
|
||||
The action brings up a dialog prepopulated with the
|
||||
current name of the field. Editing and confirming this dialog immediately changes
|
||||
current name of the field. Editing and confirming this dialog immediately changes the
|
||||
field's name in its corresponding structure definition. The dialog enforces unique field names.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
Reference in New Issue
Block a user