Что такое исходный код windows

Обновлено: 04.07.2024

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

В сеть попал исходный код Windows XP SP1 и других версий операционной системы. На форуме 4chan опубликовали 43 гигабайта файлов, которые можно загрузить через Torrent.

Помимо Windows XP и Server 2003 в файлах утечки можно обнаружить и более старые версии операционной системы Microsoft. В том числе MS DOS 3.30, MS DOS 6.0, Windows 2000, Windows CE 3, 4 и 5, Windows Embedded 7, Windows Embedded CE, Windows NT 3.5 и Windows NT 4.

Утечка включает в себя исходные коды DirectX 8, Microsoft Paint, игр Hearts на C++, Reversi и «Пасьянса». Кроме того, в файлах можно обнаружить коды mssipotf, которые позволяют подписывать файлы шрифтов и проверять подписи, mscms — системы управления цветом от Microsoft и Postscript шрифтов UI драйвер NT\printscan\print\drivers\usermode\driverui\ps и makentf.

Среди файлов также есть папка с названием «медиа», в которой можно найти коллекцию видео с конспирологическими теориями вокруг Билла Гейтса. В дополнение к торрент-файлу неизвестные опубликовали архив только с исходным кодом XP и Windows Server 2003 на 2,9 Гб.

Как утверждает автор утечки, исходный код Windows XP «годами» перемещался от хакера к хакеру, но впервые оказался доступен публично. В Microsoft пока не подтвердили, действительно ли в сеть попал код её старых ОС.

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

Несмотря на то, что Windows XP вышла почти 20 лет назад, утечка её исходного кода может представлять опасность для современных компьютеров. Если в Microsoft всё ещё используют какие-то части кода в новых версиях систем, то в них могли попасть те же уязвимости и баги.

Кроме того, многие государственные ведомства и отдельные организации по всему миру всё ещё используют Windows XP для работы. По данным на август 2020 года, на старой системе работало 1,2% компьютеров в мире или около 25 миллионов устройств — это больше, чем на Windows 8 (0,57%), ChromeOS (0,42%) и Windows Vista (0,12%).

Microsoft прекратила поддержку Windows XP ещё в апреле 2014 года. Таким образом, система уже более шести лет не получала важных технических обновлений и патчей безопасности.

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

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

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

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

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

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

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

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

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

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

При осмотре полученных данных стала понятна примерная структура дерева исходных кодов. Корень — «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??».

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» — описательный файл для библиотек

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

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

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

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

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

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

То есть, если в какой-либо из папок уже присутствует файл с расширением «cpp», скорее всего все его соседи будут иметь такое же расширение.

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

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

Телеметрия

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

