винты отдыхают: бездисковая загрузка Windows

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

Эта мания не обошла и меня - но на этот раз, в отличие от прошлых затей, я грузил через сеть самую что ни на есть Windows 2000.
Первое и главное, с чем меня срочно нужно поздравить, это то, что все работает - и работает вполне прилично. Как говорится, не прошло и двух недель ковыряния в "железе" и документации. Фактически я прямо сейчас работаю на бездисковой станции, так что результат у меня прямо перед носом.
А теперь расскажу, как можно повторить всю эту историю, обходя ошибки и продвигаясь прямо к цели. Попутно разучим испанские цифры до восьми включительно :-).

uno: выбираем железо

Первое, что вам понадобится для бездисковой загрузки, это два компьютера (и оба - с хорошими винчестерами :-)) Вы, конечно, в шоке: ведь как раз на винте вы и хотели сэкономить - но в свое время все станет ясно. Лучше всего, если эти компы будут, что называется, "нулевыми", то есть без всяких установленных осей - в противном случае ничего гарантировать не могу (я пытался устанавливать на всяких зверинцах - и безрезультатно проколбасился лишних три дня).
Один комп будет выполнять роль сервера. Я использую не самый мощный компьютер, который, тем не менее, справляется с поставленной задачей: Duron 800, 128 Мб памяти, интегрированная материнская плата (KLE133, видео - Trident Blade 3D Promedia, LAN - ADMTek 983 10/100 Мбит). Этот сервер не имеет ни монитора, ни клавиатуры, ни мышки - точнее, они отваливаются сразу после загрузки. Управление производится удаленно через Windows Remote Desktop.
Вообще говоря, BXP-сервер не является единым целым - на нем работает, как минимум, четыре компонента: сервер DHCP, сервер TFTP, сервер аутентификации и сервер виртуальных дисков. Из всех только последний предъявляет требования к мощности компьютера, выступая в роли своего рода специфического файлового сервера. Как известно, для файловых серверов критичным является объем оперативной памяти - так что это первое, что вам придется добавить, если производительность сервера вас не устраивает. Повышению производительности клиентских машин также будет способствовать более быстрая сеть: при возможности используйте гигабитную шину. И третья возможность - это разделение сегментов сети и установка дополнительных серверов виртуальных дисков, но об этом чуть позже.
В качестве эталонной рабочей станции выступает Athlon 1700 с 1G памяти и 60 Гб винчестером, для игрищ снабженный самым распространенным GeForce 4 MX 400 с 32 Мб видеопамяти. Хочется сказать, что столько оперативной памяти вовсе не обязательно, но, поскольку загрузочный диск и swap-файл будут работать по сети, то с целью минимизации этого трафика нужно ставить 256 Мб для Windows 2000 - и никак не меньше.
Третье устройство, также задействованное в нашей схеме - это собственный коммутатор. Это важно, поскольку общественный использовать для загрузки не очень выгодно: загрузка операционки и программ станет заметно замедляться. Теоретически коммутатор должен гибко коммутировать часто соединяющиеся порты - так что "висящие" параллельно, но не участвующие в процессе компьютеры не должны бы оказывать влияния на пропускную способность. Однако на практике приходилось констатировать значительную выгоду по времени на выделенном коммутаторе - видимо, не вся теория доходит до практики :-).
Я использовал неброский, но надежный EUSSO Nway switch USH-5008 XL. У этого восьмипортового юнита несколько преимуществ: питание 12 В, что заметно и положительно влияет на "залипание" сети по сравнению с распространенными семивольтовыми моделями. Второе - это автокросс на всех портах (то есть вы можете подключать как компьютеры, так и маршрутизаторы/коммутаторы на любой порт любым кабелем - коммутатор сам распознает, кто куда подключен, и сделает все правильно).
Отдельное внимание стоит уделить сетевой карточке на машине-клиенте. Она должна поддерживать сетевую загрузку, так называемый PXE (по аналогии со SCSI=ska-zee и SQL=seek-well, PXE читается pig-zee). Этот стандарт поддерживают сейчас все карточки, в том числе и встроенные на борту материнских плат. Я использовал недорогую и надежную Realtek RTL8139(A), которая штатно поддерживается большинством операционных систем.
Итак, все было подключено и работало без проблем (в том смысле, что дым ниоткуда не шел) - пришла очередь выбора операционных систем.

dos: выбираем операционки

