![](bg7.png)
4.1.5 7-Zip
7-Zip supports encryption of the archives using the
AES cipher in CTR mode. We performed a test with
a file consisting of 32 zero bytes (two AES blocks)
in the “Store” mode (without compression). Our ap-
plication successfully detected two encryptions; both
used the same key and the plaintext were two suc-
cessive counter values (0x01, 0x00, 0x00, 0x00,
... and 0x02, 0x00, 0x00, 0x00, ...), as ex-
pected.
4.1.6 Putty
Putty uses the SSH protocol to encrypt the transferred
data, and AES is one of the supported ciphers in this
protocols. We attempted to recover data from a con-
nection where AES-256 in CTR mode was the agreed-
upon cipher between client and server. Two distinct
key expansions were detected and recovered as well
as a lot of encryptions. After we XORed the recov-
ered plaintexts with the encrypted data captured by
WireShark, we were able to observe data structure ex-
pected in the unencrypted contents of the SSH proto-
col.
4.1.7 PowerShell
PowerShell is a scripting language which, among
other things, supports reading web data using the
HTTPS protocol using the Invoke-WebRequest
command. When we enforced the use of TLS ver-
sion 1.0, the client and server agreed upon using the
AES-128 cipher in CBC mode. Our application suc-
cessfully detected both the key expansion and the en-
cryption as well as decryption of data and we were
able to verify that the recovered plaintext contained
the expected data of the HTTP protocol.
4.2 Performance Tests
During our tests we measured the speed of our ap-
plication in different scenarios using 7-Zip. The tool
was chosen because it allows precise specification of
the size of the data as well as precise measurement of
time; at the same time it is a real-world application
and as such can provide a real-world benchmark, un-
like a custom benchmarking application which would
be heavily dependent on the actual organization of the
AES code (e.g. whether the substitution tables were
located in the same memory page(s) as some other
frequently used data or code items). We created files
of 256, 4096 and 65536 bytes and measured how long
did 7-Zip take processing these files without compres-
sion but with AES-256 encryption in different scenar-
ios based on our application’s settings. The results
can be seen in Table 1.
It is apparent that the presence of our application
carries a significant performance penalty even if no
key- and plaintext-recovery is being done. This is
caused by the fact that on any access to the memory
page containing a detected substitution table causes a
page fault, a number of context switches between the
application, our AesSniffer and the operating system,
and several VirtualProtectEx calls, not to mention
the possible need for using a software decoder of the
affected instruction. While this penalty can be re-
duced if the monitored application used a friendlier
memory layout (e.g. the substitution tables would be
located in dedicated memory pages), the opposite is
also possible – if, for example, the substitution table
occupies the same memory page as a virtual method
table of some frequently used object class, the penalty
could be much more pronounced, even more so if
some frequently used code was located there as well.
Another significant increase in the processing time
can be observed if the detection of AES-192 is acti-
vated. The reason for that is that with AES-192 there
are far more possible permutations of the key than
with AES-128 and AES-256 because the columns of
the 192-bit key depend on five other columns rather
than three columns with 128- and 256-bit keys.
Finally, the size of the data to be encrypted ob-
viously increases the overall time because more ac-
cesses to the substitution table are required – 160 ac-
cesses per block in case of AES-128, 192 accesses per
block in case of AES-192 and 224 accesses per block
in case of AES-256.
While these penalties may seem overwhelming,
it should be noted that they are still far more man-
ageable than other dynamic approaches. We imple-
mented a very simple tracer into our application, one
which forces single-stepping of all instructions with-
out any additional processing (i.e. no AES detection
at all). Encryption of a 256-byte would then take more
than 38900 seconds, or something like 200-times the
worst case of our code with full detections enabled.
If better performance was desired, it is possible
to separate the gathering of data (monitoring accesses
to substitution tables) from the processing of the data
(key and plaintext recovery): While the first phase
must by necessity be performed at the time the ac-
cesses are done, the second phase does not need to – it
is quite sufficient to process the data asynchronously,
e.g. in a different thread or even offline from a record
of the accesses in a file. That would at the very least
resolve the penalty for using AES-192 which is un-
necessarily incurred synchronously in the current im-
plementation.
ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy
178