Что-то понесло меня посмотреть, как устроен формат файла с сигнатурами osinfo.dat у софт-айса. Очень хочется запустить его на XP SP3. Поиск в гугле дал сообщения, где в лучшем случае удавалось запустить его с кучей ошибок, сайс плевался, что не может найти MiCopyOnWrite и другие функции, что чревато его кривой работой. Предлагается разреверсить формат osinfo.dat и сделать сигнатуры для XP SP3. Вопрос первый - это кому-нибудь нужно? Если нет, то я не буду выкладывать наработки и буду делать для себя. Вопрос второй - можно ли этот файл чем-нибудь сгенерировать? Где-то был линк на какой-то способ, но линк мертвый. Путем продолжительного втыкания в хексдамп этого файла удалось обнаружить закономерности в размещении блоков в нем. Файл состоит из последовательных блоков, первый ворд у них содержит длину блока, второй ворд - какие-то флаги, остальные байты блока содержат полезную информацию. Дальше идет следующий блок и тп. до конца файла. Блоки бывают нескольких типов. Один из типов удалось опознать - там идет список версий ядра (major.minor, service pack, build number), имена модулей, имена функций и их сигнатуры. Немного удалось узнать и про другие типы блоков. Остальное придется доузнавать путем реверсинга самого сайса в месте, где он подгружает этот файл. Если кому интересно, могу выложить наработки.
ну конечно же выкладывай )) п.с. нагуглив однажды soft-ice cover,и был приятно удивлен что на хр3 спокойно запустился айс...
смотря какой формат на XP SP3 Софтайс запускается без каких-либо проблем, вот только в лог пишет ругательства, где-то на руборде я приводил текст из лога
конечно интересно, инфо по теме: deciphering osinfo.dat for softice http://www.woodmann.com/forum/showthread.php?t=12234
Формат файлов osinfo.dat и osinfob.dat (в чем разница между ними я не знаю - формат один и содержание похоже) следующий. Файлы разделены на блоки нескольких типов. Блок начинается с ворда, содержащего размер блока, включая заголовок, потом идет ворд неизвестных пока что флагов (я видел только значение 0001), далее идет содержимое длиной (размер_блока-4), где 4 - размер этого заголовка. После него идет следующий блок и так далее до конца файла. В начале файла располагаются блоки неизвестного назначения, в которых лежат копирайты Compuware, вероятно, они информационные и служат описателем содержимого файла. Далее идут блоки двух типов неизвестного назначения, в которых в том числе содержатся: версия Windows в формате Major.Minor, версия сервиспака, build number. Я их назвал в исходнике OS1 и OS2. Далее идут блоки с сигнатурами функций. В них так же содержатся версия Windows (Major.Minor, SP, build number), имя модуля, имя функции, сигнатура функции а так же имя экспортируемой функции, начиная с которой надо искать эту сигнатуру. (это я подтвердил по ссылке JohnFive). Эти блоки нужны для определения адресов неэкспортируемых функций. Дальше идут блоки неизвестного назначения, названные у меня коротко DATA. В общем структура блока может быть описана следующей структурой (Си): Code (Text): #pragma pack(push,1) struct OSINFOHEADER { WORD structLength; // block length, bytes WORD flags; // flags, always 0001 union { struct { char infoBlock[362]; // copyright block } info; struct { BYTE reserved1; BYTE minorKernel; // major.minor windows version BYTE majorKernel; WORD buildNumber; // build number char spNumber[4]; // asciiz string 'sp0', 'sp1', ... with service pack number WORD reserved2[7]; // [7] in OS2 or [6] in OS1 } os; struct { BYTE alwaysZero; // Always 0 BYTE minorKernel; // Версия Windows - Major.Minor BYTE majorKernel; WORD buildNumber; // Kernel build number char spNumber; // Service pack number BYTE reserved[21]; WORD reserved2; char moduleName[40]; // module name (asciiz) char routineName[60]; // internal routine name (asciiz) char routine2Name[60]; // exported routine name (asciiz) BYTE signature1[41]; // internal routine signature BYTE signature2[42]; // exported routine signature } func; struct { BYTE alwaysZero; BYTE minorKernel; BYTE majorKernel; WORD buildNumber; char spNumber; BYTE reserved[58]; } data; }; }; #pragma pack(pop) #define OSINFO_INFOBLOCK_LENGTH 366 #define OSINFO_OS1BLOCK_LENGTH 25 #define OSINFO_OS2BLOCK_LENGTH 27 #define OSINFO_FUNCBLOCK_LENGTH 276 #define OSINFO_DATABLOCK_LENGTH 68 Как видно, файл содержит блоки 5 разных типов. Назначение одного из них (FUNCBLOCK) удалось достоверно определить. Пока что эти данные получены лишь продолжительным втыканием в хексдамп osinfo.dat. Назначение блоков OS1, OS2, DATA все еще не ясно - возможно, какие-то из них содержат адреса патчей или что-то подобное. Пример программы, анализирующей osinfo.dat: (единственный аргумент командной строки - путь к osinfo.dat/osinfob.dat) Code (Text): /* * osinfo.dat/osinfob.dat parser for SoftICE * [C] Great, 2009 */ #include <windows.h> #include <stdio.h> #pragma pack(push,1) struct OSINFOHEADER { WORD structLength; WORD flags; union { struct { char infoBlock[362]; } info; struct { BYTE reserved1; BYTE minorKernel; BYTE majorKernel; WORD buildNumber; char spNumber[4]; WORD reserved2[7]; // or [6] } os; struct { BYTE alwaysZero; BYTE minorKernel; BYTE majorKernel; WORD buildNumber; char spNumber; BYTE reserved[21]; WORD reserved2; char moduleName[40]; char routineName[60]; char routine2Name[60]; BYTE signature1[41]; BYTE signature2[42]; } func; struct { BYTE alwaysZero; BYTE minorKernel; BYTE majorKernel; WORD buildNumber; char spNumber; BYTE reserved[58]; } data; }; }; #pragma pack(pop) #define OSINFO_INFOBLOCK_LENGTH 366 #define OSINFO_OS1BLOCK_LENGTH 25 #define OSINFO_OS2BLOCK_LENGTH 27 #define OSINFO_FUNCBLOCK_LENGTH 276 #define OSINFO_DATABLOCK_LENGTH 68 struct SYSTEM_SUPPORTED { WORD buildNumber; WORD SpNumber; BYTE major; BYTE minor; int refs; }; SYSTEM_SUPPORTED Systems[200]; int nSystems = 0; void AddSystem (WORD build, WORD sp, BYTE major, BYTE minor) { for (int i=0; i<200; i++) { if (Systems[i].buildNumber == build && Systems[i].SpNumber == sp && Systems[i].major == major && Systems[i].minor == minor) { Systems[i].refs++; return; } } Systems[nSystems].buildNumber = build; Systems[nSystems].SpNumber = sp; Systems[nSystems].refs = 1; Systems[nSystems].major = major; Systems[nSystems].minor = minor; nSystems++; } int main (int argc, char** argv) { printf("osinfo.dat parser for SoftICE. [C] Great, 2009\n"); if (argc != 2) return printf("use: %s path-to-osinfo.dat\n", argv[0]); char *osinfo = argv[1]; HANDLE hFile = CreateFile (osinfo, GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0); HANDLE hSection = CreateFileMapping (hFile, 0, PAGE_READONLY, 0, 0, 0); LPVOID lpMapping = MapViewOfFile (hSection, FILE_MAP_READ, 0, 0, 0); if (lpMapping == 0) return printf("failed\n"); DWORD len = GetFileSize (hFile, 0); OSINFOHEADER *rec = (OSINFOHEADER*) lpMapping; do { switch (rec->structLength) { case OSINFO_INFOBLOCK_LENGTH: printf("infoblock[%x]: %s\n", (DWORD)rec - (DWORD)lpMapping, rec->info.infoBlock); break; case OSINFO_OS1BLOCK_LENGTH: case OSINFO_OS2BLOCK_LENGTH: AddSystem (rec->os.buildNumber, rec->os.spNumber[2]-'0', rec->os.majorKernel, rec->os.minorKernel); break; case OSINFO_FUNCBLOCK_LENGTH: //if (!stricmp (rec->func.routineName, "MiCopyOnWrite") || !stricmp (rec->func.routine2Name, "MiCopyOnWrite")) printf("modblock[%x]: kernel %d.%d SP%c build %d reserved2 %d (%x) module %s functions %s %s [%02x %02x]\n", (DWORD)rec - (DWORD)lpMapping, rec->func.majorKernel, rec->func.minorKernel, rec->func.spNumber, rec->func.buildNumber, rec->func.reserved2, rec->func.reserved2, rec->func.moduleName, rec->func.routineName, rec->func.routine2Name, rec->func.signature1[0], rec->func.signature2[0]); break; case OSINFO_DATABLOCK_LENGTH: printf("data[%x]: kernel %d.%d SP%c build %d\n", (DWORD)rec - (DWORD)lpMapping, rec->data.majorKernel, rec->data.minorKernel, rec->data.spNumber, rec->data.buildNumber); break; default: printf("unknown[%x]: length %d\n", (DWORD)rec - (DWORD)lpMapping, rec->structLength); } *(DWORD*)&rec += rec->structLength; } while ((DWORD)rec - (DWORD)lpMapping < len); for (int i=0; i<nSystems; i++) { printf("System[%-4d] %d.%d build %d (%04x) sp%d %d signatures\n", i, Systems[i].major, Systems[i].minor, Systems[i].buildNumber, Systems[i].buildNumber, Systems[i].SpNumber, Systems[i].refs); } return 0; } Её вывод наглядно показывает содержимое этого файла. Reversing in progress... PS. Обращаю внимание на то, что некоторые Osinfo.dat содержат сигнатуры для ядра 6.0 билды 40xx - это виста, когда она еще была бетой и звалась longhorn! =)
простите за глупый вопрос - а поотлаживать сам айс можно ??? если на виртуалку поставить 2ksp4 bkb xp2 c рабочим айсом это чтонибудь даст ???
Проще запихнуть ntice.sys в IDA и реверсить момент, где оно грузит osinfo.dat, чем я в принципе щас и занимаюсь
в нете еще валяется такая штука "ntice.rar - декомпилированый mamaich'em SoftIce для NT 4.0.5 (Build 526). Большая часть адресов и имен функций взята из сырцов IceDump"
Great "Вопрос первый - это кому-нибудь нужно? Если нет, то я не буду выкладывать наработки и буду делать для себя." Безусловно нужно . Наконец-то хоть кто-то ( а тем более сам Great ) взялся за это !
Мне кажется, максимум чего можно добиться через osinfo.dat - запустить SICE на новых сервиспаках XP/2k3. Под Vista/7 он таким макаром почти наверняка не заработает - разве что серьёзно хачить под него саму винду.
Вроде бы это из-за новой модели видеодрайверов, да и самих карточек тоже, не? Этот момент уже как-то обсуждался, надо поискать просто.
Давным-давно Крис в своем старом блоге писал что занимается портированием софт-айса под висту: http://souriz.wordpress.com/2008/05/09/bug-in-olly-windows-behavior-and-peter-ferrie/ Может у него что-то получилось с тех пор.
x64 Нет. AFAIK, основная причина отказа Compuware oт SICE - тенденция развития ядра виндовс (PatchGuard и проч), сильно повышающая сложность разработки и требующая изменения настроек винды под себя в объёме, неприемлемом для такого продукта. С другой стороны сыграло роль значительно возросшие стабильность и возможности MS DbgTools. SICE вполне юзабелен и без видео, в 2-х комповой конфигурации. Я его, кстати, под ВМваре только так и пользовал. В ряде задач он показал себя намного лучше WinDBG в плане производительности (например, если нужны условные бряки в "горячих" точках) из-за того, что обработка бряков производится на отлаживаемом компе, а не гоняется по медленному COMу.
