This Python script is essentially a wrapper for the smtpd Python module.
I use it to receive emails, and write them to disk.
Sometimes I use this to exfiltrate (malicious) emails.
This Python script is essentially a wrapper for the smtpd Python module.
I use it to receive emails, and write them to disk.
Sometimes I use this to exfiltrate (malicious) emails.
Windows explorer has an option to remove properties from media files: “Remove Properties and Personal Information”. For example, removing Exif data from JPEG files.
There is an issue with this feature: it does not properly remove Exif data.
Within an open folder (Windows explorer), select a media file (I’m using Canon_40D.jpg), right-click and select properties:

Select Details:

Then click “Remove Properties and Personal Information”:

When you click OK, a new file will be created: Canon_40D – Copy.jpg (I renamed this file to Canon_40D-redacted-W11.jpg, because I tested this first on my Windows 11 machine).
File Canon_40D.jpg contains Exif data pertaining to the camera, like its maker and model:

File Canon_40D-redacted-W11.jpg (the redacted version of file Canon_40D.jpg) contains less Exif data: the maker and model properties have been removed:

Looking at the redacted file with binary editor 010 Editor, I noticed that these properties had not been completely removed. Let me explain.
JPEG files are composed of segments of data, these segments can be analyzed with my tool jpegdump.py.
Here is the output for file Canon_40D.jpg (original file), I’m using option -E to include the SHA256 hash of the data of each segment:

And here is the output for file Canon_40D-redacted-W11.jpg (redacted file):

Notice that all the hashes of the segments are identical, except for the third segment, APP1. This segment contains the Exif data. This means that only the Exif data has changed, nothing else, like the picture itself.
Segments APP1 of both pictures have the same size, 2476 bytes. Although properties have been removed, Microsoft Explorer’s removal feature did not shrink the segment.
When I open the original file (Canon_40D.jpg) with 010 Editor, a template for JPEG files is automatically used to parse the structure of the JPEG file. This can be seen in the Template Results below the hexadecimal dump:

The JPG template is also able to parse Exif data: I drilled down in the template hierarchy, until I found the Exif properties (circled in red). There are 11 properties, the first is Make (tag 0x010F) and the second one is Model (tag 0x0110).
Opening the template DIRENTRY structure for property Make reveals the following fields:

Remark that the string “Canon”, that is the string value of the Make property, is not contained inside the DIRENTRY structure for said property. What it does contain, is the size of the string (6 bytes) and an offset to the string itself (an offset of 146 bytes). Literal string values (StrAscii structures) are stored inside the Exif data structure, after the list of DIRENTRY structures.
It is the same for the Model property:

The Model DIRENTRY structure points to an ASCII string (StrAscii), size is 4 bytes and offset is 152 bytes.
Let’s take a look now, again with 010 Editor, at the cleaned file that was created by clicking “Remove Properties and Personal Information” (Canon_40D-redacted-W11.jpg):

Notice that this file has 8 DIRENTRY structures in stead of 11: 3 Exif properties have been removed (Make, Model & Software). And the StrAscii structures for these 3 properties do not appear in the template result.
However, these 3 StrAscii string values are still inside the APP1 segment:

They are at the exact same location as in the original file (Canon_40D.jpg):

Conclusion: when you use Windows Explorer’s “Remove Properties and Personal Information” feature, Exif properties will be removed, but if these are string properties, they are not completely removed.
Windows Explorer’s “Remove Properties and Personal Information” feature removes DIRENTRY structures (properties), but does not remove StrAscii structures (properties’ string values).
When the Exif data of JPEG files cleaned with this feature is viewed, the orphaned strings will not appear. But when they are viewed with a binary editor, these strings do appear. And of course, they can also be easily visualized with a strings utility (here I’m using my strings utility strings.py):

