Гайд Themida под героином

Ahora_technology · 5 Апр 2023

Итак, сегодня речь будет затронута темида и ещё защиты.

Здесь анализировались следующие версии:
Repacke от

Пожалуйста, авторизуйтесь для просмотра ссылки.

(Themida v 3.0.4.0)

Пожалуйста, авторизуйтесь для просмотра ссылки.

WinLicense является просто модифицированной версией темиды,но с добавлением лицензии и другими плюшками.

Здесь будет продемонстрирован код больше x64 code,нежели x32 т.к логика почти одинакова
+ из-за ограничений по количеству слов автору пришлось пихнуть примеры в pastebin(заранее извиняюсь за это и просто вставьте его в notepad++,если надо)

Затрагиваемые моменты:
Анализ распаковки
Нахождение импорта в темиде
Обход anti-debug,anti-vm,file/register or monitor tool's
Анализ шифрование импорта
Обходим CRC file
Обходим Runtime CRC
Анализ мутации кода
Слегка анализируем VM

Так же автор попытается показать мысли/логику во время анализу,чтобы не было магическое появления информации

Распаковка
EP начинается с секции .boot и выглядит следующим образом:

Пожалуйста, авторизуйтесь для просмотра ссылки.

Я не вижу особого смысла анализировать т.к он просто расшифровывает секцию .themida и передаёт ей управление с jmp rax(просто смело пропускайте сие чудо).

в x32 аналогично

Теперь перейдём к анализу расшифровки нашей секции .text
Итак, давайте воспользуемся HWBP,чтобы не ломать голову откуда запись/чтение.
Устанавливаем HWBP на 1 байт секции.
Давайте просто начнём копать, откуда идёт запись.

Чтобы упростить анализ используем трассировку.
Нас встречает следующий код:

Пожалуйста, авторизуйтесь для просмотра ссылки.

Если упростить код
(вы всегда можете удалить jmp т.к ими часто обузят протекторы и свернуть математические операции, но об этом будет сказано в мутации кода):
Из кода выше понятно следующее:
mov eax,dword ptr ds:[rsi] - чтение зашифрованный секции
add rsi,4 прибавление + sizeof(ULONG)
;decrypt
mov dword ptr ds:[rsi],eax - запись расшифрованный байт секции .text

Быстро и лениво деобфусцируя:

sub 50F7E667 -> add 3E0A24B7-> xor 4B1068D5
or sub 12EDC1B0 -> xor 4B1068D5

В упрощённом видел:
mov eax,dword ptr ds:[rsi];чтение
add rsi,4; + sizeof(ULONG)
sub eax,12EDC1B0;расшифровка 1
xor eax,4B1068D5; расшифровка 2
mov dword ptr ds:[rsi],eax;запись расшифрованных байт

Короче, первое действие - просто расшифровка с помощью sub & xor в данном случае

Вторая запись:

Пожалуйста, авторизуйтесь для просмотра ссылки.

В упрощенном виде:
mov byte ptr ds:[rdi],al
add rsi,1
add rdi,1
sub ecx,1
mov al,byte ptr ds:[rsi]
mov byte ptr ds:[rdi],al

Но погодите-ка, ведь адрес в rsi вообще выделен в отдельном регионе?
Ну, протектор, видимо, решил использовать данный трюк для усложнения + потом я покажу, что он использует этот трюк в другом месте.

Отсюда растут ноги в запись в выделенную память.
Я не хочу пихать код т.к он очень большой, но он напоминает распаковку секции .themida т.к так же юзается
add dl, dl
Сам график(код в первоначальном виде т.е jmp не очищены и прочие приколы):

Нас интересует эта часть кода:
ret 0x18
или в x32 бинарнике
ret 0xC
Из моих опытов, всегда после этой инструкции идёт jmp,благодаря чему можно составить сигнатуру
x64 - C2 18 00 E9
x32 - C2 0C 00 E9
Это будет первая точка остановы с поиском импорта, которая сработает при поиске этого паттерна.
Давайте проверим мои слова:

и само выполнение кода:

Получаем следующие NtApi/Api:

Пожалуйста, авторизуйтесь для просмотра ссылки.

В теории вы можете просто перехватить это добро, чтобы,например, обойти anti-debug,CRC file и т.д

