В сеть утекла Windows XP, какими это обернется последствиями

Не для кого не секрет, что недавно в сеть утекли исходники Windows XP.

В этом посте я расскажу какими именно проблемами это может обернуться. Особенно для рядового компьютера на новенькой Windows 10.

Да, да! Современную десятку это тоже заденет .

Слитый код

Слитый в сеть исходный код windows — считай открытая программа, которая содержит информацию о том как устроено ядро системы.

Если этот код в открытом виде попадает к стороннему программисту, то он с ним может сделать всего две вещи:

Очень интересно будет посмотреть доработанную XP, например с вырезанным софтом или измененным загрузчиком.

При этом один спец уже нашел в исходных кодах винды ME (тоже были слиты) полноэкранное меню пуск, которое так и не вышло на этой ОС.

А вот в коде нашли экспериментальный дизайн стартового меню для XP над которым работали в Microsoft:

Плохого в изучении и пересборке системы вроде бы ничего нет. Если конечно внутрь не засунут незаметный троян и не будут раздавать такую сборку на торрентах.

А ещё можно подменить сервер обновлений и на базе XP сделать другую ОС, доведя её до современных возможностей. Думаю один человек такое не потянет, а вот команда энтузиастов, которая почти сразу обрастет своим сообществом — легко.

Ну кому нужна в наш век старая windows xp — спросите вы?

На самом деле ее используют для некоторых специфических нужд. Недавно прошла новость, что судах ей пользуются наравне с другими.

Исходя из вышенаписаного можно сделать вывод: Если вам и нужна win xp, то не качайте её откуда попало. Берите из проверенного источника. С этого момента все кастомные сборки XP под подозрением.

Если некая группа хакеров изучит уязвимости XP

На самом деле слово если тут даже не применимо. Уже изучают. Это же лакомый кусочек. И причина на то такая: даже ядро новенькой windows 10 содержит большую часть кода от XP .

Найденная в коде XP уязвимость вполне может эксплуатироваться на десятке

Фактически это приведет к новым уязвимости на десятке, семёрке и др. версиях. На десятке то уязвимости закроют в обновлениях, а вот владельцам Windows 7 уже никто не поможет.

Хорошие новости

Существуют в принципе открытые программы и операционные системы.

Изучить их код может каждый. И ничего живут как-то, отлавливая глюки сообществом разработчиков и энтузиастов.

А ещё давненько уже Microsoft сама передавала исходные коды XP в руки властей Китая . И вот я очень не уверен, что оттуда не было утечек. Наверняка программисты Поднебесной поработали над кодом. Новость хорошая потому что это было давно, и мало отразилось на безопасности.

Спасибо за внимание, если понравилась статья ставьте палец вверх и подписывайтесь на блог, будет интересно!

Написание WinLocker’а на Python

Внимание!

Данная статья была создана в познавательных целях! Автор не несёт ответственности за ваши незаконные действия и за вред причинённый вашему компьютеру. Помните, это не игрушка какая-то, это ВИНЛОКЕР! Автор настоятельно не рекомендует запускать программу, которая описана в этой статье без детального ознакомления с кодом.

Вступление

И всем привет братва, с вами я, Геймер Дисклеймер. Как вы думаете, чем я занимался 2 дня подряд? Нет, я не в доту рубился (и вам не советую, раз уж вы себя программистами называете). Я подготавливал материал для Хабра. А точнее, создавал винлокер. И нет, я его не скоммуниздил украл у кого-то, а сам создавал его с нуля. И сегодня я научу вас его создавать. И да, если вы дисклеймер так и не прочитали, то ни в коем случае не используйте этот код во вред другим! Ну ладно, без лишних слов, погнали!

Что нам нужно?

Для создания винлокера нам понадобится:

Сам Python, установить который вы сможете на официальном сайте

Текстовый редактор, в моём случае это будет S*****e Text, цензура для того, чтобы модерация не сочла это за пиар (фактически, вы сможете его написать хоть в простом блокноте)

Доступ к интернету для установки необходимых модулей в PyPI

Компьютер, работающий на ОС Windows

Хоть какое-то базовое познание Python

Чай с молоком, или в крайнем случае кофе

Приступаем к написанию

Ну что-же, раз мы убедились, что всё необходимое у нас есть, теперь можем начинать писать код.

Создаём файл main.py в любой директории

После этого открываем его в любом редакторе.

И начинаем писать наш волшебный код.

Установка и импорт модулей