You will not know to which properties these strings belong, because that information has been erased (DIRENTRY structures). But here, just the string values themselves, are enough to know that this is a Canon camera and that GIMP software was used to produce the final picture.
In case you want to test this yourself and try to reproduce my findings, you can download file Canon_40D.jpg from here. The file I created by using Windows Explorer’s “Remove Properties and Personal Information” feature, Canon_40D-redacted-W11.jpg, has a SHA256 of 8B190028D0F9F2A6F7EDB1DC0955008D73173C32C19C32CE62372C7163EE1223. I tested this on a fully patched Windows 10 machine (21H2) and a fully patched Windows 11 machine. The results where completely identical.
And as I know that some remaining Windows 7 users will want to know if Windows 7 is also affected: a fully patched Windows 7 machine has the same issue (though the cleaned file was different from the W10/W11 file).
If you absolutely want to make sure that all metadata is gone from your media files, do not use Windows Explorer (for the moment). Use another tool. Ideally, use a tool that completely removes the segments containing metadata (APP1, APP2, …).
I did inform Microsoft about this issue.
This new version of jpegdump.py adds option -E to display extra info for each segment.
This extra data is a hash of the segment’s data: md5, sha1, sha256.

This new version brings a new encoding: zxcn
zxcn stands for “zero x comma no-leading zero”, and is very similar to zxc encoding (zero x comma).
Example of zxc: 0x90,0x0A,0x4D,0x5A
Remark the leading zero for value 0x0A (values smaller than 0x10).
With zxcn encoding, there is no leading zero for values smaller than 0x10.
Thus the example for zxcn becomes: 0x90,0xA,0x4D,0x5A
base64dump_V0_0_20.zip (https)This new version of pecheck adds support for dumping files (-D) while using option -l P.
pecheck-v0_7_14.zip (https)Office documents with a VBA project that contains streams whose name starts with __SRP_, have had their VBA macros executed at least once.
As Dr. Bontchev describes in the documentation for his pcodedmp tool:
When the p-code has been executed at least once, a further tokenized form of it is stored elsewhere in the document (in streams, the names of which begin with __SRP_, followed by a number).

Thus in my maldoc trainings, I always explain that the presence of __SRP_ streams is an indication that the VBA code has been executed prior to the saving of the document, and vice-versa, that the absence means that the code was not executed (prior to saving).
I recently discovered that these __SRP_ streams are also created when the VBA project is compiled (without running the macros), by selecting menu option “Debug / Compile Project” in the VBA IDE.

This new version brings some options to guide the XOR-key detection algorithm.
The beacon’s AES and HMAC key are contained in writable process memory: my tool cs-extract-key.py can detect these keys. But the beacon can be configured to encode these keys while it is sleeping. This feature is called a sleep mask, and uses a 13-byte long XOR key. The complete writable memory section that contains the beacon process data, like encryption keys, is encoded with this 13-byte long XOR key.
Since writable process memory sections contain a lot of consecutive NULL bytes (0x00), the 13-byte long XOR-key will be present in the encoded process memory (XORing 0x00 with a key gives the key).
My tool will try to detect this XOR-key, but searching for 13-byte long random byte sequences that appear often. It does this by considering all possible 13-byte long sequences as a potential key, and counting how many times each potential key appears. Then it throws away all keys that don’t appear often (less than 100 times) and all keys that do not appear random (for example, keys with more than 3 0x00 bytes).
The most prevalent of these remaining keys, is considered as the most likely XOR key.
The new options that have been added to version 0.0.3, allow to guide this key finding algorithm.
Option –keysize is the XOR key size: the default value is 13.
Option –numberofkeystotry specifies how many keys that are considered to be potential XOR keys. The default value is 10: this means that the 10 most prevalent keys are selected and displayed.
Option –keystotry specifies which keys to try, out of the 10 keys selected. By default, only the first key (most prevalent key) is tried: value 0. But you can provide several keys, as a comma separated list of indices.
A potential XOR-key is selected as a decoding key, if the decoded memory section contains string b’sha256\x00′.
Finally, option -r can be used to let the tool analyze a raw set of data (e.g., the provided file is not parsed as a minidump file, but just taken as raw data).
cs-analyze-processdump_V0_0_3.zip (https)I added option –donotfullsearch in this new version of my tool to extract encryption keys from process memory dumps of beacons.
When this option is used, cs-extract-key.py will not fall back to a full search when string sha256\x00 is not found.
cs-extract-key_V0_0_4.zip (https)