Так же в x64 бинарнике юзается VEH(в дальнейшем он удаляется).
Почему же они его юзают?
Ответ не застав долго ждать:

Начнём с простого т.к обнаружение мониторов для реестра/файлов.
Из списка выше понятно, что юзается FindWindows и вот список:

x32:
FindWindows
lpClassName:
"OLLYDBG"
"GBDYLLO"
"pediy06"
"PROCMON_WINDOW_CLASS"

lpWindowName :
"File Monitor - Sysinternals:

Пожалуйста, авторизуйтесь для просмотра ссылки.

"
"Process Monitor - Sysinternals:

Пожалуйста, авторизуйтесь для просмотра ссылки.

"

x64:
FindWindows
lpClassName:
"PROCMON_WINDOW_CLASS"
"RegmonClass"
"18467-41"
"Registry Monitor - Sysinternals:

Пожалуйста, авторизуйтесь для просмотра ссылки.

"

lpWindowName :
"Process Monitor - Sysinternals:

Пожалуйста, авторизуйтесь для просмотра ссылки.

"
"File Monitor - Sysinternals:

Пожалуйста, авторизуйтесь для просмотра ссылки.

"

Однако, это не весь список WinApi/NtApi. WTF????(попробуйте только пропатчить FindWindows и запустить программу под темидой с детектом monitor tools)
Ну, ответ довольно прост:GetProcAddress(особенно из-за получения его выше темидой).
Лично автор решил данную проблему так: начинать трассировку, скопировать адрес NtApi/WinApi и когда индекс трассировки будет >50k смотреть данный адрес(трассировка->поиск-> константа)
Я так сделал и рекомендую так делать т.к разработчики протектора могут начать получать адрес в другом месте,хотя вы можете потратить много времени на это.

В любом случае, у нас есть в списке импорта lstrcmpiA на этот WinApi,поэтому ставим bp и мы получим следующий список драйверов:

NtQuerySystemInformation with SystemModuleInformation

CONST CHAR* bad_list_driver_monitor[] =
{
"FileMonitor.sys"
"Filem"
"REGMON"
"regsys"
"sysregm"
"PROCMON"
"Kernel Detective"
"CisUtMonitor"
"Revoflt"

};

Так же создаётся поток, который будет вызывать FindWindowA(можно просто сделать прыжок на свой же адрес т.е EB FE,заморозить поток и т.д).
Anti-debug(x64/x32):

Loader:
NtOpenSection + NtMapViewOfSection Map ntdll file(KnownDlls)(берёт только NtQueryInformationProcess)
NtSetInformationThread with ThreadHideFromDebugger
CheckRemoteDebuggerPresent -> ProcessDebugPort
GetThreadContext -> NtGetThreadContext
NtQueryInformationProcess with ProcessDebugPort/ProcessDebugObjectHandle
GetForegroundWindow -> NtUserGetForegroundWindow
GetWindowText -> GetWindowThreadProcessId -> NtUserQueryWindow

NtQuerySystemInformation with SystemModuleInformation
CONST CHAR* bad_list_driver_anti_debug[] =
{
ntice.sys
iceext.sys
Syser.sys
HanOlly.sys
extrem.sys
FRDTSC.SYS
fengyue.sys
};
VirtualProtect -> NtProtectVirtualMemory -> IsBadWritePtr -> DbgUiRemoteBreakin goto(jmp) LdrShutdownProcess
VirtualProtect -> NtProtectVirtualMemory -> DbgUiRemoteBreakin -> ret

Анти-дебаг в лоадере аналогичен в SDK за исключением SystemModuleInformation.

Anti-VM:

x64
Компьютер\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000 -> DriverDesc
Компьютер\HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System -> SystemBiosVersion\VideoBiosVersion
Компьютер\HKEY_LOCAL_MACHINE\HARDWARE\ACPI\DSDT\VBOX__
GetSystemFirmwareTable(NtQuerySystemInformation with SystemFirmwareTableInformation) + BMSR

