Pages
Wednesday, December 13, 2023
What's New in OneDriveExplorer
Wednesday, September 20, 2023
OneDriveExplorer ODL Parsing Issues
The Issue
Recently, I've been noticing there have been quite a few instances where OneDriveExplorer was unable to parse out some of the ODL logs and in other instances the parameters of the logs are a jumbled mess.
Finding the issue
There has to be something in the way these tools are handling the data (OneDriveExplore's ODL parsing is based off of Yogesh's work). If we look at Yogesh's blog post, he has laid out nicely the structure of the ODL files.
The fix
I reached out to Yogesh to see if he had noticed any changes with the ODL files. Upon further examination, Yogesh noticed the ODL version had changed along with the structures for the data_block and data had also changed.
Results
Updated parser = 1,921,804 entries, no errors, parameters parsed properly
Old parser = 959,819 entries, 15 files could not be read, some parameters jumbled
This ODL version change occurred in v23.180.0828.0001 and later. It might be a good idea to recheck any forensics examinations that have been performed on this version or higher. v23.180.0828.0001 rolled out on 9/01/23 as an insider build so the window is fairly small. The latest release of OneDriveExplorer can be found here.
Thursday, September 7, 2023
What's New in OneDriveExplorer
It's been about a year and a half since the initial release of OneDriveExplorer. With this being a major release, I thought I'd write about some of the updates and improvements. I've been working hard in my spare time to add in data as it is discovered and to give the best user experience possible. With that said, lets look at some of the improvements and features with this release.
Updated dat parser
The way OnedDriveExplorer initially would parse information out of the dat file was with regex. With the limited dataset, at the time, this was the best viable option. The problem with this approach is that it made it difficult to reliably extract more data. After analyzing 300+ OneDrive installs, the structures in the data file became better understood. OneDriveExplore is now able to "walk" the dat file from beginning to end without the need for regex making it more reliable and able to extract more data.
SQLite parsing
Although not entirely new, it appears OneDrive is moving away from the proprietary dat file to SQLite. OneDriveExplorer is able to parse these new SQLite files and there have already been instances where the dat file has been removed from the settings folder. So rest assure, OneDriveExplorer has your back.
Updated GUI and Status Column
The GUI now has a three pane view, much like Windows File Explorer. The left pane features a folder navigation view. The center pane shows files and folders in the selected folder along with the status, date modified and file size. The right pane gives you more details about the file or folder selected. A thing to note about the status column. There may be times a number appears in the column. This is the status number form the raw data. If visible, the status meaning is not entirely understood.
Another slight change is the search function. Instead of highlighting the matches found, they are now populated in the center pane.
The latest release of OneDriveExplorer can be found here.
Friday, May 26, 2023
The curious case of ♪ and ◙
I was recently reading Chad Tilbury's post Finding Evil WMI Event Consumers with Disk Forensics and it reminded me of something. I have a script that automates the collection and parsing of KAPE that uses WMI event consumers and filters. The problem was, I needed a way to pass parameters to the the encrypted powershell script in the consumer. I found some information about putting the parameters in a file and reading the file to get the parameters. The problem with this solution is I needed the parameters to be dynamic. So what does one do in this case? This is where ♪ and ◙ come into play.
What is ♪ and ◙ in the first place?
These strange characters can be created using ALT codes (hello 90's). The first one ♪, can be created by holding down the alt key and typing 13 on the number pad. ◙ can be created by holding down the alt key and typing 10 on the number pad. A little bit of history behind ALT codes according to Wikipedia:
"On IBM PC compatible personal computers from the 1980s, the BIOS allowed the user to hold down the Alt
key and type a decimal number on the keypad. It would place the corresponding code into the keyboard buffer so that it would look (almost) as if the code had been entered by a single keystroke. Applications reading keystrokes from the BIOS would behave according to what action they associate with that code. Some would interpret the code as a command, but often it would be interpreted as a code to be placed on the screen at the location of the cursor, thus displaying the corresponding 8-bit character from the current code page. On the original IBM PC this was CP437. In most cases typing a number greater than 255 produced the character associated with the remainder after the number is divided by 256."
Passing parameters to Powershell in a WMI consumer
So, how do we use this to our advantage to pass parameters to an encrypted powershell script? Lets say we have the following script:
Next, we'll take the script and encode it.
PS C:\Temp\Demo> $text = {
param
(
[Parameter(Mandatory)]
[string]
$FileName,[Parameter(Mandatory)]
[string]
$Extension
)
Write-Host "Filter Fired"
$filein = $FileName +"."+ $Extension
$fileout = $FileName +".zip"
Write-Host $filein
Write-Host $fileoutCompress-Archive -LiteralPath $filein -DestinationPath $fileout
Remove-Item -Path $filein
}
PS C:\Temp\Demo> $PScommand = [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($text))
PS C:\Temp\Demo> $PScommand
CgBwAGEAcgBhAG0ACgAoAAoAIAAgACAAIABbAFAAYQByAGEAbQBlAHQAZQByACgATQBhAG4AZABhAHQAbwByAHkAKQBdAAoAIAAgACAAIABbAHMAdAByAGkAbgBnAF0ACgAgACAAIAAgACQARgBpAGwAZQBOAGEAbQBlACwACgAgACAAIAAgAAoAIAAgACAAIABbAFAAYQByAGEAbQBlAHQAZQByACgATQBhAG4AZABhAHQAbwByAHkAKQBdAAoAIAAgACAAIABbAHMAdAByAGkAbgBnAF0ACgAgACAAIAAgACQARQB4AHQAZQBuAHMAaQBvAG4ACgApAAoAIAAgACAAIABXAHIAaQB0AGUALQBIAG8AcwB0ACAAIgBGAGkAbAB0AGUAcgAgAEYAaQByAGUAZAAiAAoAIAAgACAAIAAkAGYAaQBsAGUAaQBuACAAPQAgACQARgBpAGwAZQBOAGEAbQBlAC4AVAByAGkAbQAoACkAKwAiAC4AIgArACQARQB4AHQAZQBuAHMAaQBvAG4ACgAgACAAIAAgACQAZgBpAGwAZQBvAHUAdAAgAD0AIAAkAEYAaQBsAGUATgBhAG0AZQAuAFQAcgBpAG0AKAApACsAIgAuAHoAaQBwACIACgAgACAAIAAgAFcAcgBpAHQAZQAtAEgAbwBzAHQAIAAkAGYAaQBsAGUAaQBuAAoAIAAgACAAIABXAHIAaQB0AGUALQBIAG8AcwB0ACAAJABmAGkAbABlAG8AdQB0AAoAIAAgACAAIAAKACAAIAAgACAAQwBvAG0AcAByAGUAcwBzAC0AQQByAGMAaABpAHYAZQAgAC0ATABpAHQAZQByAGEAbABQAGEAdABoACAAJABmAGkAbABlAGkAbgAgAC0ARABlAHMAdABpAG4AYQB0AGkAbwBuAFAAYQB0AGgAIAAkAGYAaQBsAGUAbwB1AHQACgAKACAAIAAgACAAUgBlAG0AbwB2AGUALQBJAHQAZQBtACAALQBQAGEAdABoACAAJABmAGkAbABlAGkAbgAKAA==
If we try and run this command and pass the parameters to it, we get the following error:
Another way we could do this is to just run the command and answer the prompts, like so:
Unfortunately, the mandatory parameters are needed but we do not have access to the command line to pass them in a WMI consumer. Lets try echoing the parameters.
Still no luck. The command prompt does not recognize \n as a line feed. Lets try something a little crazy here. We'll replace \n with ◙.
Bingo! But why does this work? If we look at the code page, we can see that ◙ is interpreted as LF (Line Feed) and ♪ as CR (Carriage Return).