d:\th\admin\enterprisemgmt\enterprisecsps\v2\certificatecore\certificatestoretelemetry.cpp
d:\th\base\appcompat\appraiser\heads\telemetry\telemetryappraiser.cpp
d:\th\base\appmodel\search\common\telemetry\telemetry.cpp
d:\th\base\diagnosis\feedback\siuf\libs\telemetry\siufdatacustom.c??
d:\th\base\diagnosis\pdui\de\wizard\wizardtelemetryprovider.c??
d:\th\base\enterpriseclientsync\settingsync\azure\lib\azuresettingsyncprovidertelemetry.cpp
d:\th\base\fs\exfat\telemetry.c
d:\th\base\fs\fastfat\telemetry.c
d:\th\base\fs\udfs\telemetry.c
d:\th\base\power\energy\platformtelemetry.c??
d:\th\base\power\energy\sleepstudytelemetry.c??
d:\th\base\stor\vds\diskpart\diskparttelemetry.c??
d:\th\base\stor\vds\diskraid\diskraidtelemetry.cpp
d:\th\base\win32\winnls\els\advancedservices\spelling\platformspecific\current\spellingtelemetry.c??
d:\th\drivers\input\hid\hidcore\hidclass\telemetry.h
d:\th\drivers\mobilepc\location\product\core\crowdsource\locationoriontelemetry.cpp
d:\th\drivers\mobilepc\sensors\common\helpers\sensorstelemetry.cpp
d:\th\drivers\wdm\bluetooth\user\bthtelemetry\bthtelemetry.c??
d:\th\drivers\wdm\bluetooth\user\bthtelemetry\fingerprintcollector.c??
d:\th\drivers\wdm\bluetooth\user\bthtelemetry\localradiocollector.c??
d:\th\drivers\wdm\usb\telemetry\registry.c??
d:\th\drivers\wdm\usb\telemetry\telemetry.c??
d:\th\ds\dns\server\server\dnsexe\dnstelemetry.c??
d:\th\ds\ext\live\identity\lib\tracing\lite\microsoftaccounttelemetry.c??
d:\th\ds\security\base\lsa\server\cfiles\telemetry.c
d:\th\ds\security\protocols\msv_sspi\dll\ntlmtelemetry.c??
d:\th\ds\security\protocols\ssl\telemetry\telemetry.c??
d:\th\ds\security\protocols\sspcommon\ssptelemetry.c??
d:\th\enduser\windowsupdate\client\installagent\common\commontelemetry.cpp
d:\th\enduser\winstore\licensemanager\lib\telemetry.cpp
d:\th\minio\ndis\sys\mp\ndistelemetry.c??
d:\th\minio\security\base\lsa\security\driver\telemetry.cxx
d:\th\minkernel\fs\cdfs\telemetry.c
d:\th\minkernel\fs\ntfs\mp\telemetry.c??
d:\th\minkernel\fs\refs\mp\telemetry.c??
d:\th\net\netio\iphlpsvc\service\teredo_telemetry.c
d:\th\net\peernetng\torino\telemetry\notelemetry\peerdistnotelemetry.c??
d:\th\net\rras\ip\nathlp\dhcp\telemetryutils.c??
d:\th\net\winrt\networking\src\sockets\socketstelemetry.h
d:\th\shell\cortana\cortanaui\src\telemetrymanager.cpp
d:\th\shell\explorer\traynotificationareatelemetry.h
d:\th\shell\explorerframe\dll\ribbontelemetry.c??
d:\th\shell\fileexplorer\product\fileexplorertelemetry.c??
d:\th\shell\osshell\control\scrnsave\default\screensavertelemetryc.c??
d:\th\windows\moderncore\inputv2\inputprocessors\devices\keyboard\lib\keyboardprocessortelemetry.c??
d:\th\windows\published\main\touchtelemetry.h
d:\th\xbox\onecore\connectedstorage\service\lib\connectedstoragetelemetryevents.cpp
d:\th\xbox\shellui\common\xbox.shell.data\telemetryutil.c??

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

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??
Думаю, на этой находке пора закругляться.

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

Чтобы разобраться вопросе, насколько может быть сложным программный код «Виндовс» мы обратились к одному из разработчиков команды Windows NT в компании Microsoft — Кену Греггу (Ken Gregg).

Кен Грегг (Ken Gregg), разработчик в составе группы Windows NT

«Могу сказать вам, что у меня был доступ к исходному коду, когда я был в команде Windows NT (NT является основой для всех настольных версий Windows начиная с XP), во время проектов разработки NT 3.1 и NT 3.5. Всё было в рамках стандартов кодирования NT Workbook — эдакой «библии» для всей проектной команды.

. Хотя я и не читал каждую строку кода, но то, с чем мне пришлось работать, было очень:

чётким,
модульным,
многоуровневым,
обслуживаемым».

Нужно исходить из того, что именно понимается под сложностью кода. Это понимание сугубо субъективное, ведь так? Благо существует множество различных метрик, используемых и комбинируемых для измерения сложности программного обеспечения в тех или иных ситуациях (та же самая модульность, многоуровневость и обслуживаемость).

Насколько сложна Windows в программном коде?

Конечно, чтобы прочитать и понять код, вам нужно было бы иметь представление об общей архитектуре Windows NT.

Вероятно, лучшим источником информации о внутренностях Windows сегодня являются книги Windows Internals 6th Edition (в двух томах).

Некоторые люди просто приравнивают сложность кода к размеру. У этого сравнения тоже есть метрика — строки кода (LOC).

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

Кен Грегг (Ken Gregg)

«Существует много споров о методах, используемых для подсчета строк кода (LOC). Если использовать одни и те же критерии от одного выпуска к следующему, то получится относительное изменение размера базы кода.

Сравнивать эти числа с цифрами другой ОС, которая использовала другой метод подсчета строк кода, всё равно что сравнивать яблоки с апельсинами. То есть это некорректный подход».

