Month: June 2022

Converting WAV file to 8Khz, Mono, 16-Bit PCM

willjessiamLeave a comment

Recently I had a need to convert a WAV audio file from 22.05Khz, Mono, 8-Bit PCM to Khz, Mono, 16-Bit PCM so that a phone system I was configuring could interpret the audio files used for on-hold messaging.

There are a number of online services that can do this, but I don’t trust them and I wanted to work out how to do this with ffmpeg.

Since I was using my Windows box at the time and I needed to document this for others, I went with the Windows binary, but the same could be achieved on Linux or Mac.

  • The windows package for this software can be found here: https://www.gyan.dev/ffmpeg/builds/ffmpeg-git-essentials.7z
  • The download will be a .z7 file which will need to be extracted using 7-zip
  • Once extracted, browse to the bin folder, eg. \ffmpeg-2022-06-16-git-5242ede48d-essentials_build\bin
  • You will see a file called ffmpeg.exe. This is the file that performs the conversion via command line
  • Copy the path from file explorer so that you can browse to this location using command prompt or PowerShell
  • Open command prompt, start > run > cmd > enter
  • In command prompt, change to this directory , eg. cd C:\ffmpeg-2022-06-16-git-5242ede48d-essentials_build\bin
  • Now you will be in the bin directory and you can use ffmpeg
  • To check what type of file you are working with, run the following command C:\>ffmpeg.exe -i C:\sample.wav , eg. C:\ffmpeg-2022-06-16-git-5242ede48d-essentials_build\bin>ffmpeg.exe -i C:\users\<user>\downloads\sample.wav
  • An output will be given showing the encoding of the file.
  • If the file is already 8Khz, Mono, 16-Bit PCM then no changes are necessary and the file can be used.
  • If the file is something different to this, for example 22050 Hz, mono, u8, 176 kb/s, then it will need converting.
  • Keep in mind that by default ffmpeg will output information in Hz rather than Khz. In this example, 22050 Hz is 22.05 Khz (not what we want!).
  • The u8 listed in the example is an ffmpeg audio type. See this page to identify what audio types there are: https://trac.ffmpeg.org/wiki/audio%20types.
  • When we check u8 against audio types, it is listed as PCM unsigned 8-bit. Since this is not 16-bit, we need to convert the file.
  • The audio type for 8Khz, Mono, 16-Bit PCM is pcm_s16le.
  • To convert the file, we use the following command ffmpeg -i sample.wav -acodec pcm_s16le -ac 1 -ar 8000 output.wav, eg: ffmpeg.exe -i C:\users\<user>\downloads\sample.wav -acodec pcm_s16le -ac 1 -ar 8000 C:\users\<user>\downloads\output-16-bit.wav
  • Let’s break down the command. -i is for input file, -acodec specifies the audio codec, -ac sets the number of audio channels (mono), -ar sets the audio sampling frequency (8Khz)
  • If we run ffmpeg with no switches against the converted sample file again, we get 8000 Hz, mono, s16, 128 kb/s which is compatible with phone system I was working on.

Using the same method above, you could convert any number of source audio formats to other formats. Ffmpeg also has many other capabilities and can convert video too, it’s extremely flexible and robust. I recommend checking out the following man page https://manpages.org/ffmpeg.

Lastly, I looked back through my notes and realised I had used ffmpeg a few times in the past. One of these times was to convert a mp4 video file to webm for a HTML5 project, eg.

ffmpeg -i "C:\Users\<user>\Documents\Media1.mp4" -c:v libvpx-vp9 -crf 30 -b:v 0 -b:a 128k -c:a libopus C:\temp\output.webm

Thanks for reading.

Tail Windows Update Log Server 2016+ / Windows 10

willjessiamLeave a comment

Sometimes you have to patch mission critical Windows servers and you want to see what’s going on in the background. The modern windows update dialogue provides little verbosity, especially when compared to apt or yum in the Linux world.

In the Windows 7 / Server 2012 days I used to just tail C:\Windows\WindowsUpdate.log and watch the update process, especially when troubleshooting, or when updates were hanging on install. Nowadays if you open that file, you get the following message:

Windows Update logs are now generated using ETW (Event Tracing for Windows).
Please run the Get-WindowsUpdateLog PowerShell command to convert ETW traces into a readable WindowsUpdate.log.

For more information, please visit https://go.microsoft.com/fwlink/?LinkId=518345

