What's New in OneDriveExplorer

Key updates 

There are a couple of improvements to this version of OneDriveExplorer (ODE). First off, the much needed update to the json output. This will make it easier to add new elements and removes all the unneeded ones. The next improvement was to the status column. The various statuses have been figured out so you will no longer see a number next to the unknown ones. With the status figured out, OneDriveExplorer can now properly nest the folder structure and tell the difference between synced and linked libraries. The parentScopeID, parentResourceID, and resourceID are also properly parsed now.

Lets look at the data

If we compare the new version of ODE to the previous one, some interesting things jump out. We can clearly see which folder is the users OneDrive folder and which ones have been synced. You will also notice that the status column has been updated with the proper statuses.

Status meaning

The following are the OneDrive statuses that are recorded and their meaning:  

The interesting thing with the status codes are that not synced and not linked are not on the users file system. Whenever we perform a sync or link to a library, the OneDrive client pulls all the information from the head of the library. In turn, we are able to see with ODE data for the entire library whether the files/folders are on the endpoint or not. 

The latest version of OneDriveExplorer can be found here.

Additional updates

The <UserCid>.dat page has been updated with the latest information on the file format.

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.

So I tried Yogesh Khatri's OneDrive to see if it was something OneDriveExplore was doing wrong. It generated quite a few "Error in read_string()" and "ERROR writing rows: <class '_csv.Error'> need to escape, but no escapechar set" errors and the same jumbled mess appeared in some of the Params_Decoded field.

Something seems to be amiss.

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.

With this information, I slightly modified OneDriveExplorer to dump out the structures so they could be examined. As it turned out, for some reason, some of the data blocks do not follow this same structure. From the output, I could see the data_len was an absurdly large number, throwing off the parser in both tools.

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.

With this information, Yogesh and I have updated our tools to parse the ODL files. Running OneDriveExplorer again now shows everything is properly aligned.

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.

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.

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 $fileout

    Compress-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).