Merge pull request #1386 from j-t-1/doc

Cosmetic changes to documentation

doc/source/symbol-tables.rst

@@ -25,9 +25,9 @@ as long as the symbol files stay in the same location.
 Windows symbol tables
 ---------------------
 
-For Windows systems, Volatility accepts a string made up of the GUID and Age of the required PDB file.  It then
+For Windows systems, Volatility accepts a string made up of the GUID and age of the required PDB file.  It then
 searches all files under the configured symbol directories under the windows subdirectory.  Any that contain metadata
-which matches the pdb name and GUID/age (or any compressed variant) will be used.  If such a symbol table cannot be found, then
+which matches the PDB name and GUID/age (or any compressed variant) will be used.  If such a symbol table cannot be found, then
 the associated PDB file will be downloaded from Microsoft's Symbol Server and converted into the appropriate JSON
 format, and will be saved in the correct location.
 
@@ -54,8 +54,8 @@ most Volatility plugins.  Note that in most linux distributions, the standard ke
 and the kernel with debugging information is stored in a package that must be acquired separately.
 
 A generic table isn't guaranteed to produce accurate results, and would reduce the number of structures
-that all plugins could rely on.  As such, and because linux kernels with different configurations can produce different structures,
-volatility 3 requires that the banners in the JSON file match the banners found in the image *exactly*, not just the version
+that all plugins could rely on.  As such, and because Linux kernels with different configurations can produce different structures,
+Volatility 3 requires that the banners in the JSON file match the banners found in the image *exactly*, not just the version
 number.  This can include elements such as the compilation time and even the version of gcc used for the compilation.
 The exact match is required to ensure that the results volatility returns are accurate, therefore there is no simple means
 provided to get the wrong JSON ISF file to easily match.
@@ -63,8 +63,8 @@ provided to get the wrong JSON ISF file to easily match.
 To determine the string for a particular memory image, use the `banners` plugin.  Once the specific banner is known,
 try to locate that exact kernel debugging package for the operating system.  Unfortunately each distribution provides
 its debugging packages under different package names and there are so many that the distribution may not keep all old
-versions of the debugging symbols, and therefore **it may not be possible to find the right symbols to analyze a linux
-memory image with volatility**.  With Macs there are far fewer kernels and only one distribution, making it easier to
+versions of the debugging symbols, and therefore **it may not be possible to find the right symbols to analyze a Linux
+memory image with Volatility**.  With Macs there are far fewer kernels and only one distribution, making it easier to
 ensure that the right symbols can be found.
 
 Once a kernel with debugging symbols/appropriate DWARF file has been located, `dwarf2json <https://github.com/volatilityfoundation/dwarf2json>`_ will convert it into an
@@ -75,7 +75,7 @@ symbol offsets within the DWARF data, which dwarf2json can extract into the JSON
 
 The banners available for volatility to use can be found using the `isfinfo` plugin, but this will potentially take a
 long time to run depending on the number of JSON files available.  This will list all the JSON (ISF) files that
-volatility3 is aware of, and for linux/mac systems what banner string they search for.  For volatility to use the JSON
+Volatility 3 is aware of, and for linux/mac systems what banner string they search for.  For volatility to use the JSON
 file, the banners must match exactly (down to the compilation date).
 
 .. note::

doc/source/vol2to3.rst

@@ -27,7 +27,7 @@ The object model has changed as well, objects now inherit directly from their Py
 object is actually a Python integer (and has all the associated methods, and can be used wherever a normal int could).
 In Volatility 2, a complex proxy object was constructed which tried to emulate all the methods of the host object, but
 ultimately it was a different type and could not be used in the same places (critically, it could make the ordering of
-operations important, since a + b might not work, but b + a might work fine).
+operations important, since x + y might not work, but y + x might work fine).
 
 Volatility 3 has also had significant speed improvements, where Volatility 2 was designed to allow access to live memory
 images and situations in which the underlying data could change during the run of the plugin, in Volatility 3 the data
@@ -36,11 +36,11 @@ This was because live memory analysis was barely ever used, and this feature cou
 re-read many times over for no benefit (particularly since each re-read could result in many additional image reads
 from following page table translations).
 
-Finally, in order to provide Volatility specific information without impact on the ability for structures to have members
+Further, in order to provide Volatility specific information without impact on the ability for structures to have members
 with arbitrary names, all the metadata about the object (such as its layer or offset) have been moved to a read-only :py:meth:`~volatility3.framework.interfaces.objects.ObjectInterface.vol`
 dictionary.
 
-Further the distinction between a :py:class:`~volatility3.framework.interfaces.objects.Template` (the thing that
+Finally, the distinction between a :py:class:`~volatility3.framework.interfaces.objects.Template` (the thing that
 constructs an object) and the :py:class:`Object <volatility3.framework.interfaces.objects.ObjectInterface>` itself has
 been made more explicit.  In Volatility 2, some information (such as size) could only be determined from a constructed object,
 leading to instantiating a template on an empty buffer, just to determine the size.  In Volatility 3, templates contain
@@ -56,15 +56,14 @@ Volatility 2 were strictly limited to a stack, one on top of one other.  In Vola
 
 Automagic
 ---------
-In Volatility 2, we often tried to make this simpler for both users and developers.  This resulted in something was
-referred to as automagic, in that it was magic that happened automatically.  We've now codified that more, so that the
+In Volatility 2, we often tried to make this simpler for both users and developers.  This resulted in something referred to as automagic, in that it was magic that happened automatically.  We've now codified that more, so that the
 automagic processes are clearly defined and can be enabled or disabled as necessary for any particular run.  We also
 included a stacker automagic to emulate the most common feature of Volatility 2, automatically stacking address spaces
 (now translation layers) on top of each other.
 
-By default the automagic chosen to be run are determined based on the plugin requested, so that linux plugins get linux
-specific automagic and windows plugins get windows specific automagic.  This should reduce unnecessarily searching for
-linux kernels in a windows image, for example.  At the moment this is not user configurableS.
+By default the automagic chosen to be run are determined based on the plugin requested, so that Linux plugins get Linux
+specific automagic and Windows plugins get Windows specific automagic.  This should reduce unnecessarily searching for
+Linux kernels in a Windows image, for example.  At the moment this is not user configurable.
 
 Searching and Scanning
 ----------------------

doc/source/volshell.rst

@@ -144,12 +144,12 @@ We can provide arguments via the `dpo` method call:
     356	4	smss.exe	0x8c0bccf8d040	3	-	N/A	False	2021-03-13 17:25:33.000000 	N/A	Disabled
     ...
 
-Here's we've provided the kernel name that was requested by the volshell plugin itself (the generic volshell does not
+Here we've provided the kernel name that was requested by the volshell plugin itself (the generic volshell does not
 load a kernel module, and instead only has a TranslationLayerRequirement).
 A different module could be created and provided instead.  The context used
 by the `dpo` method is always `context`.
 
-Instead of print the results directly to screen, they can be gathered into a TreeGrid objects for direct access by
+Instead of printing the results directly to screen, they can be gathered into a TreeGrid objects for direct access by
 using the `generate_treegrid` or `gt` command.
 
 ::