x32
in eax,dx ; eax - (68584D56)hXMV, dx - XV
in eax,dx eax - (564D5868)VMXh,dx - VX
Мне было лень полностью анализировать т.к они юзают что-то ещё и достать быстро не получилось:
Компьютер\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000 -> DriverDesc
Компьютер\HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System -> SystemBiosVersion\VideoBiosVersion
Компьютер\HKEY_LOCAL_MACHINE\HARDWARE\ACPI\DSDT\VBOX__
GetSystemFirmwareTable(NtQuerySystemInformation with SystemFirmwareTableInformation) + BMSR
И как-то ешё трюк, который мне лень анализировать из-за нехватки времени

anti-sandbox(x32/x64):
GetModuleHandleA:
cmdvrt32.dll
SbieDll.dll(Hi,VMProtect)

Обфускация импорта

При трассировке видим следящее:

Пожалуйста, авторизуйтесь для просмотра ссылки.

Нас должно зацепить следующее:
1)Способ получения начала секции
через:
call$+5
pop rbp
sub rbp,31E3F

2)Последняя операция с расшифровкой импорта:
00007FF7FDDFD631 or rax,reg ; decrypt address

3)Запихивание переменной в стек через push и при этом с 2 регистрами:
00007FF7FDE07979 | FF3428 | push qword ptr ds:[rax+rbp]

Я не вижу смысла деобфусцировать т.к можно понять логику и скажу следущее:
1)Протектор должен прочитать откуда-то зашифрованное значение и расшифровать(в моём случае оно находится в секции .winlicense) -> можно поставить PAGE GUARD hook
Первое чтение идёт как раз из push qword ptr ds:[rax+rbp] ; push qword ptr ds:[offset+start_secthion] (offset - 255B4)
Это делается из-за того,чтобы не убивать скорость выполнение программы т.к под VM займёт куда больше операций,а отсюда и времени
2)((res_offset - 7C4591CA) ^ 7D0AE1FA) | FFFFFFFF
Здесь идут операции :sub,xor,and
3)
push reg
mov qword ptr ss:[rsp],decrypt_address

При анализе я всегда встречал 3 пункта с верху(так же jmp,похоже,всегда вставляется даже при виртуализированном коде т.е начинать сканирование нужно от jmp),поэтому можно сделать логику для расшифровки импортов.

в x32:

Пожалуйста, авторизуйтесь для просмотра ссылки.

1)Встречаем так же push dword ptr ss:[ebp+eax]
2)В конце используется xor для расшифровки
3) Так же в упрощённом виде:
push reg
mov qword ptr ss:[esp],decrypt_address

Аналогично так же с возможностью с расшифровкой автоматический(поиск jmp + проверка команд и меньше ~150 операций перед ret), но только нужно проверять на xor eax,reg в x32

Обходим CRC file

Итак, немного пояснения, чтобы не было проблем в различии CRC.
CRC используется протекторами для обнаружения изменений в файле/в секции.
Основная идея CRC file - обнаружить практический любое изменение байт в файле,за исключением некоторых моментов в файле + где сохраняется значение.
CRC подвергается коллизии, но этот способ неудобен в данном случае для обхода т.к нужно анализировать сам алгоритм,а он может быть в VM.
Самый простой способ - найти где сохраняется итоговый результат CRC или подменить файл на оригинальный.

Themida использует следующий способ подсчёта:
Themida использует следующий способ подсчёта CRC файла:
GetModuleFileName
CreateFileW
GetFileSize
CreateFileMappingW
MapViewOfFile
UnmapViewOfFile

Можно просто подменять файл и это работает,но давайте избавимся от бесполезной работы.
В данном примере понадобится CTF exploler для создания новой секции и вставки оригинального файла в новую секцию.
File -> open -> secthion headers -> add secthion(file data) и кидаем оригинальный файл -> add secthion(empty space) -> у новой секции change secthion flag ->
Is executeble и ставим галочку т.к туда будем пихать наш код.
Можно написать dll без crt и скопировать код(единственно, что вам нужно будет сделать: сохранять почти все регистры и Rlag/Eflag) и передавать туда выполнение
(вы сможете хукнуть эти api раньше, например, чем будет вообще выполнена распаковка(изменение EP на свой код)).
В данном примере автор продемонстрирует патчинг vm-entry после вызова API.
Логика обхода(в данном случае была дефолтная VM т.е Tiger Rea):
1)Делаем подмену rax/eax после вызова MapViewOfFile и сохраняем оригинальное значение, если вызов вернул не NULL
2)Делаем подмену размер файла(это не обязательно, но будем пунктуальные в этом плане)
3)Возвращаем оригинальный выделенный адрес из MapViewOfFile в UnmapViewOfFile т.к иначе будет unmap нашей секции или по-простому: нам кирдык.