Ах да. чуть не забыл. Надо нам еще окрыть командную строку (вводим Win + R, и пишем cmd

и попадаем в командную строку.

вводим туда pip install getpass3

И у нас происходит установка

Таким же образом вводим комманды pip install pyautogui и pip install playsound

Потом возвращаемся в наш файл, и пишем в нём слудующее:

Создание окна

После этого для удобства ставим отступ, и пишем вот такое

Тут мы присваиваем переменной USER_NAME имя нашего пользователя, в моём случае это просто User.

Потом вводим в наш файл такие истрочки, пояснение будет в комментариях

Для удобства, вот вам код, который вы должны скопировать:

Запуск, и проверка кода на работоспособность

Сохраняем файл. После сохранения заходим опять в консоль, переходим в нашу директорию, где расположен файл. Делается это так:

Моя директория C:/myFiles. Поэтому моя комманда будет выглядеть вот так

потом вводим вот такую строчку:

В результате у вас должно запуститься окно.

Круто! Но ведь это ещё далеко не винлокер.

Но до этого мы ещё не дошли. Сейчас Мы поговорим про адаптивность

Делаем окно адаптивным

Давайте сначало поговорим, зачем нам это вообще нужно. Я вам скажу. Не у всех же нормальный 1920×1080 мониторы. У меня самого монитор 1366×768. А у кого-то мониторы ещё меньше

И чтобы у некоторых людей текст не вылазил за пределы экрана, мы настроим адаптивность.

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

ПРИМЕЧАНИЕ. Весь последующий код следует вставлять до строчки window.mainloop()

Опять-же вот вам весь код:

Сохраняем и проверяем. Если код не выдал ошибок, то идём дальше

Добавляем функции

Сделать окно — это конечно круто, но пока-что оно бесполезное. И это мы будем исправлять.

Сохраняем, и запускаем. Вроде-бы ничего не изменилось. Так и должно быть! Ведь мы нигде не запускали наши функции. И запускать мы их пока-что не будем. Иначе будет очень плохо

И да, на первой строчке мы видим функцию play(test) . Но постойте! там же упомянут файл sound.mp3. Но ведь его у меня нету.

Сохраняем его в директорию с нашим файлом. Если у файла название не sound.mp3, то переименовываем

Делаем апгрейд интерфейса

До этого момента у нас в окне выводился просто черный квадрат. Не вариант! Где вы видели такой винлокер?

Вводим вот эти строчки кода (опять-же, все обьясняю в комментариях):

ВНИМАНИЕ! ОКНО ЗАКРЫВАЕМ КОМБИНАЦИЕЙ КЛАВИШ ALT + F4

А ТАКЖЕ, КОД ОТ ВИНЛОКЕРА: petya

Запускаем и проверяем. Окно должно выглядеть вот так:

Если же нет, то вот вам весь код:

Убираем возможность закрытия окна путём Alt + F4

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

Нам нужно это убрать. Для этого просто вводим перед строчкой window.mainloop() строку block()

Теперь от винлокера можно избавиться вводом кода.

КОД: petya

Убираем возможность снять винлокер путём закрытия командной строки

Особо внимательные читатели додумались закрывать винлокер обычного закрытия командной строки. Если вы меня не поняли, ничего страшного. Потом поймёте. нам нужно всего лишь к файлу main.py добавить w, чтобы получилось main.pyw

Исходный код

Вот и всё! Наш винлокер готов, вот вам весь исходный код файла:

.EXE файл

Так-же вы сможете скомилировать весь код в расширение .ехе с помощью pyinstaller. Я очень добрый автор, и я решил скинуть вам установщик, замаскированный под читы для CS:GO, вы можете затроллить этим друга, но обещайте, что не будете делать атаки этим винлокером, а также, когда немножко посмеётесь, обязательно скажите пароль от винлокера:)

Заключение

В заключение я хочу сказать скептикам — делать вирусы можно хоть где. Даже на том самом PHP.

Так что всем спасибо за то, что прочитали мою статью, а модерации спасибо, в случае, если моя статься попадёт на ленту.

Изучаем дерево исходников Windows 10: от телеметрии до open source

Насколько бы закрытым ни было программное обеспечение Microsoft, информации о своем внутреннем устройстве оно выдает предостаточно. К примеру, экспорт функций из библиотеки по именам дает представление о ее интерфейсах. В свободном доступе есть и отладочные символы, которые повсеместно используются для диагностики ошибок в ОС. Однако на руках у нас все равно имеются только скомпилированные бинарные модули. Становится интересно: а какими они были до компиляции? Давайте попробуем разобраться, как вытащить побольше информации об исходных кодах, не делая ничего незаконного.

Идея, конечно, не нова. В свое время подобное делали и Марк Руссинович, и Алекс Ионеску. Мне лишь было интересно получить свежие данные, немного дополнив и уточнив уже проделанную другими работу. Для эксперимента нам понадобятся пакеты отладочных символов, которые есть в свободном доступе. Я взял пакеты для последней релизной версии «десятки» (64 бита), причем решил исследовать и релизный пакет (free build), и отладочный (checked build).