As we can see, Microsoft have ditched text based logging in favour of ETW based logging. The link provided takes you to an article on Windows Update log files which lists out the various log files and what they do. If you want a concise log that is the same as what you got in Server 2012, then you have to run Get-WindowsUpdateLog which will spit out that familiar log file. This is no good in my situation, as that generated log file would be for the point in time it was generated, not a dynamically updated log file being written to during updates.

Since I don’t care really about the log contents and I just want to see some verbosity in the update process while its happening, I went through the other logs listed and came across the CBS log. CBS stands for Component based servicing and it provides output on update installation…. great!

When reviewing the log, I identified that the lines containing the strings Appl and FOD make up the majority of the hundreds, or thousands of entries, when running a tail. I filtered these out and it seems that what’s left is mostly operational logging to do with the update engine. Since my goal is to watch Windows Update progress to ensure something is happening, I wrote a quick PowerShell one liner:

Get-Content -Path $env:WinDir\Logs\CBS\CBS.log -Tail 10 -Wait | Select-String -Pattern 'Appl:|FOD:' -NotMatch

This command will get last 10 lines of the CBS log file, wait for new entries to be written, filter out Appl and FOD and write the results to the console.

If I want to get more details after patching is complete, I can always run Get-WindowsUpdateLog.

This may stop working at any point of course if Microsoft change something, but for now, it gives me peace knowing that the update stuck at 23% for 47 minutes is actually being installed and I’m not about to have a long night… or not too long anyway.

Thanks for reading.

Mitigating CVE-2022-30190 via Group Policy Preference Registry Keys

willjessiamLeave a comment

On 31 May 2022, Microsoft disclosed a remote code execution vulnerability in MSDT, the Microsoft Support Diagnostic Tool. This vulnerability, CVE-2022-30190, can be exploited by sending a URL to a vulnerable system. Successful exploitation allows an attacker to install programs, view or change data, or create new accounts in line with the victim’s user permissions. There are a number of proof of concept videos getting around including one that is a bit scary that uses the file previewer in Windows to trigger the vuln. As of 1/6/22 there is no patch from Microsoft.

There are two things you can do to mitigate the vulnerability:

  1. Remove the ability for ms-msdt: URL’s to be executed
  2. Disable troubleshooting tools via group policy

Non-mitigated functionality

First, let’s see what happens before the mitigation:

Launch the troubleshooter

Or run a troubleshooter app from the start menu

The troublershooter tool runs as expected

Remove ms-msdt functionality

To remove ms-msdt URL functionality, we need the URL to not associate with the %SystemRoot%\system32\msdt.exe binary, this is achieved by deleting the ms-msdt URL handler key from the registry.

Here is the key we are talking about

Since this will be patched at some point, we want a way to be able to revert the change so I captured the default keys and added these to their own collection and targeted them at a computer that doesn’t exist (targeting will be removed once we want the original keys restored):

Original reg keys

In table form for easy viewing / copying:

HiveKeyValue NameTypeValue Data
HKEY_CLASSES_ROOTms-msdtnone (default)REG_SZURL:ms-msdt
HKEY_CLASSES_ROOTms-msdtURL ProtocolREG_SZ
HKEY_CLASSES_ROOTms-msdtEditFlagsREG_DWORD00200000 (hex)
HKEY_CLASSES_ROOTms-msdt\shellnone (default)REG_SZ
HKEY_CLASSES_ROOTms-msdt\shell\opennone (default)REG_SZ
HKEY_CLASSES_ROOTms-msdt\shell\open\commandnone (default)REG_EXPAND_SZ“%SystemRoot%\system32\msdt.exe” %1

Targeting ‘enable-ms-msdt’ collection to a non existent computer for quick restore of keys once vuln is patched

I then created a collection with the root ms-msdt key that we will be deleting:

ms-msdt key to be deleted

Disable troubleshooting tools

To disable the troubleshooting tools, the following reg key was also deployed: (see link)

EnableDiagnostics reg key to be deployed

Mitigated functionality

Launch the troubleshooter

The URL no longer has a handler to execute

Or run a troubleshooter app from the start menu

Troubleshooter can’t execute as it has been restricted by GPO

Reverting the changes

To revert the changes, all we have to do now is remove the targeting from the enable-ms-msdt collection, delete the collection that is deleting the ms-msdt key and set the EnableDiagnostics reg key to binary 1 which enables users to run troubleshooters again. In my experience the troubleshooters are pretty useless anyway so maybe I’ll leave this disabled.

Thanks for reading.