Для сервера (пока) подходят только операционные системы семейства Windows, поскольку только на этой платформе работает BXP (а именно эта программа и делает бездисковую загрузку Windows возможной).
Для установки на сервер была выбрана Windows XP Professionl SP1. Для этого было три причины: во-первых, XP имеет все драйверы для указанной материнской платы, что, в общем, многое упрощает и целый ряд телодвижений делает ненужными. Во-вторых, XP очень хорошо перезагружается (в отличие от той же Windows 2000, с которой у меня было немало случаев "сейчас, сейчас я перезагружусь - ты только жди"). Это было важно, поскольку хотелось иметь возможность перезагружать сервер удаленно - или, по крайней мере, без подключения монитора и клавиатуры.
Третье - и, собственно, самое главное - это Remote Desktop, то есть возможность удаленно подключаться и получать графический "shell" на удаленной машине. Если сервер всегда будет у вас под рукой и не составит труда поставить на него монитор /* или вспомнить про существование терминальных сервисов или RAdmin, черт возьми ! :) – прим. ред. */ - тогда, возможно, вы предпочтете поставить Windows 2000 и сэкономить таким образом мощность для более высокой производительности сервисов.
Естественно, всякие 98 или Me были отброшены без всяких раздумий, поскольку ни надежность, ни управление ресурсами, в том числе сетевыми соединениями и дисковой файловой системой, не находятся у этих систем на уровне, достаточном для решения поставленных задач.
Для эталонного клиента я выбрал Windows 2000 Professional. Собственно, было три варианта: помимо упомянутой Windows 2000, претендовали Windows XP и Windows Embedded. Первая отпала сама собой: во-первых, она потребляет в несколько раз больше ресурсов (что в масштабах целой сети умножается пропорционально количеству рабочих станций); во-вторых, ее образ в несколько раз объемней (то есть сама загрузка длится заметно дольше); и третье - я просто потерпел фиаско при запуске этой ОС, то есть при попытках загрузить образ XP система вылетала - да еще и с рядом неприятных сообщений, намекающих на скромность моих умственных способностей.
Windows XP Embedded - во всем неплохая система, я экспериментировал с ней вполне успешно, но к ее "отставке" привели следующие три причины. Во- первых, ее генерация сама по себе - процесс трудоемкий. Так что решать проблемы сетевой загрузки и одновременно конфигурировать XPE - это несколько утомительно. Во-вторых, для работы XPE требуется инсталляция на клиентской стороне дополнительных компонент и их конфигурация, что еще более отдаляет ожидаемый результат. И в-третьих, это все-таки XP - то есть даже в урезанном варианте она может потребовать больше ресурсов, чем Windows 2000 (а уж тем более если вы захотите встроить туда такие возможности, как Internet Explorer и DOT NET).
Дополнительная просьба: по возможности инсталлируйте клиентскую часть на чистый диск. Создайте один раздел размером до 8000 Гб. Желательно даже меньше, поскольку таков будет размер образа вашего диска на сервере и, соответственно, расход места на нем - если вы примете решение сделать виртуальные диски полноценными с внесением изменений в сам образ, то количество образов будет пропорционально количеству рабочих станций.
Очень важно: проследите, чтобы имя эталонного диска было С:. Это жесткое требование BXP - в случае, если у вас на диске уже стоит какая-нибудь Windows NT, она будет тянуть за собой мэппинг, так что следующая установка получит имя D: и так далее. Даже если вы и исподвывернетесь и, используя, к примеру, Partition Magic, перемэппите имена устройств (а это еще нужно придумать как) - то и в таком случае вы должны будете гарантировать, что старая инсталляция не получает управления.
Плохая новость заключается в том, что, как по ходу выяснилось, NT5 держит только одну копию ntldr на одном физическом диске, так что все последующие инсталляции не будут устанавливать этот компонент. Короче, я вам точно говорю: ставьте клиент на чистый винчестер в первый раздел с именем C: - и все будет работать как надо.
Также инсталлируйте на рабочую станцию все драйверы и прочие компоненты, вроде DOT NET, Media Player, Direct X и так далее: хоть это можно сделать и позже, но перед созданием загрузочного образа нелишне иметь хорошее представление о его размере. Кроме того, я наблюдал проблемы с установкой некоторых компонент на виртуальный диск: например, драйвер звуковой карточки на борту и Norton Ghost, установленные на образ, не работали - но после их установки на эталонный диск и создания нового образа все стало на свои места.
Вообще же, если вы настроены реально эксплуатировать BXP, эталонный диск для вас должен стать предметом особой заботы: придется аккуратно спланировать, что нужно обязательно туда установить, а что можно загружать и по сети (игры, например). Это важно, поскольку: размер эталонного диска ограничен - это раз, все ваши ошибки будут реплицироваться пропорционально количеству рабочих станций - это два.