Ставим bp на MapViewOfFile,GetFileSize и проверяем вызывается ли vm-handler пару раз или только 1 раз.
В моём случае он вызывался только 1 раз.
Мы должны получить адрес выхода vm перед вызовом UnmapViewOfFile т.к это убьёт наш файл.
Ставим bp на обращение к последним байтам,чтобы не снимать ооооочень длинную трассировку и начинаем трассировку,пока не дойдём до вызова.
У автора много раз вызывалась vm-exit,поэтому нужно ставить условие на подмену rax/eax.

Будет прикреплён с файлом в качестве примера.

Краткий обзор файла и пример обхода crc file(будет прикреплены в качестве примера):

rva: header va : offset file
5E36E4 : 00000001405E36E4 : 5DE4E4 - filze size(vm-entry)
5CA074 : 00000001405CA074 : 5C4E74 - map file(vm-entry)
3A6E7 : 000000014003A6E7 : 354E7 - unmap file(vm-exit call api or jmp next code)

call GetFileSize -> vm-emtry -> jmp patch ->
mov eax,0x674E00 ;размер полученный в оригинальном файле с помощью GetFileSize
pushfq ; восстанавливаем украденные байты
sub rsp,0x8
jmp winlicense_test_protected_2_11.7FF7966A36E9

MapViewOfFile -> vm-entry -> jmp patch ->
mov qword ptr ds:[0x7FF79673A120],rax ;сохраняем значение относительно rip + offset
lea rax,qword ptr ds:[0x7FF79673B000] ; получаем адрес оригинального файла в секции относительно rip
pushfq ; восстанавливаем украденные байты
push 0x6FF5AC8B
jmp winlicense_test_protected_2_11.7FF79668A079

Тут вообще должна быть проверка сначала:
cmp rax,0
но весь рофл в том,что темида всё-равно будет читать, если даже при неудачном NTSTATUS

pop rcx ; rcx - наш адрес, который мы подменили
push rdx
lea rdx,qword ptr ds:[0x7FF79673B000]; получаем адрес скопированной нашего файла
cmp rcx,rdx;наш подменённый адрес
jne winlicense_test_protected_2_11.7FF79673A051
mov rcx,qword ptr ds:[0x7FF79673A120] ; подменяем, иначе будет худо нам
pop rdx
pop rax ; просто восстанавливаем украденные байты
popfq
ret 0x0

Браво! Вы обошли CRC file ничего особо не делая!
Можно другими способами, но я продемонстрировал, который пришёл самый первый в голову автора.

в x32 почти аналогично.

Обходим Runtime CRC
или
Я купил себе машину, думал, круче не найти,
Откатал на ней неделю, сдохла, мать её ити!

Я называю так CRC т.к проверка может быть выполнена только в runtime самого вашего кода(CHECK_CODE_INTEGRITY ).
На самом деле CRC секции подсчитано и оно просто вычисляется заново & сравняется с готовым CRC.
Так же CRC runtime проверяет только патч ER секции(.text),а не другие и тем более VM(я не видел,чтобы темида его проверяла и сама пять ERW)

Итак, начинаем с того, что мы пробуем пропатчить любой байт в .text секции и мы получаем обнаружение.
Попробуем изменить безобидный code cave(int3) и получаем обнаружение:

Посмотри откуда идёт чтение:

видим такую ситуацию:

Пожалуйста, авторизуйтесь для просмотра ссылки.

Вас должен сразу смутить следущий код:
00007FF6BFEC86DD | mov bl,0x7
Значение перезаписывается т.е оно сохраняется где-то сверху и как раз после чтения идёт запись в RW регион памяти!

Теперь ставим там bp на обращение и смотрим, откуда идёт чтение:

00007FF6C044CFB4 | add eax,dword ptr ds:[r11]
и
00007FF6C044CE4C | xor eax,dword ptr ds:[rdx]
Если посмотрим на график,то это просто мутированный код и нам повезло!
График:

В упрощённом виде:

loop_read:
00007FF6C044CFB4 | add eax,dword ptr ds:[r11]
00007FF6C03F9184 | rol eax,10
00007FF6C044CE2B | push rdx
00007FF6C044CE42 | add rdx,rsi
00007FF6C044CE4C | xor eax,dword ptr ds:[rdx]
00007FF6C044CE52 | pop rdx
00007FF6C044E2F3 | add rsi,4; +sizeof(ULONG)
00007FF6C044F16E | sub ecx,1
00007FF6C03C5C6D | test ecx,ecx
00007FF6C0403D1F | je winlicense_test_protected.stop_scan
00007FF6C0403D25 | jmp winlicense_test_protected.loop_read

stop_scan:
00007FF6C0433708 | 8945 E0 | mov dword ptr ss:[rbp-20],eax
00007FF6C044FE30 | FF75 E4 | push qword ptr ss:[rbp-1C]
00007FF6C044B12F | FF97 D9310600 | call qword ptr ds:[rdi+631D9]; прыжок в VM

Дальше нас особо код не интересует
*Часть кода пропущена и основная логика без этого понятна.

Итак,здесь просто происходит цикл, да ещё и не в VM! ЛЯПОТА!
Результат сохраняется в eax и давайте его попробуем пропатчить!
убираем все патчи -> получаем оригинальный результат CRC(eax - 00000000F84B2AA5) -> видим E9 00000000 | jmp winlicense_test_protected.7FF6C044F287(идёт после pop rax) и меняем на:
mov eax,0xF84B2AA5 (5 байт как раз)
Ура! Мы обошли CRC runtime!

В крайнем случае вы можете всегда найти все места откуда идёт чтение и постепенно пропатчит их/просто давать скопированный регион.
С x32 такая же история.

Анализ мутации кода

До мутации:

После:

и

Поэтапно будем разбирать:
1)Злоупотреблением jmp.

00007FF786810E86 | add rsp,8
00007FF786810E8A | jmp winlicense_test_protected.7FF786803559
00007FF786803559 | push 77CC7B6D
00007FF78680355E | mov qword ptr ss:[rsp],rsi
00007FF786803562 | mov rsi,rsp
00007FF786803565 | add rsi,8
00007FF786803569 | sub rsi,8

Если смотреть просто дизассемблированный код,то видим следящее:
00007FF78680355D ja winlicense_test_protected.7FF7868035A7
00007FF78680355F mov dword ptr ss:[rsp],esi
00007FF786803562 mov rsi,rsp
00007FF786803565 add rsi,8
00007FF786803569 sub rsi,8

;some code

Пожалуйста, авторизуйтесь для просмотра ссылки.

;some code
rcx будет преобразован в 140000000

и

Пожалуйста, авторизуйтесь для просмотра ссылки.

mov eax, 80008001- код,который была мутированная

Трассировка:

Пожалуйста, авторизуйтесь для просмотра ссылки.

Нас интересует только это:

7FF786170000 - PE файла
7FF7861AA888 - ret address

Пожалуйста, авторизуйтесь для просмотра ссылки.

Пожалуйста, авторизуйтесь для просмотра ссылки.

Пожалуйста, авторизуйтесь для просмотра ссылки.

Статья подошла к своему концу из-за нехватки времени.
Be robbers and ravagers as long as you cannot be rulers and owners, you men of knowledgel...

Пожалуйста, авторизуйтесь для просмотра ссылки.

:

Пожалуйста, авторизуйтесь для просмотра ссылки.

idesync · 6 Апр 2023

Ахуенно огромная стена текста. Чуть не умер, пока листал до низа, чтобы поставить лайк.
Мне этот гайд ни к чему, но, думаю, заинтересованным людям максимально зайдёт.

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

mj12 · 6 Апр 2023

Ahora57 написал(а):
Repacke от
Пожалуйста, авторизуйтесь для просмотра ссылки.
(Themida v 3.0.4.0)

Перешёл по ссылке и ахренел, такого я не видел даже на r0crew
Лол с каких это пор китайцы так эволюционировали, прошло вроде немного с "футболка шорта по пять" до patch themida virtualizer, + они даже за хвх шарят, во дают