Отладочные символы — это набор файлов с расширением pdb (program database, база данных программы), в которых хранится различная информация для расширения возможностей отладки бинарных модулей в ОС, включая имена глобалов, функций и структур данных, иногда вместе с их содержимым.

Помимо символов можно взять условно доступную отладочную сборку «десятки». Такая сборка богата на ассерты, в которых бывают описаны не только недокументированые и отсуствующие в символьных файлах имена переменных, но и номер строки в файле, в котором сработал ассерт.

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

Натравливаем на файлы символов утилиту strings от sysinternals и получаем около 13 ГБ сырых данных. А вот кормить все файлы из дистрибутива отладочной сборки подряд — так себе идея, ненужных данных будет слишком много. Ограничимся набором расширений: exe — исполняемые файлы, sys — драйвера, dll — билиотеки, ocx — ActiveX-компоненты, cpl — компоненты панели управления, efi — EFI-приложения, в частности загрузчик. Сырых данных от дистрибутива набралось 5,3 ГБ.

К своему удивлению я обнаружил, что не так много программ способны хотя бы открыть файлы размером в десяток гигабайт, и уж тем более единицы смогли поддержать функцию поиска внутри таких файлов. В данном эксперименте для ручного просмотра сырых и промежуточных данных использовался 010 Editor. Фильтрация данных дешево и сердито осуществлялась скриптами на питоне.

Фильтрация данных из символьных файлов

В символьных файлах помимо прочего содержится информация компоновщика. То есть, в символьном файле присутствует список объектных файлов, которые использовались для компоновки соответствующего бинарника, причем в компоновщике используется полный путь до объектного файла.

• Зацепка-фильтр № 1: ищем строки по маске «:\\».

Получаем абсолютные пути, сортируем, удаляем дубликаты. К слову, мусора получилось не так много, и он был удален вручную.

При осмотре полученных данных стала понятна примерная структура дерева исходных кодов. Корень — «d:\th», что по всей видимости означает threshold, в соответствии с названием ноябрьской версии Windows 10 — Threshold 1. Однако файлов с корнем «d:\th» оказалось мало. Это объясняется тем, что компоновщик принимает уже собранные файлы. А сборка объектников осуществляется в папки «d:\th.obj.amd64fre» для релизной сборки и «d:\th.obj.amd64chk» для отладочной.

• Зацепка-фильтр № 2: предполагаем, что исходные файлы хранятся по аналогии с объектными файлами после сборки, и осуществляем «разборку» объектных файлов в исходные. Внимание! Этот шаг может внести искажение структуры для некоторых папок, потому как достоверно не известны параметры сборки исходников.

Для примера:
d:\th.obj.amd64fre\shell\osshell\games\freecell\objfre\amd64\freecellgame.obj
это бывший
d:\th\shell\osshell\games\freecell\freecellgame.c??

По поводу расширения файлов: объектный файл получается из кучи разных типов исходного файла: «c», «cpp», «cxx», «asm» и т. д. На данном этапе неясно, какой именно тип исходного файла использовался, поэтому оставим расширение «c??».

Помимо папки «d:\th» наблюдается множество других корней. Например, «d:\th.public.chk» и «d:\th.public.fre». Данную папку мы опустим ввиду того, что в ней хранится публичная часть sdk, то есть она нам не очень интересна. Также стоит отметить различные пути проектов для драйверов, которые, судя по всему, собираются где-то на рабочих местах разработчиков:

c:\users\joseph-liu\desktop\sources\rtl819xp_src\common\objfre_win7_amd64\amd64\eeprom.obj
C:\ALLPROJECTS\SW_MODEM\pcm\amd64\pcm.lib
C:\Palau\palau_10.4.292.0\sw\host\drivers\becndis\inbox\WS10\sandbox\Debug\x64\eth_tx.obj
C:\Users\avarde\Desktop\inbox\working\Contents\Sources\wl\sys\amd64\bcmwl63a\bcmwl63a\x64\Windows8Debug\nicpci.obj

Другими словами, существует набор драйверов устройств, отвечающих стандартам, например, USB XHCI, которые входят в дерево исходных кодов ОС. А все специфичные драйвера собираются где-то в другом месте.

• Зацепка-фильтр № 3: удаляем бинарные файлы, поскольку нам интересны только исходные. Удаляем «pdb», «lib», «exp» и т. п. Файлы «res» откатываем до «rc» — исходного кода ресурсного файла.

Выходные данные становятся все красивее! Однако на этом этапе дополнительные данные получить уже практически невозможно. Переходим к следующему набору сырых данных.