tres: загружаем и устанавливаем BXP

Собственно, этот шаг можно было проделать и самым первым.
BXP - это набор серверов, в своей совокупности обеспечивающих сетевую загрузку. Загрузить программу можно с сайта Venturcom, есть и другие возможности получения данной инсталляции - этот продукт распространяет еще несколько компаний. Главное, что вас должен интересовать файл с именем bxp25.exe размером 12,6 Мб.
Этот файл содержит четыре варианта инсталляции, но нас пока что будут интересовать только два из них: инсталляция сервера и инсталляция клиента. Два других варианта - это установка самостоятельного файлового сервера и установка Embedded Tools (после основной установки вы поймете, зачем они могут быть нужны, но сейчас мы не станем их рассматривать).
Будем считать, что серверная часть BXP без проблем установлена на сервер. Но это еще не значит, что тот начал работать - на самом деле вам придется стартовать все сервисы вручную чуть позже, когда вы их сконфигурируете.
Важно! Хоть инсталляция и не настаивает на этом явно (как это делает, например, DirectX: "оба-на! перезагрузочка", хех) - тем не менее, обязательно перезагрузите компьютер, иначе ничего не станет работать.
Кроме прочего, не забудьте установить, как минимум, триальную лицензию. Это интерактивный процесс: вы отправляете письмо на Venturcom - и в ответ получаете от LicenseRobot@vci.com файл лицензии LicenseResponse.vlf. После установки BXP у вас появится новое устройство с именем "лицензии" и красивой красной пиктограммкой в виде щита: щелкните на ней правой кнопкой, выберите Import License и укажите на полученный от Venturcom файл. Должно сработать - на "диске" лицензий появится "каталог" с данными, соответствующими вашей лицензии.

quatro: настраиваем DHCP-сервер

В набор компонент, устанавливаемых с BXP-сервером, входит DHCP-сервер - однако я его не использовал, поскольку уже располагал установленным Turbo DHCP. Кроме того, встроенный в BXP Tellurian DHCP не умеет взаимодействовать с другими серверами DHCP в одной подсети - а это как раз был мой случай. И, наконец, Tellurian настраивается через файл конфигурации, с обязательным рестартом сервиса после внесения в него изменений, - что не столько страшно, сколько утомительно. Короче: входящий в состав BXP сервер меня не устраивал и, как показало время, оказался совсем не нужным.
Вообще, правильная настройка DHCP - это самая важная часть процесса сетевой загрузки в целом. Так что первое, чего вы должны добиться, это настроить DHCP и загрузить дискового клиента с динамической конфигурацией от этого сервера. На этом этапе в BIOS'е вашего компьютера первым пунктом должна стоять загрузка с диска - для сетевой загрузки еще не пришло время.
Вот список опций, которые установлены на моем Turbo DHCP, помимо диапазона адресов и подсети:

Опции, кроме -1 и -14, не имеют к сетевой загрузке прямого отношения; и, конечно же, все адреса должны быть заменены на специфические для вашей подсети. Next server должен указывать на ваш сервер, где установлен BXP и с которого будет загружаться образ VLDRMI13.bin. Настройка NBT-сервера для Windows обозначает настройки WINS. Если вы не уверены в том, как правильно настроить DHCP (чтобы не было конфликтов адресации между серверами и подобных накладок) - лучше обратитесь к системному администратору. Turbo DHCP совершенно бесплатно можно закачать с сайта.
В данной точке будем считать, что ваша рабочая станция успешно загружается, получая параметры от вашего же DHCP-сервера. Важный момент.

cinco: настраиваем TFTP и другие сервисы BXP

После установки сервер BXP не начинает работу автоматически: вы должны сконфигурировать все сервисы и запустить их вручную. "Запустить вручную" значит зайти в Панель управления > Административные задачи > Сервисы и выполнить две операции: сначала правой кнопкой выбрать на нужном сервисе «Стартовать», затем (все той же правой кнопкой) выбрать свойства и далее «Тип запуска: автоматически» - чтобы этот сервис стартовал при перезагрузке компьютера. Надеюсь, эта операция вам знакома и трудностей не доставит. А для тех, кто в танке, еще раз повторю: все происходит на вашем сервере.
Итак, поехали-покатились по настройкам компонент BXP. Первым настроим TFTP, то есть сервер, раздающий вашему клиенту файл начальной загрузки. Настройка производится через Control Panel - там вы должны найти пиктограму Venturcom TFTP Service. По умолчанию он не подключен ни к какому порту и не настроен ни на какой каталог. Исправляем эту ситуацию, настроив параметры следующим образом:
- TFTP Options: Allow Transmit - да, Allow Receive - нет;
- Transmit (GET) Directory -C:\Program Files\Venturcom\BXP\TFTPBOOT\;
- TFTP Logging - без разницы, поставьте в ноль;
- TFTP Network - отметьте все сетевые интерфейсы, на которых TFTP будет ожидать подключений бездисковых клиентов, и не меняйте ни в коем случае порт 69, он жестко закодирован в PXE BOOT BIOS;
- About - хех, ну почитайте, что ли :-).
Альтернативно можно настроить сервис 3COM PXE. Укажите файл загрузки C:\Program Files\Venturcom\BXP\TFTPBOOT\BOOTPTAB, отключите Proxy DHCP, если сервер DHCP расположен на том же компьютере и остальные параметры можно не изменять.
Третий способ получения загрузочного образа - BOOTP - является устаревшим, так что не используйте его без крайней необходимости.
Еще два сервиса нужно настроить обязательно.
BXP Login Service Preferences -ярлык на него расположен в папке установленной программы BXP. Все, что тут нужно сделать - это отметить интерфейс, на котором данный сервис будет принимать запросы на аутентификацию. Сама база, как вы видите, это файл в формате MS Access (или, точнее, MS DBJet 3.0), на досуге можете поковырять его вьювером. Если вы хотите принимать запросы от анонимных хостов (что, в общем, может сэкономить много времени и вполне безопасно в закрытой среде), отметьте Add New Clients To Database.
BXP IO Service Preferences.Также разрешите ему "слушать" на одном или нескольких интерфейсах и, если есть желание, измените местоположение виртуальных дисков. Естественно, что указанный физический диск должен иметь достаточный запас емкости.
Теперь, когда все настроено как следует, можно запускать сервисы. Делается это, как уже было сказано, руками, через «Сервисы» - искомые сервисы BXP имеют имена, начинающиеся с "BXP" и (если вы используете PXE или BOOTP) "3Com". Всего их должно насчитываться пять-шесть штук - в зависимости от того, используете ли вы собственный TFTP-сервер. Запустите их и не забудьте отметить тип запуска «Автоматический».
После запуска сервисов зайдите BXP Administrator - и в Tools-Configure Bootstrap выберите параметры:
- путь должен указывать на C:\Program Files\Venturcom\BXP\TFTPBOOT\VLDRMI13.bin;
- адреса - получаемые по DHCP, адреса из базы данных, Verbose Mode - Да.
После нажатия на OK программа физически пропатчит ваш загрузочный образ (это напоминает мне конфигурацию очень прикольного трояна thing) - и таким образом клиент будет работать с указанными вами опциями.
Теперь в вашем распоряжении - полноценный сервер сетевой загрузки. Осталось создать загрузочный образ операционной системы - и все готово.

seis: создаем загрузочный образ