Как менялся программный код Windows?

Здесь приводятся некоторые лакомые кусочки, дающие представление о размерах современной кодовой базы Windows. Строки кода здесь являются приблизительными и неофициальными, но основаны на достаточно надёжных источниках, о которых говорит Кен Грегг .

Как база кода Windows NT развивалась с 1993 года

MLOC — это количество миллионов строк исходного кода. По ним можно определить относительную сложность операционной системы, если опираться на размеры кода (LOC-методика).

Windows NT 3.1 (1993) - 5,6 MLOC
Windows NT 3.5 (1994) - 8,4 MLOC
Windows NT 3.51 (1995) - 10,2 MLOC
Windows NT 4.0 (1996) - 16 MLOC
Windows 2000 (2000) - 29 MLOC
Windows XP (2001) - 35 MLOC
Windows Vista (2007) - 45 MLOC
Windows 7 (2009) - 42 MLOC
Windows 8 (2012) - 50 MLOC
Windows 10 (2015) - 55 MLOC

Исходный код Windows состоит в основном из C и C++, а также небольшого количества кода на ассемблере.

Некоторые из утилит пользовательского режима и другие подобные службы пишутся на Си Шарп, но это относительно небольшой процент от общей базы кода.

Кен Грегг (Ken Gregg)

«Я намеренно не включил в список 16-битные версии ОС, выпущенные с 1985 по 2000 годы. Windows NT была основой для всех современных 32-бит и 64-бит версий Windows. Количество строк кода в серверных версиях было таким же, как и в несерверных версиях, выпущенных в том же году (то есть они имели одинаковую базу исходного кода)».

Несколько слов про ядро Windows NT

По словам Кена, работа над ядром NT началась в 1988 году. Ядро было создано с нуля в качестве 32-разрядной упреждающей многозадачной ОС.

Ядро NT впервые загрузилось в июле 1989 года на процессоре Intel i860 RISC. С самого начала был сильный толчок к тому, чтобы новая ОС была совместимой с различными архитектурами центральных процессоров и не была привязана только к архитектуре Intel x86 (IA-32).

NT в конечном итоге работал на MIPS, DEC Alpha, PowerPC, Itanium и, конечно, Intel x86 и x64.

Некоторая сложность была добавлена в базу кода на уровне абстрагирования оборудования (HAL). Это было нужно для поддержки неинтеловских архитектур.

А как вы оцениваете перспективы Windows в плане кода? Узнайте, какие версии Windows актуальны сейчас и какие ОС можно рассмотреть в качестве альтернативы.

Компания ZEL-Услуги

Есть проблемы при использовании Windows и непонятен программный код для внедрения новых бизнес-инструментов в ОС от Microsoft? Проконсультируйтесь с экспертами по ИТ-аутсорсингу и получите поддержку по любым техническим вопросам и задачам.

Разные эксперты по безопасности и профильные медиа упомянули, что исходный код является легитимным. Однако, опубликованный в сети файл размером 42 гигабайта содержит исходный код не только Windows XP, но и других продуктов Microsoft, в частности Windows CE, Windows NT и Xbox. Среди прочего, в файле содержится исходники MS-DOS и конспирологические документы о причастности Билла Гейтса к различным мировым событиям.

The Windows XP SP1 source code leak looks pretty legit

Положительные и негативные эффекты подобных типов утечек

Не стоит спешить с выводами и думать, что нас вот-вот взломают, ведь у данной ситуации есть две стороны медали. С одной стороны, есть такие ресурсы, как Hacker News, которые представляют собой сообщества разработчиков, способных провести инспекцию исходного кода, улучшить свое понимание системы Microsoft и создать альтернативные версии на базе раскрытых исходников.

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

Но есть и обратная сторона медали. Данная утечка создает дополнительные риски безопасности для пользователей и организаций, продолжающих использовать Windows XP. Система до сих пор активно используется в некоторых учреждениях США, в Армии Великобритании, в некоторых больницах и банкоматах. Теперь исходный код может быть проанализирован для поиска уязвимостей и последующего проведения атак против этих целей.

Тем не менее, компании и государственные учреждения, продолжающие использовать Windows XP или Windows 7 из-за соображения совместимости со специфичным ПО, платят Microsoft за возможность получать обновления безопасности и расширенную поддержку.

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

Читайте также: