Didier Stevens

Friday 2 September 2022

Quickpost: Standby Power Consumption Of My Bosch 18V Chargers

Filed under: Hardware,Quickpost — Didier Stevens @ 0:00

I have 2 Bosch 18V “power for all” chargers. A normal charger (AL 1830 CV) and a fast charger (AL 1880 CV).

Measuring the power consumption of these 2 chargers in standby mode (plugged into a 230V outlet, but no battery connected) with a GPM-8310 powermeter, I obtained the following results:

AL 1830 CV: 476,33 mW

AL 1880 CV: 344,39 mW


Quickpost info

Sunday 31 July 2022

Quickpost: iPad Pro Charging – Power Consumption

Filed under: Hardware,Quickpost — Didier Stevens @ 9:01

I charged an iPad Pro (12.9 Inch) and measured the power consumption (at 120V and 230V). According to the specs, this iPad has a battery with a capacity of 40.88 Wh.

Procedure: when the iPad Pro turns itself of because of a low battery, I started to charge the iPad with an Apple A2347 USB C charger and measured the AC power consumption of this charger. It consumes around 21 Watt, this value starts to diminish when the battery approaches full charge. When at 100%, the charger will still deliver power, slowly decreasing to 3 Watts, and then it stops delivering power for charging. At that point, I stop the power consumption measurement.

I did not use the iPad while charging.

This measurement was done twice: at 120V 60Hz and 230V 50Hz (using an AC power supply).

ACWhDuration
120V 60Hz57.17103:07:48
230V 50Hz57.55903:09:16

There’s not much difference between the two measurements, but what I’ll certainly take away from this test, is that it takes around 57 Wh of AC power to charge a 40.88 Wh battery!

Update: when I did these tests, my iPad Pro had around 84 charging cycles.


Quickpost info

Monday 25 July 2022

Quickpost: Standby Power Consumption Of My USB Chargers (120V vs 230V)

Filed under: Hardware,Quickpost — Didier Stevens @ 16:11

I did not explicitly specify in my post “Quickpost: Standby Power Consumption Of My USB Chargers” that I did my tests here in Flanders, Belgium and thus that the mains electricity is 230V 50Hz.

I wondered what the results would be in other parts of the world, like the USA. To answer this question, I redid my tests with the USB chargers powered by an AC power supply that delivers electricity at 120V and 60Hz.

The devices I tested are:

  1. Apple A1357
  2. Apple A2347
  3. Anker A2053

The no-brand USB charger was not tested, as the input specs specify 220V – 240V.

I connected each one to the AC power supply (120V 60Hz) and used a powermeter (GPM 8310, resolution 0,1 µW) to measure the standby power consumption over 24 hours.

This is the result:

Model24 hours (Wh)1 hour (Wh)1 year (Wh)
Apple A13572,04250,0851745,5125
Apple A23470,54730,0228199,7718
Anker A20533,75270,15641369,7360

24 hours is the measured data, the “1 hour” and “1 year” columns are calculated based on the 24 hours data.

And here is the summary for 120V and 230V:

Model1 hour (Wh, 120V 60Hz)1 hour (Wh, 230V 50Hz)
Apple A13570,08510,1202
Apple A23470,02280,0530
Anker A20530,15640,2114

It’s clear that my USB chargers consume less standby power at 120V 60Hz than at 230V 50Hz.


Quickpost info

Tuesday 12 July 2022

Quickpost: Standby Power Consumption Of My USB Chargers

Filed under: Hardware,Quickpost — Didier Stevens @ 0:00

I did some tests with my USB chargers: how much power do they consume when plugged into a power socket without charging any device (standby)?

The devices I tested are:

  1. Apple A1357
  2. Apple A2347
  3. Anker A2053
  4. No-brand: Chacon EMP604USB

I connected each one to a powermeter and let it measure the standby power consumption for 24 hours.

This is the result:

Model24 hours (Wh)1 hour (Wh)1 year (Wh)
Apple A13572,88470,12021052,9155
Apple A23471,27230,0530464,3895
Anker A20535,07340,21141851,7910
No-brand: Chacon EMP604USB5,64730,23532061,2645

24 hours is the measured data, the “1 hour” and “1 year” columns are calculated based on the 24 hours data.

The no-brand USB charger consumes the most: around 2 kWh per year, which is still less than a switched off Philips Hue lamp.

Using the same cost as for the Philips Hue lamp, that no-brand charger costs me around €1 if I would leave it plugged in for a whole year without letting it charge anything.


Quickpost info

Monday 26 April 2021

Quickpost: Decrypting Cobalt Strike Traffic

Filed under: Encryption,Malware,My Software,Quickpost — Didier Stevens @ 0:00

I have been looking at several samples of Cobalt Strike beacons used in malware attacks. Although work is still ongoing, I already want to share my findings.

Cobalt Strike beacons communicating over HTTP encrypt their data with AES (unless a trial version is used). I found code to decrypt/encrypt such data in the PyBeacon and Geacon Github repositories.

This code works if you know the AES key: which is not a problem in the use cases of the code above, as it is developed to simulate a beacon. Beacons generate their own AES key, and thus these beacon simulations also generate their own AES key.

But what if you’re analyzing real beacons used in malware attacks? How do you obtain the AES key?

I found a way to extract the keys (AES and HMAC) from process memory of a running beacon.

I use the following procdump command to prepare process memory dumps:

procdump -mp -w -s 1 -n 5 malware.exe

Then I start the beacon malware.exe in a malware analysis virtual machine while capturing traffic with Wireshark.

My new tool cs-extract-key.py looks in the dumped process memory for the unencrypted (RSA encryption) metadata that a beacon sends to the C2. This metadata contains the AES en HMAC keys.

Example:

This method does not always work: the metadata is overwritten after some time, so the process dump needs to be taken quickly after the beacon is started. And there are also cases were this metadata can not be found (I suspect this is version bound).

For those cases, my tool has another way of obtaining the keys. I extract the encrypted data of the first post of the beacon to the C2 (this is called a callback in the PyBeacon code):

And then I provide this to my tool, together with the process dump. My tool will then proceed with a dictionary attack: extract all possible AES and HMAC keys from the process dump, and try do authenticate and decrypt the callback. If this works, the keys have been found:

And once I have obtained the keys, I can pass them to my traffic decoding program that I have updated to include decryption (and that I have renamed to cs-parse-http-traffic.py):


Quickpost info


Friday 12 March 2021

Quickpost: “ProxyLogon PoC” Capture File

Filed under: Forensics,Networking,Quickpost,Vulnerabilities — Didier Stevens @ 18:43

I was able to get the “ProxyLogon PoC” Python script running against a vulnerable Exchange server in a VM. It required some tweaks to the code, and also a change in Exchange permissions, as explained in this tweet by @irsdl.

I created a capture file:

More details will follow.

Update: I added a second capture file (proxylogon-poc-capture-with-keys-and-webshell.pcapng), this one includes a request to the webshell that was installed.

proxylogon-poc-capture-with-keys_V2.zip (https)
MD5: A005AC9CCE0F833C99B5113E79005C7D
SHA256: AA092E099141F8A09F62C3529D8B27624CD11FF348738F78CA9A1E657F999755


Quickpost info


Friday 12 February 2021

Quickpost: oledump.py plugin_biff.py: Remove Sheet Protection From Spreadsheets

Filed under: Malware,My Software,Quickpost — Didier Stevens @ 0:00

My new version of plugin_biff.py has a new option: –hexrecord.

Here I’ll show how I use this to remove the sheet protection from malicious spreadsheets.

If you want to open a malicious spreadsheet (for example with Excel 4 macros) in a sandbox, to inspect its content with Excel, chances are that it is protected.

I’m not talking about encryption (this is something that can be handled with my tool msoffcrypto-crack.py), but about sheet protection.

Enabling sheet protection can be done in Excel as follows:

Although you have to provide a password, that password is not used to derive an encryption key. An .xls file with sheet protection is not encrypted.

If you use my tool oledump.py together with plugin_biff.py, you can select all BIFF records that have the string “protect” in their name or description (-O protect). This will give you different records that govern sheet protection.

First, let’s take a look at an empty, unprotected (and unencrypted) .xls spreadsheet. With option -O protect I select the appropriate records, and with option -a I get an hex/ascii dump of the record data:

We can see that there are several records, and that their data is all NULL (0x00) bytes.

When we do the same for a spreadsheet with sheet protection, we get a different view:

First of all we have 4 extra records, and their data isn’t zero: the flags are set to 1 (01 00 little-endian) and the Protection Password data is AB94. That is the hash of the password (P@ssw0rd) we typed to create this sheet.

To remove this sheet protection, we just need to set all data to 0x00. This is something that can be done with an hex editor.

First use option -R instead of option -a:

This will give you the complete records (type, length and data) in hexadecimal. Next you can search for each record using this hexadecimal data with an hex editor and set the data bytes to 0x00.

Searching for the first record 120002000100:

Setting the data to 0x00: 0100 -> 0000

Do this for the 4 records, and then save the spreadsheet under a different name (keep the original intact).

Now you can open the spreadsheet, and the sheet protection is gone. You can now unhide hidden sheets for example.


Quickpost info


Monday 7 December 2020

Quickpost: finger.exe

Filed under: Hacking,Networking,Quickpost — Didier Stevens @ 0:00

Windows 10 comes with the finger command, an ancient computer network tool.

You can still use it to lookup weather information, for example 🙂

It establishes a TCP connection to the hostname/IP address after the @ character, using destination port 79. And then it sends the text before the @ characters in ASCII, terminated with carriage return & line feed.

After that, it reads the reply, displays it, and closes the TCP connection.

finger.exe is not proxy-aware.

Port 79 is not hardcoded as an integer in finger.exe: the port is identified by service name “finger” (UNICODE), which is defined in the services list (%SystemRoot%\system32\drivers\etc\services). GetAddrInfo uses this list.

If you replace “finger” with “http\x00\x00” (UNICODE) in finger.exe (via binary patching, a shim, …), the finger command will connect to port 80:

As noted by many, finger.exe can be (ab)used to exchange information and files. Here I had my own go at it with finger.exe & Excel:

 


Quickpost info


Monday 2 November 2020

Quickpost: Portable Power

Filed under: Hardware,Quickpost — Didier Stevens @ 0:00

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.

Saturday 31 October 2020

Quickpost: VMware OS Version Snapshots

Filed under: Quickpost — Didier Stevens @ 0:00

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.


Quickpost info


« Previous PageNext Page »

Blog at WordPress.com.