In this new version of cut-bytes.py, I add support for custom Python transforms (options -P and -S), pyzipper and fixed a bug.
cut-bytes_V0_0_16.zip (http)I added extra plaintexts for the modulus of Cobalt Strike’s public RSA key.
xor-kpa_V0_0_7.zip (http)This new version of file-magic.py adds a definition to identify OneNote .one files:
And adds support for pyzipper.
file-magic_V0_0_6.zip (http)A small feature update for pdf-parser.py Statistics include unreferenced objects now:
About a week ago, I was asked if I had tools for OneNote files.
I don’t, and I had no time to take a closer look.
But last Thursday night, I had some time to take a look. I looked at this OneNote maldoc sample.
I opened the file in the binary editor I use often (010 Editor):
I expected to see some magic header, a special sequence of byte that would tell me which file type is used. I didn’t see that, but I noticed that the first 16 bytes look random. And they were the same for another sample. So this could be a GUID. GUIDs in Microsoft’s representation are a mix of little- and big-endian hexadecimal integers. That’s why 010 Editor has an entry for GUIDs in its inspector tab:
This is the GUID represented as a string: {7B5C52E4-D88C-4DA7-AEB1-5378D02996D3}
Looking this up with Google:
That’s great, Microsoft has a document [MS-ONESTORE] describing this file format.
Unfortunately, I did a quick search but didn’t find a pure Python module to read this file format. Maybe it exists, but I didn’t find it.
Next I tried my pecheck.py tool to locate the executable inside the onenote sample. That worked well:
At position 0x2aa4, here’s an embedded PE file. Taking a look with the binary editor:
I see the MZ header, and 36 bytes in front of that, another random looking sequence of 16 bytes. Maybe another GUID:
{BDE316E7-2665-4511-A4C4-8D4D0B7A9EAC}
A bit of Google search:
Turns out that this is a FileDataStoreObject structure.
So looking for this GUID in any file, one can find (and extract) embedded files. So that’s what I quickly coded using my Python template for binary files (there are some issues with this GUID-search method, I’ll address these in an upcoming blog post or video)
A new tool: onedump.py
New functions and classes have been added to process-binary-file.py.
python-templates_V0_0_9.zip (http)This is a new tool (based on my Python template for binary files) to analyze OneNote files.
This version is limited to handling embedded files (for the moment).
As I might still make significant changes to the user interface, I’ve put this tool in my GitHub beta repository.
A small update to option -W of zipdump.py.
Next to value vir, you can now also specify values hash and hashvir.
hash: write each file with name equal to the SHA256 of the content of the file.
hashvir: write each file with name equal to the SHA256 of the content of the file plus extension .vir.
zipdump_v0_0_24.zip (http)I use my tools dns-pydivert and dnsresolver.py for dynamic analysis of software (malware and benign software).
On the virtual machine where I’m doing dynamic analysis, I disable IPv6 support.
I install dnslib and run dnsresolver.py with a command like this, for example:
dnsresolver.py "type=resolve,label=example.com,answer=. 1 IN A 127.0.0.1" "type=forwarder,server=8.8.8.8"
The first command is a resolve command: DNS A queries for example.com will be resolved to IPv4 address 127.0.0.1 with TTL 1 minute.
The second command is a forwarder command: all DNS requests not handled by other commands, are forwarded to 8.8.8.8. Make sure that the IPv4 address of the DNS server you forward requests to, is different from the VM’s default DNS server, otherwise this forwarding will be redirected by dns-pydivert too.
I don’t use this second resolver command if the VM is isolated from the Internet, I only use it when I want to allow some interaction with the Internet.
Then I install pydivert and run dns-pydivert.py as administrator.
You can’t run dns-pydivert.py properly without administrative permissions:
When dns-pydivert.py and dnsresolver.py are running, DNS traffic is altered according to our settings.
For example (picture above), when I issue a “ping google.com” command inside the VM, dns-pydivert sees this first DNS packet and configures itself with the addresses in this packet: 192.168.32.129 is the IPv4 address of the Windows VM and 192.168.32.2 is the IPv4 address of this Windows VM’s DNS server.
It alters this first request to be redirected to the VM itself (192.168.32.2 -> 192.168.32.129).
Then dnsresolver receives this packet, and forwards it to DNS server 8.8.8.8. It receives a reply from DNS server 8.8.8.8, and forwards it to the Windows VM (192.168.32.129).
Then dns-pydivert sees this reply, and changes its source from 192.168.32.129 to 192.168.32.2, so that it appears to come from the Windows VM’s default DNS server.
When I do the same (picture above) for example.com (ping example.com), the query is redirected to dnsresolver, which resolves this to 127.0.0.1 with a TTL of 1 minute (per resolve commands configuration).
Thus the ping command pings the localhost, instead of example.com’s web server.
And when I kill dns-pydivert (picture above) and issue a “ping example.com” again after waiting for 1 minute, the query is no longer redirected and example.com’s web server is pinged this time.
I used ping here to illustrate the process, but often it’s HTTP(S) traffic that I want to redirect, and then I also use my simple-listener.py tool to emulate simple web servers.
Remark that this will only redirect DNS traffic (per the configuration). This does not redirect traffic “directed” at IPv4 addresses (as opposed to hostnames).
This can be done too with pydivert, and I will probably release a tool for that too.
dns-pydivert is a tool that uses WinDivert, a “user-mode packet capture-and-divert package for Windows” to divert IPv4 DNS packets to and from the machine it is running on.
This tool requires admin rights.
When started, it listens for IPv4 UDP packets with source and/or destination port equal to 53.
When this tools processes its first UDP packet with destination port 53, it considers the source address of this packet as the DNS client’s IPv4 address (e.g., the Windows machine this tool is running on) and the destination address to be the IPv4 address of the DNS server used by the client.
From then on, all IPv4 UDP packets with source or destination port 53 (including that first packet) are altered by the tool.
All IPv4 UDP packets with destination port 53, have their destination address changed to the IPv4 address of the client.
All IPv4 UDP packets with source port 53, have their source address changed to the IPv4 address of the DNS server.
This tool can be used to redirect all DNS IPv4 traffic to the machine itself, where a tool like dnsresolver.py can handle the DNS requests.
Caveats:
Didier Stevens 