TTYPO_6aHaH · 6 Апр 2023

Это все очень интересно, а героин где?

Ahora_technology · 6 Апр 2023

idesync написал(а):
Ахуенно огромная стена текста. Чуть не умер, пока листал до низа, чтобы поставить лайк.
Мне этот гайд ни к чему, но, думаю, заинтересованным людям максимально зайдёт.

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

Да,с оформлением текста траблы т.к мне пришлось сократить сие чудо где-то минимум в 2 раза + перетаскивать код в pastebin

TTYPO_6aHaH написал(а):
Это все очень интересно, а героин где?

Героин был использован частично для анализа, но большая часть осталась для анализа самих VM oreans :LUL:

dsiboy08 · 4 Май 2023

ничего не понял но было интересно

Catharsis · 9 Май 2023

Ahora57 написал(а):
Anti-VM:

Ahora57 написал(а):
И как-то ешё трюк, который мне лень анализировать из-за нехватки времени

Вот этот:

(я Рафаэлю этот метод и репортил, так как детект VM был уж совсем плохой)
rtdsc + cpuid и получаем еще один детект VM
Только надо покрутить пару сотен итераций, отсортировать результаты, взять медианное значение и сравнить с эталонным.

Ahora_technology · 9 Май 2023

Catharsis написал(а):
Вот этот:

(я Рафаэлю этот метод и репортил, так как детект VM был уж совсем плохой)
rtdsc + cpuid и получаем еще один детект VM
Только надо покрутить пару сотен итераций, отсортировать результаты, взять медианное значение и сравнить с эталонным.

rdtsc с VM-exit хороший пример обнаружения гипервизора, но его популярность приводит к

Пожалуйста, авторизуйтесь для просмотра ссылки.

обнаружения самого гипервизора.
Я лично предлагал Пермякому переписать anti-vm т.к способ обхода давно

Пожалуйста, авторизуйтесь для просмотра ссылки.

.
Если говорить про специальные детекты,то для VMWare можно использовать

Пожалуйста, авторизуйтесь для просмотра ссылки.

т.к это неплохой отпечаток VM.
Для VirtualBox достаточно

Пожалуйста, авторизуйтесь для просмотра ссылки.

т.к его неправильно обрабатывает VirtualBox(который и использует VMP уже много лет).
Хорошим примером обнаружением гипервизора является на мой взгляд

Пожалуйста, авторизуйтесь для просмотра ссылки.

.

• Breakpoint-Condition Detected (B3–B0)—Bits 3:0. The processor updates these four bits on every
debug breakpoint or general-detect condition. A bit is set to 1 if the corresponding addressbreakpoint register detects an enabled breakpoint condition, as specified by the DR7 Ln, Gn, R/Wn
and LENn controls, and is cleared to 0 otherwise. For example, B1 (bit 1) is set to 1 if an addressbreakpoint condition is detected by DR1.

• Single Step (BS)—Bit 14. The processor sets this bit to 1 if the #DB exception occurs as a result of
single-step mode (rFLAGS[TF] = 1). Single-step mode has the highest-priority among debug
exceptions. Other status bits within the DR6 register can be set by the processor along with the BS
bit.

• B0 through B3 (breakpoint condition detected) flags (bits 0 through 3) — Indicates (when set) that its
associated breakpoint condition was met when a debug exception was generated. These flags are set if the
condition described for each breakpoint by the LENn, and R/Wn flags in debug control register DR7 is true.
They may or may not be set if the breakpoint is not enabled by the Ln or the Gn flags in register DR7. Therefore
on a #DB, a debug handler should check only those B0-B3 bits which correspond to an enabled breakpoint.

• BS (single step) flag (bit 14) — Indicates (when set) that the debug exception was triggered by the singlestep execution mode (enabled with the TF flag in the EFLAGS register). The single-step mode is the highestpriority debug exception. When the BS flag is set, any of the other debug status bits also may be set.

OXXXYMlRON · 30 Май 2023

no spinlock?

Kodama · 30 Май 2023

OXXXXYMIRON написал(а):
no spinlock?

Разрабы выкупили насколько он смешной видимо