Фильтрация данных из исполняемых файлов

Поскольку абсолютных путей в сырых данных оказалось мало, фильтровать строки будем по расширениям:

• «c» — исходные файы на языке C,
• «cpp» — исходные файлы на языке C++,
• «cxx» — исходные файлы на C или C++,
• «h» — заголовочные файлы на языке C,
• «hpp» — заголовочные файлы на языке C++,
• «hxx» — заголовочные файлы на C или C++,
• «asm» — исходные файлы на MASM,
• «inc» — заголовочные файлы на MASM,
• «def» — описательный файл для библиотек

После фильтрации данных становится видно, что хотя у полученный путей и нет корня, структура каталогов говорит о том, что она строится относительно него. То есть, всем путям достаточно добавить в начале корень «d:\th».

На этом этапе есть несколько проблем с данными, полученными из символов. Первая проблема: мы не уверены, что правильно откатили путь сборки исходного файла в объектный файл.

• Зацепка-фильтр № 4: проверим, есть ли совпадения между путями до объектных файлов и путями до исходных.

И они действительно есть! То есть, для большинства каталогов можно утверждать, что их структура восстановлена правильно. Конечно, все еще остаются сомнительные каталоги, но думаю, эта погрешность вполне приемлема. Попутно можно смело заменять расширение «c??» на расширение совпавшего по пути исходника.

Вторая проблема — заголовочные файлы. Дело в том, что это важная часть исходных файлов, однако из заголовочника не получается объектный файл, а это значит, что из информации об объектных файлах нельзя восстановить заголовочники. Приходится довольствоваться малым, а именно теми заголовочниками, которые мы нашли в сырых данных бинарных файлов.

Третья проблема: мы все еще не знаем большинство расширений исходных файлов.

• Зацепка-фильтр № 5: будем считать, что в пределах одной папки хранятся исходные файлы одинакового типа.

Ну а как же исходники на ассемблере? За последним штрихом можно обратиться к Windows Research Kernel — исходным кодам Windows XP — и часть исходников на ассемблере переименовать вручную.

Изучаем полученные данные

Телеметрия

Какое-то время я изучал вопрос об устройстве телеметрии в Windows 10. К сожалению, анализ на скорую руку не выявил ничего стоящего. Я не нашел никаких кейлоггеров, никакой утечки чувствительных данных, ничего, к чему можно было бы прикопаться. И первым ключевым словом для поиска среди исходных файлов было «telemetry». Результат превзошел мои ожидания: 424 совпадения. Самые интересные приведу ниже.

Комментировать, пожалуй, не стоит, поскольку все равно достоверно ничего не известно. Однако эти данные могут послужить хорошей отправной точкой для более детального исследования.

Kernel Patch Protection

Следующая находка — всеми любимый PatchGuard. Правда, в дереве исходников ОС присутствует только один файл непонятного, скорее всего бинарного типа.
d:\th\minkernel\ntos\ke\patchgd.wmp
Поискав совпадения в нефильтрованных данных, я обнаружил, что на самом деле Kernel Patch Protection — это отдельный проект.
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen00.c??
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen01.c??
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen02.c??
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen03.c??
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen04.c??
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen05.c??
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen06.c??
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen07.c??
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen08.c??
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp\xcptgen09.c??
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp_noltcg\patchgd.c??
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp_noltcg\patchgda.c??
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp_noltcg\patchgda2.c??
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp_noltcg\patchgda3.c??
d:\bnb_kpg\minkernel\oem\src\kernel\patchgd\mp_noltcg\patchgda4.c??

Сомнительные файлы

Не придумав больше ничего меня интересующего, я начал искать все подряд — и остался доволен!

d:\th\windows\core\ntgdi\fondrv\otfd\atmdrvr\umlib\backdoor.c??
в драйвере шрифтов?

d:\th\inetcore\edgehtml\src\site\webaudio\opensource\wtf\wtfvector.h
Web Template Framework, это всего лишь Web Template Framework, спорная аббревиатура. Погодите,

Open source?

d:\th\printscan\print\drivers\renderfilters\msxpsfilters\util\opensource\libjpeg\jaricom.c??
d:\th\printscan\print\drivers\renderfilters\msxpsfilters\util\opensource\libpng\png.c??
d:\th\printscan\print\drivers\renderfilters\msxpsfilters\util\opensource\libtiff\tif_compress.c??
d:\th\printscan\print\drivers\renderfilters\msxpsfilters\util\opensource\zlib\deflate.c??
Думаю, на этой находке пора закругляться.

Архив с текстовым файлом со списком исходников приведен по ссылке. Делитесь своими находками в комментариях!