Загрузочный образ ОС - это, фактически, содержимое вашего загрузочного раздела, но перенесенное на виртуальный диск. Кроме того, вашу Windows 2000 следует пропатчить патчем BXP Client, который добавляет драйвер сетевого "винчестера".
Итак, для начала на серверной машине создайте с помощью BXP Administrator виртуальный диск. Вообще, все остальное будет происходить, в основном, в этой программе. Выберите I/O-сервер, щелкните на нем правой кнопкой и выберите «Создать виртуальный диск». Теперь его нужно отформатировать.
Делается это следующим образом. Сначала примонтируйте новый диск (самый простой способ сделать это - выбрать диск и нажать <Ctrl+M>). Теперь этот виртуальный диск примонтирован в виртуальный драйв, который, как вы, вероятно, уже заметили, появился у вас на сервере (помимо диска с лицензиями). Учтите, что "мэппинг" работает только при запущенном BXP Administrator. Теперь отформатируйте этот диск самым обычным для Windows способом и отмонтируйте его обратно. Теперь диск готов для записи образа.
Следующий шаг потребует внимательности. Создайте нового клиента на сервере - можете указать для него фиксированный MAC-адрес (в качестве "волшебных пирожков" прокатывают вопросительные знаки), если хотите ограничить загрузку только определенными рабочими станциями. Теперь самый интересный момент: укажите в настройках тип загрузки «С жесткого диска». Не спрашивайте зачем - так нужно. Перезагрузите клиентскую машину, войдите в BIOS и первым номером поставьте загрузку по сети. Теперь с перезагрузки вы должны увидеть опрос DHCP и получение "пяти точек". На самом деле каждая точка отвечает за получение определенной опции настройки (это как слэш-роторы и дот-тикеры при загрузке Unix'ов - вроде фигня, но kernel-хацкеры в курсе каждого оборота) - как выяснилось из исходного кода PXE BIOS. Если у вас проблема с настройками DHCP, не найден I/O-сервер, на сервере не найден загрузочный файл или возникла еще какая проблема - вы получите об этом сообщение.
После загрузки образа с сервера BXP продолжит загрузку с локального жесткого диска - и это то, что нам пока нужно. После загрузки таким прихотливым способом (и только так!) установите из инсталляции BXP клиентскую часть (а иначе вы ее и не установите). Это, фактически, два компонента: драйвер виртуального диска и маленькая программка, которая копирует ваш диск C: (только С - это жестко закодировано и никак не меняется) на виртуальный диск на сервере. Если инсталляция прошла успешно, вы увидите новый виртуальный диск - это ваш образ на сервере, запускайте создатель образа (поищите его в «Программах») и в качестве цели копирования укажите этот диск. Тэкс-фэкс-пэкс! - и через пару минут вы будете как никогда близки к счастью.
Теперь снова переходите на сервер и измените тип загрузки клиента на «С виртуального диска». Вам откроется три опции: "с первого диска", "с первого свободного" и "показать дисковое меню" для выбора клиентом одного из нескольких образов. Что касается выбора диска клиентом, то тут я не придумал ничего умного - но, поскольку размер виртуальных дисков ограничен, то, возможно, действительно имеет смысл сделать, например, один диск для работы, а второй для игр. Загрузка же "первого попавшегося" имеет смысл только в случае, если все рабочие станции одинаковы, так что каждая станция может загружаться с любого образа - и то очень вероятно, что пользователь пожелает как-то персонифицировать свой образ и в таком случае захочет пользоваться только одним диском. Короче - загрузка с первого диска является самым простым и логичным выбором.
Дополнительно по отношению к образам дисков есть несколько стратегий использования, настраиваемых в BXP Configuration. Для настройки использования виртуального диска этот диск должен быть отключен от всех клиентов (даже от тех, что загружаются с винчестера - они ведь тоже лочат виртуальный диск, только что не первым номером). Итак, вы можете создать для диска write-кэш, причем как в памяти клиентского компьютера, так и на диске сервера. На самом деле кэш является еще и оверлейной областью - то есть, когда вы будете записывать на виртуальный диск, запись будет производиться не в образ, а в оверлей. Естественно, что оверлей в памяти будет куда быстрее, но так же понятно, что он не сохраняет своего состояния. Это полезно, когда вы настраиваете, например, компьютерный класс и в ваши планы не входит переустанавливать систему после нашествия каждой следующей орды обезбашенных хакеров.
Кроме прочего, дисковый кэш (в оперативной памяти клиента тоже - но это очевидно) персонифицирован - то есть сколько пользователей, столько и кэшей. Чего это дает? Получается, что сотня пользователей может "прикуривать" от одного загрузочного образа, но при этом каждый может вносить в систему изменения, и BXP будет хранить их в компактном виде персональной "дельты". Конечно, такая конфигурация будет сильно нагружать сеть, и есть свидетельства, что процессор сервера тоже будет очень греться, так что за экономию дисковой памяти сервера придется платить его повышенной мощностью и гигабитной сетью - иначе работа будет медленной.
Внимание: для того чтобы изменять режим использования образа, нужно не просто "положить" всех подключаемых клиентов, но и "выкатить" виртуальные диски, то есть зайти в настройки каждого клиента и исключить нужный образ как вариант загрузки. Кроме того, не делайте образ диска, если у вас включен кэш - вся запись пойдет именно туда, кэш разбухнет (а в случае кэша в оперативке - так и вообще забьется). Это неправильно.

siette: запускаем змея в космос

Собственно, это самая короткая и простая часть дела: если вы все сделали правильно, то просто перезагрузите клиентскую машину и убедитесь, что все пучком. Получилось? Тогда можете щемиться закупать остальные бездисковые компы, экономя на каждом по приблизительно 30 американских рублей - но самая главная экономия будет, конечно, на вашей работе по настройке одного компа вместо кучи.

ocho: мы строили, строили и наконец построили

Собственно, все, только что рассказанное - это так себе, предисловие фактически. То есть вы, конечно, можете настроить систему и при определенном везении даже продлить ее trial'ный период на следующую пятилетку. Но это все, так сказать, цветочки для сисадминов, которые, как известно, хоть и super, но все-таки юзеры.
Однако хотелось бы не тырить софт Venturcom ценой 1500 зеленых, а честно его порвать и реконструировать. Поэтому любой нормальный хацкер должен срочно закатать все, чего там у него закатывается, и наваять OpenBXP, работающий под Linux и другими системами. В целях портабельности я бы выбрал Java или Perl - заодно получится компактный и структурированный исходный код.
Несколько наводящих подсказок. Первое, что мы уже и сделали, это использовали альтернативный сервер DHCP, то есть эта компонента у нас уже Open. Точно так же и TFTP- и PXE-серверы являются чем-то совершенно от BXP не зависимым. Учитывая, что и PXE, и BOOTP представлены хоть и бесплатными, но все-таки принадлежащими 3Com, серверами, я рекомендовал бы просто игнорировать эти варианты загрузки (хотя бы временно, до лучших времен). Кстати, если вы настроили DHCP так, как показано в этой статье, то вам эти сервисы, что называется, однозначно не упираются - я их даже не стартовал.
В качестве шага к светлому будущему я предпринял установку бесплатного Solar Windows TFTP Server v.6.0, переписал в его каталог C:\TFTP-Root файл VLDRMI13.bin, после чего спокойно положил сервис BXP TFTP - и все продолжало работать как ни в чем не бывало (ну, за исключением лагов "TFTP Timeout", которые фиксировал Solar TFTP - но загрузке это не мешало, да и кто знает, как там работал BXP TFTP, я в его логи не вдавался).
Итак, осталось четыре сервиса, которые воленс-ноленс придется реконструировать, поскольку падение любого из них мгновенно делает сетевую загрузку невозможной. Исследование закладки General дает нам следующие соответствия имен файлов (в каталоге C:\Program Files\Venturcom\BXP\) и сервисов:

Кроме того, придется разобраться с клиентскими модулями: модулем BNClient размером 24 Кб, драйвером BXP Miniport SCSI Virtual Adapter (копии всех используемых файлов лежат в C:\WINNT\System32\BNTemp, 107 Кб) и самым ужасным файлом - VLDRMI.bin.
Ужасен этот файл не столько своим небольшим размером (всего 22 Кб, половина из которых - диагностические сообщения, однородные массивы и сообщения об ошибках), сколько полным отсутствием знакомых ориентиров вроде системных вызовов, поскольку на момент загрузки он работает в среде PXE bre-boot-OS, где, естественно, доступны какие-то системные вызовы, например BIOS, в том числе сетевые PXE, но как это работает придется изучать с нуля. Для дизассемблирования помогут такие подсказки:
- сначала сверните строки в конце текста и однородные массивы по всему тексту - из-за неизвестной точки входа это не делается автоматически;
- данные процедуры по соглашению кодеров vldrmi находятся за телом этой же процедуры, и, поскольку все происходит в одном сегменте, адресация таких "локальных переменных" часто осуществляется через CS;
- выравнивание кода - по границам двойных слов, так что пару нулей часто означает границы процедур;
- типичный пролог процедур: 66h, 60h, 6h, 1Eh - что в терминах ассемблера выглядит как:

pushad
push es
push ds

- или что-то в этом роде, после нескольких удачных попаданий остальные процедуры найдутся сами.
Есть еще небольшая наводка по поводу "где лежат параметры, которые изменяются в процессе настройки". Есть такая простая утилита fc (типа File Compare) - сделав копию с образа и изменяя параметры, можно обнаружить следующее (флажки 57C8-57C9 - последние байты в файле):

На момент публикации статьи я уже продвинулся дальше, но сегодня моя цель - не выкладывать вам код, который даже и дезассемблировать-то нельзя (а fc - не дезассемблер, так что не придеретесь), а просто показать, что все делается, и сравнительно быстро. Задача предстоит сравнительно сложная, но детерминированно разрешимая.
Решив ее, вы немедленно станете героем дня, многие конторы мира начнут вас хотеть, а вы сами сможете создать вокруг себя движение - в общем, варианты на выбор. А остальные пусть очередной раз переписывают свое резюме, каждому, как говорится, свое.

Чеботарёв Арсений,ac@comizdat.com.
Впервые опубликовано в журнале "Компьтеры+Программы".