Page Menu
Home
Xreate
Search
Configure Global Search
Log In
Docs
Questions
Repository
Issues
Patches
Internal API
Files
F2731030
exploitation.xml
No One
Temporary
Actions
Download File
Edit File
Delete File
View Transforms
Subscribe
Mute Notifications
Subscribers
None
File Metadata
Details
File Info
Storage
Attached
Created
Sat, Mar 14, 3:06 AM
Size
24 KB
Mime Type
text/xml
Expires
Mon, Mar 16, 3:06 AM (1 d, 16 h)
Engine
blob
Format
Raw Data
Handle
243790
Attached To
rXR Xreate
exploitation.xml
View Options
<?xml version="1.0" encoding="UTF-8"?>
<chapter version="5.1" xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xila="http://www.w3.org/2001/XInclude/local-attributes"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:trans="http://docbook.org/ns/transclusion"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:m="http://www.w3.org/1998/Math/MathML"
xmlns:html="http://www.w3.org/1999/xhtml"
xmlns:db="http://docbook.org/ns/docbook">
<?xxe-sn 26yv439af40 1?>
<title><?xxe-sn 26yv439af40 2?>Exploitation</title>
<para><?xxe-sn 26yv439af40 6?>This chapter discusses <emphasis><?xxe-sn 26yv439af40 7?>exploiting</emphasis>
external resources, such as files, as a particular instance of a
<emphasis><?xxe-sn 26yv439af40 8?>side effects</emphasis> problem that
inevitably stems from an interaction with the outside world. Unlike <link
xlink:href="/d/virtualization/"><?xxe-sn 295bzzou9kw 2?>virtualization</link>,
another topic that deals with I/O, exploitation approaches the subject from
a different angle — it is concerned with <emphasis><?xxe-sn 26yv439af40 x?>order
of operations</emphasis>, a sequence in which different clients jointly use
the same resource, and it deals with corresponding difficulties, e.g.
ensures proper initialization of a resource before its actual usage.</para>
<section>
<?xxe-sn 29je46abuev -wunr7fl0rw8v?>
<title><?xxe-sn 29je46abuev -wunr7fl0rw8u?>Syntax</title>
<section>
<?xxe-sn 29je46abuev -wunr7fl0rw8s?>
<title><?xxe-sn 29je46abuev -wunr7fl0rw8r?>Annotations</title>
<synopsis><?xxe-sn 29je46abuev -wunr7fl0rw8q?>SYNTAX:
**use**(//resource-id//)
**init**(//resource-id//)</synopsis>
<itemizedlist>
<?xxe-sn 29je46abuev -wunr7fl0rw8p?>
<listitem>
<?xxe-sn 29je46abuev -wunr7fl0rw8o?>
<para><?xxe-sn 29je46abuev -wunr7fl0rw8n?><emphasis><?xxe-sn 29je46abuev -wunr7fl0rw8m?>resource-id</emphasis>
— user-defined resource identifier</para>
</listitem>
</itemizedlist>
<para><?xxe-sn 29je46abuev -wunr7fl0rw8l?>Annotates a function or code
block as such that exploits resource <emphasis><?xxe-sn 29je46abuev -wunr7fl0rw8k?>resource-id</emphasis>.</para>
</section>
<section>
<?xxe-sn 29je46abuev -wunr7fl0rw8j?>
<title><?xxe-sn 29je46abuev -wunr7fl0rw8i?>Guards</title>
<synopsis><?xxe-sn 29je46abuev -wunr7fl0rw8h?>SYNTAX:
**exploitation(init)**
**exploitation(none)**</synopsis>
<para><?xxe-sn 29je46abuev -wunr7fl0rw8g?>Specializations that are
recognized by exploitation reasoning. Each specialization corresponds to
an initialization strategy:</para>
<itemizedlist>
<?xxe-sn 29je46abuev -wunr7fl0rw8f?>
<listitem>
<?xxe-sn 29je46abuev -wunr7fl0rw8e?>
<para><?xxe-sn 29je46abuev -wunr7fl0rw8d?><code><?xxe-sn 29je46abuev -wunr7fl0rw8a?>exploitation(init)</code>
is expected to perform actual resource initialization.</para>
</listitem>
<listitem>
<?xxe-sn 29je46abuev -wunr7fl0rw8c?>
<para><?xxe-sn 29je46abuev -wunr7fl0rw8b?><code><?xxe-sn 29je46abuev -wunr7fl0rw89?>exploitation(none)</code>
is expected to do nothing as initialization is either not necessary
or done elsewhere.</para>
</listitem>
</itemizedlist>
</section>
</section>
<section>
<?xxe-sn 26yv439af40 3?>
<title><?xxe-sn 26yv439af40 4?>Background</title>
<para><?xxe-sn 26yv439af40 b?>In software engineering, the idea to avoid
side effects has received considerable traction. Indeed, side effects are
something that is hard to take into account, and thus programs that have
side effects are inherently unsafe, so best coding practices rightfully
suggest to isolate the code that produces side effects as much as
possible. It is so called pure functional languages whose philosophy goes
even further and frames side effects as something opposite of "pure" and
built around effectless computations, to the point that some languages'
design itself includes side effects producing constructs, such as I/O,
describing them as an afterthought, as something almost
unnecessary.</para>
<remark><?xxe-sn 2eplydoeos0 pu35zrt1aby9?>Я тут взял на себя смелость
подредактировать последнее предложение, посмотри внимательно - все ли я
правильно понял</remark>
<para><?xxe-sn 26yv439af40 c?>However, in reality the opposite is true, as
most applications' sole responsibility is to communicate with the "outside
world", reacting to the external events and changing the "world's state"
accordingly. As a consequence, side effects usually are the
<emphasis><?xxe-sn 26yv439af40 d?>only</emphasis> important effects
produced by a program, and they surely deserve a first class support from
a programming language and justify the efforts to develop an approach to
alleviate the related safety and performance concerns.</para>
</section>
<section>
<?xxe-sn 26yv439af40 z?>
<title><?xxe-sn 26yv439af40 10?>Exploitation Plan</title>
<para><?xxe-sn 26yv439af40 12?>One complexity with taking side effects
into account is that the final result depends on an <emphasis><?xxe-sn 28ivhnywem8 1?>exact
order of operations</emphasis>. For many techniques, this harshly impacts
both performance and safety, e.g. caching or parallelization can neither
be automatically performed nor validated since they are based on various
degrees of reordering or deal with possibly undetermined beforehand order
of execution.</para>
<remark><?xxe-sn 2fs606w84j4 pu35zrt1aby9?>Мне не очень нравится фраза
"deal with possibly undetermined beforehand order of execution". Выглядит
очень громоздко. Может, лучше сказать "or are connected with such an order
of execution that was not determined beforehand".</remark>
<para><?xxe-sn 28ivhnywem8 2?>In this chapter, it is assumed that final
effects of execution are fully defined by <emphasis><?xxe-sn 28ivhnywem8 3?>exploitation
path</emphasis> — for a particular code path that can occur during
execution, it is its part consisting of only relevant code blocks., i.e.
those that deal with an exploited resource. Other (unannotated) code
blocks are assumed to not produce exploitation effects, so they are
excluded from consideration. Thus reasoning about effects is reduced to
considering all possible exploitation paths, checking if they meet certain
requirements that define valid exploitation, and making corrections if
needed and possible.</para>
<para><?xxe-sn 26yv439af40 13?>The result of the reasoning is called
<emphasis><?xxe-sn 26yv439af40 14?>exploitation plan</emphasis> — a
specification that defines the exact order and strategy of using a given
resource in order to comply with imposed requirements.</para>
<para><?xxe-sn 26yv439af40 15?>With all above said, the discussed approach
can be presented as follows:</para>
<itemizedlist>
<?xxe-sn 26yv439af40 16?>
<listitem>
<?xxe-sn 26yv439af40 17?>
<para><?xxe-sn 26yv439af40 18?>Annotations are used to express certain
aspects of side effects to enable further reasoning. They indicate the
code blocks that deal with a resource as well as provide additional
information about how exactly it is exploited, e.g. using,
initializing or deinitializing the resource.</para>
</listitem>
<listitem>
<?xxe-sn 28ivhnywem8 4?>
<para><?xxe-sn 28ivhnywem8 5?>Existing code paths extracted during
source code processing and coupled with relevant annotations are
enough to construct all possible exploitation paths and analyze them.
The analysis determines possible (<emphasis><?xxe-sn 295bzzou9kw 3?>weak</emphasis>)
paths that can either occur or not occur during particular execution,
as well as certain paths (<emphasis><?xxe-sn 295bzzou9kw 4?>strong</emphasis>)
that occur under any conditions. Also it checks if an exploitation
path is valid against certain exploitation rules, e.g. initialization
always occurs before the actual usage, and if it is possible to
correct the invalid paths.</para>
</listitem>
<listitem>
<?xxe-sn 28ivhnywem8 6?>
<para><?xxe-sn 28ivhnywem8 7?>The reasoning's result is an
exploitation plan that dictates the order and strategy of exploitation
presented in the form of an appropriate specialization for polymorphic
functions that deal with resources in order to ensure safe
exploitation to the extent based on provided annotations.</para>
</listitem>
<listitem>
<?xxe-sn 26yv439af40 19?>
<para><?xxe-sn 26yv439af40 1a?>Exploitation-related side effects are
viewed as a set of additional restrictions over the operations' order.
Only the subset of possible reorders is still valid w.r.t. side
effects. Transcend's task is to achieve a refined set of valid orders.
Thus techniques that rely on reordering enjoy an additional
information to make safe optimizations.</para>
</listitem>
</itemizedlist>
<para><?xxe-sn 26yv439af40 1b?>... and it serves three major goals:</para>
<itemizedlist>
<?xxe-sn 26yv439af40 1c?>
<listitem>
<?xxe-sn 26yv439af40 1d?>
<para><?xxe-sn 26yv439af40 1e?>Safety. Validates the existing
exploitation plan, or determines if it is possible at all to safely
exploit a given resource. Compiler signals an error if a given
exploitation plan is invalid, i.e. does not satisfy requirements
w.r.t. side effects as expressed by annotations.</para>
</listitem>
<listitem>
<?xxe-sn 28j5661y0mv -wunr7fl0rw8v?>
<para><?xxe-sn 28j5661y0mv -wunr7fl0rw8u?>Regression Resilience. When
it comes to using external resources, some spurious dependencies
usually occur between otherwise isolated, independent components of a
program. Sometimes refactoring or other code changes break those
dependencies, which inevitably results in regressions. Exploitation
catches this sort of regressions and automatically regenerates the
exploitation plan suited for changed conditions.</para>
</listitem>
<listitem>
<?xxe-sn 26yv439af40 1f?>
<para><?xxe-sn 26yv439af40 1g?>Performance. Generated exploitation
plans are optimal in a sense that they cut off superfluous operations,
for example, by preventing resource initialization in several places
if it can be done safely in just one place, thus reducing overall
overhead.</para>
</listitem>
</itemizedlist>
</section>
<section>
<?xxe-sn 27ay8x1a5mo 1?>
<title><?xxe-sn 27ay8x1a5mo 2?>Domination Analysis</title>
<para><?xxe-sn 27ay8x1a5mo 3?>When it comes to reasoning about the order
of execution and possible code paths, the crucial vehicle for that is
<emphasis><?xxe-sn 27ay8x1a5mo 4?>domination analysis</emphasis> producing
<emphasis><?xxe-sn 27ay8x1a5mo 5?>dominator tree</emphasis> as an
output.</para>
<para><?xxe-sn 27ay8x1a5mo 6?>Unlike the usual function-bound domination
analysis, when a separate domination tree is produced for each function
defined in a program, Exploitation requires a program-bound analysis, that
is taking into account the control flow across all functions in a program.
It is a computationally intensive task to perform an analysis over a whole
program, however it is compensated by the fact that Exploitation only
takes into account the code blocks that deal with or, in other words,
exploit external resources. Thus there is no necessity to build a full
dominator tree, only the relevant parts are constructed, just enough to
make sound exploitation plan decisions.</para>
</section>
<section>
<?xxe-sn 28h47d43thc i?>
<title><?xxe-sn 28h47d43thc j?>Empty Exploitation Plan. Effect Free
Computations</title>
<para><?xxe-sn 28h47d43thc k?>Validation of exploitation path is done
against some predefined constraints. Depending on complexity of the
constraints, i.e. the number of different exploitation events that are
sought for in each path, reasoning goals are categorized into several
groups:</para>
<itemizedlist>
<?xxe-sn 28j5661y0mv -wunr7fl0rw8t?>
<listitem>
<?xxe-sn 28j5661y0mv -wunr7fl0rw8s?>
<para><?xxe-sn 28j5661y0mv -wunr7fl0rw8r?>Zero Order Exploitation.
Meaning that all paths are checked to determine if there is
exploitation at all or not, and if there is at least a single
exploitation event along the path.</para>
</listitem>
<listitem>
<?xxe-sn 28j5661y0mv -wunr7fl0rw8q?>
<para><?xxe-sn 28j5661y0mv -wunr7fl0rw8p?>First Order Exploitation.
Deals with the situations where it is enough to check only two
different exploitation events occurring in a required order. It can be
useful for example, to check whether all resource uses occur after it
is initialized.</para>
<remark><?xxe-sn 2fsua1xc9o0 pu35zrt1aby9?>"to check only two
different exploitation events occur in a required order" - нужно
уточнить смысл фразы. "Уточнить только два события, осуществляющиеся в
требуемом порядке", или "уточнить, осуществляются ли два этих
события"? Я использовал герундий (occur - occurring), как более
нейтральный вариант.</remark>
</listitem>
<listitem>
<?xxe-sn 28j5661y0mv -wunr7fl0rw8o?>
<para><?xxe-sn 28j5661y0mv -wunr7fl0rw8n?>Higher Order Exploitation.
Expresses constraints involving several (more than two) exploitation
events and relations between them.</para>
</listitem>
</itemizedlist>
<para><?xxe-sn 28j5661y0mv -wunr7fl0rw8m?><emphasis><?xxe-sn 28j5661y0mv -wunr7fl0rw8l?>Empty
Exploitation</emphasis> is an important instance of the zero order
constraint. It is a useful mechanism for the developer to annotate a
function or part of a program as effect free in terms of exploitation.
Thus, effectless, clean or pure code can be clearly separated from the
effectful part, and compiler raises a compilation error in case of
accidental mixing or using "wrong" type of code in a non-appropriate
environment.</para>
</section>
<section>
<?xxe-sn 26yv439af40 u?>
<title><?xxe-sn 26yv439af40 v?>Resource Initialization</title>
<para><?xxe-sn 26yv439af40 w?>One important problem related to
exploitation order is to ensure that a given resource is properly
initialized before its first usage and, additionally, that it is not
initialized more than once during the exploitation session. This is the
instance of first order exploitation since in a validation mode it is
enough to check the exploitation plan to ensure that every resource usage
was preceded by resource initialization at some point in the
<emphasis><?xxe-sn 28jw0wb6fpc 1?>past</emphasis>, i.e. previously in the
exploitation path.</para>
<para><?xxe-sn 28jw0wb6fpc 2?>For the planning mode, the problem is
addressed as follows:</para>
<itemizedlist>
<?xxe-sn 28jw0wb6fpc 3?>
<listitem>
<?xxe-sn 28jw0wb6fpc 4?>
<para><?xxe-sn 28jw0wb6fpc 5?>The central idea of the algorithm is to
consider candidates for initialization only among those code blocks
that <emphasis><?xxe-sn 295bzzou9kw 5?>dominate</emphasis> a given
usage site. Obviously, initialization in the dominating block precedes
usage for any possible code path.</para>
</listitem>
<listitem>
<?xxe-sn 295bzzou9kw 6?>
<para><?xxe-sn 295bzzou9kw 7?>One or more dominator blocks are chosen
for actual initialization in such way that they cover all the found
usage sites.</para>
</listitem>
<listitem>
<?xxe-sn 295bzzou9kw 8?>
<para><?xxe-sn 295bzzou9kw 9?>For the code blocks chosen for
initialization, the specialization <code><?xxe-sn 295bzzou9kw a?>exploitation(init)</code>
is set, while for the rest of the code blocks the specialization
<code><?xxe-sn 295bzzou9kw b?>exploitation(none)</code> is
used.</para>
</listitem>
</itemizedlist>
<para><?xxe-sn 28h47d43thc 1?>Please take a look at the example
below:</para>
<programlisting xml:id="ResourceInit_1"><?xxe-sn 28h47d43thc 2?>name="tests/exploitation.cpp: Doc_ResourceInit_1", lines=15
import raw("scripts/cfa/payload.lp").
import raw("scripts/exploitation/exploitation.lp"). //exploitation reasoning
import raw("scripts/exploitation/test1.assembly.lp").
guard:: exploitation(init)
{
openFile = function(filePrev:: FILE_P):: FILE_P; init(file)
{
fopen("/tmp/test", "w")::FILE_P
}
}
guard:: exploitation(none)
{
openFile = function(filePrev:: FILE_P):: FILE_P
{
filePrev::int
}
}
test = function:: int; entry
{
seq
{ f0 = undef:: FILE_P. f0 }
{
//Scope #1:
f1 = openFile(f0):: FILE_P.
f1
}
{ //Scope #2:
f2 = openFile(f1):: FILE_P.
f2
}
{
//Scope #3:
sizeWritten = fwrite("Attempt to write..", 12, 1, f2):: int; use(file).
sizeWritten
}
{
//Scope #4:
fclose(f2):: int; use(file)
}
{ sizeWritten :: int}
}</programlisting>
<para><?xxe-sn 28h47d43thc 3?>There is the function <code><?xxe-sn 28h47d43thc 4?>test</code>
that executes sequentially the following commands: open a file (scopes #1
and #2), write some text (scope #3), and finally, close the file (scope
#4). It represents a simple work flow with an external resource.</para>
<para><?xxe-sn 28h47d43thc 7?>In order to connect the code to the
exploitation, the functions <code><?xxe-sn 28h47d43thc 5?>fwrite</code>
and <code><?xxe-sn 28h47d43thc 6?>fclose</code> in scopes #3 and #4
respectively are annotated with annotation <code><?xxe-sn 295bzzou9kw c?>use(file)</code>.
This information is used by reasoning to look whether it is possible to
initialize a given resource before actual usage as well as where and when
exactly to initialize it. Function <code><?xxe-sn 28h47d43thc 9?>openFile</code>
is annotated as <code><?xxe-sn 28h47d43thc a?>init(file)</code> meaning it
<emphasis><?xxe-sn 28h47d43thc b?>can</emphasis> initialize depending on
the chosen strategy. The function is invoked both in scope #1 and scope
#2. Both scopes are executed <emphasis><?xxe-sn 28h47d43thc d?>strictly
before</emphasis> scopes #3, #4. Thus it is indeed possible to initialize
the resource before usage. Next task for exploitation is to choose the
correct exploitation plan, i.e. to assign strategies for all possible
initialization places in the effort to initialize the resource only once.
Here, it means that only one invocation of <code><?xxe-sn 28h47d43thc e?>openFile</code>
is assigned with <code><?xxe-sn 28h47d43thc f?>exploitation(init)</code>
to actually initialize the file. The other one is automatically marked
with <code><?xxe-sn 28h47d43thc g?>exploitation(none)</code> to invoke a
different specialization of <code><?xxe-sn 28h47d43thc h?>openFile</code>
that does nothing since the file was already initialized.</para>
</section>
</chapter>
<?xxe-revisions
#17 2019-05-28T07:25:43Z pgess
#16 2019-05-25T22:11:48Z Администратор
1sPEAAABgZElADiBkQEAAxkVbGF1c656IwwTBkMEpSMNU4xfAQFTCt8TBWPUaQDJOJcPkDaITNNQ
mC2BH5wyiTqLYQ==
#15 2019-05-25T19:18:44Z Администратор
1sPEAAABgZEBAIQhgYp9ABSCNIFQbGxpYXJlbW9vbiBlZSwnbkNMbixzxRMTGkMEEwVTDRMEYwtj
D1MEAQJTE0ODMjMEUyszDAEBQwQTB0NZMx0BAUOBZN1TRjMJAQIzgV9DBFMIEwZTE1MGUxgzgXoT
BEMZY2MzBwEBMxkTE1M3MyxDbVMaEwVjUEODChMGUw4zMuNDIlMEY4FtQwlTBmMFQxcBASMKQ4FH
YwRjDPdDN1MHIwVTB2NxEwxTKxMUY1xjgXgzGkMVUxZjTzM6Qw5TFWNQAQETCDOBSEMQU1tjCyME
MxxDBGMLQx5TVmM2M4FCQ4EkAQFTVWMOYztDLyMIU4FhEwQzClNskwxjGUNSUw0zgRQBATOLEMdD
FWMKAQEzFZMGQwRjHDMaQ4ECEw1TgiaDDxMHUwwzggaDBzOBUVM/EwhzEWNfU4FbEwZjZRMKkw9j
H0M1YwRDMgDFF65Drg2XXJpgl1SEc5NbGxaqHoM1MokunU4XXRyZYoFyjzRTgh2MEK9lgXODbBQc
uCuBfBuCGG2aES85L3HFMR9SojSDEhKDYTiPcSqNfZo+iByCCCQqp2qBTZ0sE6s6kFepK0+OWFKN
NoVGXYF8HxkYUD4PF4c5W7Y4gVWDFZ0xcYdsIA8iWjqBRoEphVZpPZtbO5JTgWEOQ3weWBCBI4tU
ix4WDqocBR0cgYIxgRCAiWsLgkq5ghGBVbxnxFxjrnSBZYdaU5Z6gR+SBzo=
#14 2019-05-06T11:44:19Z Администратор
1sPEAAABgYp+AIMjgYc+ABCBX4ErLG9kUixudHdoYXRSaWZpdXObIRMZQwQTikxDBEMlUwxDRRMJ
UwZDDGMEMzBjBBMREwUzBwEBM4FGExBDLFMEYx5TBhMIQ4IlMwYBATOBAwEBMwdTODNXAQFDZ1MF
UxYzgmRDBUNDEwozCTMIY10jBDMKYw4jClMWExRDC1M1YwRDBWMgAQFTI0MEY0VDCEMUY0UTBjMH
QwcTCzMJYwxTCGMFU0NjB9O7AQRDERMEMxFDEHMMIwhjEBMEYwQzBRMHYwxTBkMRQwhjZAEBMzhD
I1MFEwjgUwYTBFOBfmMKM0AjEFMHM1emxxMGQ0RDyAkAnT6ZCJtClB2IVp1SLIgwqmWEZJwBnwys
G6cpiTo1CoN4hC2jQC+XDI40MIVhgi6CKIELOVy/NW4alVCCbI82oSKZRmS3ZoEwb7gbqTiNC5ll
kH+dB4xLPSSdHyiVT1EVrXNSBoUPpB+IPIVRnwqEPiKZW4NAV5JTiyQqBpERgh2tdJ44jjaJawsk
iGUaDGk8qEC0GogBN4c9DZ0JggiWb1ULqSK8V442aUc=
#13 2019-03-07T18:19:21Z pgess
1sPEAAABgYc+AIFSgYUHABBwS2RvY3V0YWNrbGVuJ3ZkaXNzhw4TCdAjBVMEQwoBBkMHQxhjOFMY
My9TQWNDIxgzB1OFMmOIBAECM4IGAQEjBEMzYwVjKUNBMwVTFhMFMx1TM2MEY333IwYjBgECQyVD
alM9Y0gzPkM6UwhjgQojBDMIMwczBhMOQzxTFGMVM+J7AIcLpmeqBZBgCpZOGhyIdE0xQqtdYAuF
NIgOnSOCCoITOSquF0SSUxchhnU4hwq+eZ0lgQEmeoJHS0JACqE/rG2sJo1jo0MQQBcZ
#12 2019-02-09T15:16:04Z pgess
1sPEAAABgYUGABiBhQgAAAoHc91tE6ZjQwVTMwDdbIN6om0=
#11 2019-02-02T13:07:26Z pgess
1sPEAAABgYUIAAyBhQgAAAQBc4GFCAA=
#10 2019-02-01T17:38:23Z pgess
1sPEAAABgYUKAIFE9icACGZQc28yPz5sZWFziRsTC0MIQ2oTC2OCNgECQ4MkU4s0IwcTC2PCVFMF
MyRTFgEDM4kVEwVDCmMJU4I8EwxThHozgVuDDEOBGoMIMwljVVMMQwVTPBMEAQMTBxMGYw5TbUMP
Yx9TLHMQEwcTChMJUxYAiR6YbxmDNI5ygjqDMb5tjjuLSbZOimemdYERpyObYagAiSKDYoJMhH3i
gWejny2BIIFcqCZl6Q6TG4l51AGZa4N5lkeBJZzSBZdFigWdWA==
#9 2019-01-26T14:30:18Z pgess
1sPEAAAB9icAUfYlAAEqIGRz0wATB0OBHVMEQxszCBMFQzRTBTMEYwdjgRgTCAEBY4I9MwpDgVxj
m00Ap2mrJoRxiR2ZGo5OijKLeq8mnUlJhCOBG54rgkGBYw==
#8 2019-01-15T20:23:54Z pgess
1sPEAAAB9ioAhCvvEAAlgiWBWTphc3NvY+KAlENzVW5ld2Jyb2tld2lmb3JzIDh0cmlnZ2MzZWRz
hjUTDkNNEwgjBVMPAQFDQVNUAQVjBCMHMwQTBjMIY4wxUwdDgw5jfwEDUwQzihsBAVMiIwVjgRFD
BFNTYwYzgnoTByMGAQFDix3UEwxDCjMGMwxjBVM2YxozBc0TBkMWEyBjbFMJUyVjDhMIMzdji11T
CEMHMxVTBwEFYwSkY4I8kxZTK2OLHFMYM1EBAjOBEhMRUw0TEEOBPUMdMwSTCDMFUwlDBwEEYxET
CUMMUyAzim8zEUMcYwVTIRMSQxozgV1TEZMLAQFjE2MKEwcBBTMEgwxjC1MGYwQzBjMOQ4EbM4FY
UwkTBGMXAQFTD0MIUw5jTSMEEwtTBwEBUwczGpMIQwgzBVMGAQJjgQYTBTMFkwhjBmMHcwVTCYME
UwQzCUODSwCGSj+FZK15XBNPiyyLPJR1hWWUNYNkpX6MOIMfiRmBCIolnGArgTQQdhKbF60ngxKE
KINihiyoLp1okBUHN4hQjnyjB404oSOUH4lodqw8hHBFO4ZOqxeLbIIllBGGCCpGrHyDDC6HLFip
eZ4Bg3iBQYFqhwi+jEQfpVuYPIl8mXqLN4dsin4bj20rhGeZD0++OQWCBYFdllSWf+JYhH8Oymig
CB+BHoFDok6fa5MkgieFGRKBGqJyzHaLRL41cCiqf69yhAWEe4FAcM5PhGACnnsZgT6gNho=
#7 2019-01-15T13:53:13Z pgess
1sPEAAAB7xAAIuoxAAAQDHPREhMKQwRTQBMJExBjmDgAog2uVjCJF4N4hUU=
#6 2019-01-15T11:27:29Z pgess
1sPEAAAB6jIAF+dpAAAKB3PMJBMJQylTmxMAiReKLbtb
#5 2019-01-15T08:04:19Z pgess
1sPEAAAB520AglrYYQAogTF6RGF0aXNvZmluIGxpbVN0bDo6IEMxakRlLCwsaGxsIEluIHNoYWJ1
dHOjSwEDEwYBAiMEAQJDCmMEYwtDTGMFUyIzBzMGEw9TgyxDDxMFYwYTCSMFIwoTBTMKEwkzJgEG
MwQzC1OCV+ETBQEBQ1pjCVMMM0djBgEBY4EBAQFDJVMxEwZjdxMMQy4BA1MJYxJjFjMgYwQTGwEC
YxkBAUMGAQFjBFMGAQODCZMMgywBATMIMwQBBkMEExL5EwdDC0MHYxJDBQECUwSDCVOGCQEDQ4Na
gwkzKVObEwCRFaoCiCekAopDFIULT3MjmUcbgweMEYRHhjqtBLRjhWyRCoRwkXWCKoEaPYFqh32C
W4EahyZxhydMgQJfnjBHgzSFHYs5rTyVBJE+oEODeJFFjn6SK50Al37CmTiVDYJ8kR9Wi06ZMoMu
EoEUnUCXizOGEJeKLY5K
#4 2019-01-14T13:48:02Z pgess
1sPEAAAB2GUAgSjKVwAOVz0zPz5UdHRlc2hvdWxTcnOVKhMWQ4IsEwzdUwUBAWMEUwdjCGMJIwYB
ATMFAQFjBFMIEx9TNVMEMwRjC1MMUxEBBRMEMwkzgl5TCmMLgyBDIwEBY4FMMw0zBFMXM4pXEwUB
AWOgfQCVTSKDNKlVixtjgU2UA4k+mUicDoljFoQumTyORYVtRoN7HZdigjEdkjOBQiyJVjmVRIRC
gQeCUZlRh2Q=
#3 2018-12-24T11:55:39Z pgess
1sPEAAAByiAAglmxQABBgSBxZmxmbWZucmVzdWxpbmRpdmlkZG8gc28sIGJvZ3VzIGdsb2JpcyBs
bCBsQ0ZHNz8+QS04Pz5mb3J3bzk/PnAvPgpzpUkTCwECQx8BAlMZUyUBAmMpM4EjU4IUYwgBBRMF
Mw4TBhMJQwcBB2MMMwQTC0MgMwYzByMPQyVDCwERYwRDBRMFYwUzBEMJUwQTBAEDEwQzB+LWUw4B
A0MKExBzCwEEUwUzBiMMAQEzCFMKYwQTF3MLAQczBFMHAQFDDTMGExRzCwEEQwSDByMPUwRDBRMF
Qw1TKWOCS3MLAQETCAECAIM0DKp5LlmhW4E7gxWgXIJenROObIhji1uHGoNjOIxDiwt0S5NdhiSN
F4xGlnaRBothlSWICkSYHIYbimyXV4I3g3jJhQKEEIIQi1uDJJ8LhCvJjEOBfINCl0GELsmHL8VC
hTySPYYHhl2NPYcQxAE=
#2 2018-12-24T11:20:18Z pgess
1sPEAAABsUAAErE4AAAHBXOwUxMGQ18AqheGSg==
#1 2018-12-18T16:02:30Z pgess
1sPEAAABsT0AMqdsAAIYEm9sc6JqAQITDEMLQwuDIDODMhMLQ2JDFGMLAJhklUuCMJSIGoM0izSB
dIJQ
?>
Event Timeline
Log In to Comment