According to Wikipedia, 1768 Kelvin is the melting point of the metal cobalt.
This tool decodes and dumps the configuration of Cobalt Strike beacons.
You can find a sample beacon here.
1768_v0_0_3.zip (https)
MD5: 73DB2E96EE5B6427AF6CCE2672F91CB2
SHA256: C06850A132B89F5E8C127E43FD5CC42051706CDF058EB2D688BC8BD3043E6E02
I did some tests to generate electricity (230V AC) with a portable 12V battery (well, it’s 10 Kg).
I have a 12V VRLA battery with a capacity of 35,000 mAh. That’s 12V times 35 Ah = 420 Wh. Or equivalent to a 116,667 mAh (420,000 mWh / 3.6 V) USB powerbank.
Charging this 12V battery with a 12V battery charger connected to a 230V power outlet takes almost 7 hours (6:57) and requires 0.49 kWh. That is measured with a plug-in electricity meter with a .00 kWh precision. And I’m working under the assumption that the power requirement of the electricity meter is so small that it can be neglected.
Then I use this fully charged battery to power a 230V 150W halogen lamp via a 12V DC to 230V AC power inverter (modified sine wave).
It runs for 2 hours (2 tests: 2:01 and 2:03) and consumes 0.30 kWh.
Of the 0.49 kWh energy I put into my system, I get 0.30 kWh out of the system. That’s 61%, or a bit better than half of the energy I put into the system.
The main phases where I expect the energy losses are occurring, is in 230V AC to 12V DC conversion and electrical to chemical energy conversion (charging); and chemical to electrical conversion and 12V DC to 230V AC conversion (discharging). I believe the highest energy loss to occur in the power inverter.
And with energy loss, I mean energy that is converted into forms that are not directly useful to me, like heat.
Remark that the halogen lamp test stopped after 2 hours, because the power inverter stopped converting. The battery voltage was 11.5 V then, and I could still draw 1 A at 11.5 V for an hour (I stopped that test after 1 hour).
Next I’m going to try out a 12V to 5V adapter and power some USB devices.
Blog posts:
YouTube videos:
Videoblog posts:
SANS ISC Diary entries:
Whenever I upgrade the operating system of my virtual machines, I take a snaphot right after the upgrade.
This gives me a tree of different OS versions:
I give each snapshot a small descriptive name, that starts with the date of the snapshot (YYYYMMDD).
This allows me to revert to older versions to experiment with patched vulnerabilities, like this one.
This new version of strings.py, my tool to extract strings from arbitrary files, adds option -P to add support for Pascal strings.
A Pascal string is a string that is internally stored with a length-prefix: an integer that counts the number of characters inside the string.
The Unix strings command, and my strings.py tool, can extract Pascal strings without any problem, because they just search for a sequence of characters, without looking for a terminating NULL character (C-string) or a length-prefix (P-string ot Pascal string).
But with option -P, you can direct my tool strings.py to only extract Pascal strings, by checking if character sequences are prefixed with an integer that is equal to the number of characters inside the string. Strings that do not match that requirement are ignored.
Since an integer can be represented internally with different byte formats, you have to provide a value to option -P that indicates how the integer is stored internally. I use the same format as Python’s struct module to represent that format. For example, “<I” is a little-endian, unsigned 32-bit integer. That is how a string is represented in Delphi, as can be seen in this example of a Delphi malware sample:
The strings you see here are all found inside the sample, and are prefixed by their length. If you wouldn’t use option -P, then these strings would also be extracted, but they would not stand out amid the other strings that are not prefixed by their length.
Delphi also supports the ShortString type: one byte to encode the length. These can be found with option -P “<B”: little-endian, unsigned 8-bit integer:
strings_V0_0_5.zip (https)
MD5: A4BF314BE0A72972ECA7B14B558610E6
SHA256: 30E9E9BB618006445483AA78F804766D8FFA518974B81F9B68FF534BEA30B072
This is a small bug fix release for Python 3.
translate_v2_5_9.zip (https)
MD5: 8EC7A9F0738C86CCF2F0B44D3994E798
SHA256: 3C469996F7014CC1BD5D4F02157B7D5803698D93018360904B79EA2A1601BD10
A couple of years ago, while experimenting with SYLK files, I created a .slk file that caused Excel to crash.
When you create a text file with content “ID;;”, save it with extension .slk, then open it with Excel, Excel will crash.
Microsoft Security Response Center looked at my DoS PoC last year: the issue will not be fixed. It is a “Safe Crash”, Excel detects the invalid input and calls MsoForceAppExitIf to terminate the Excel process.
If you have Excel crashing with .slk files, then look at the first line. If you see something like “ID;;…”, know that the absence of characters between the semi-colons causes the crash. Add a letter, or remove a semi-colon, and that should fix the issue.
This new version of oledump.py adds a new variable for option -E: %MOFULEINFO%
This variable need to be used together with option -i: it contains the size of the compiled VBA code and the compressed VBA code. For example: 123+65.
There’s a new option (-s) for plugin plugin_http_heuristics: with this option, the plugin ignores space characters (useful for hexadecimal bytes separated by a space character, for example).
And there is a new plugin: plugin_msg_summary. This is a new type of plugin, a plugin that operates on the complete document. Before, plugins could only operate on individual streams, and were instantiated for each stream.
This plugin produces a summary of a .msg file (something we needed for our “Epic Manchego” research).
Here is an example:
This plugin has a couple of options, for example to produce JSON output or to add header or body information:
Here is an overview of content I published in September:
Blog posts:
SANS ISC Diary entries:
NVISO blog posts:
Over the last months, I’ve been quite busy working with my colleagues on report “Epic Manchego – atypical maldoc delivery brings flurry of infostealers“: we’ve tracked an actor creating a new type of malicious Office document.
To help with the automatic analysis of all the maldocs produced by this actor (several per day), I added new features to existing tools and created new tools.
I’m releasing this work in the coming months (some has already been published: oledump.py and zipdump.py).
Didier Stevens 