Дело в следующем. После долгих сомнений решил я попытаться портабелизировать мелкомягкй офис без Thinstall'а, а заодно и урезать насколько возможно. Начал с Word'а. Со срачей в реестр справился, но возникла (кто бы мог подумать) проблема. Word стартует, но появляется диалог с сообщением, что "Microsoft Office Word has not been installed for the current user. Please run setup to install the application.", после нажатия "Ok" на котором приложение закрывается. С помощью одной утилитки определил класс этого окошка, который оказался 0x8002 (стандартный диалог), но удивлению моему не было предела, когда я поставил в "ольке" бряки на "CreateWindowExA/W", и выяснилось, что окно такого класса не создаётся… В общем, если кто помнит дела давно минувших дней (офис 2003), подскажите, куда копать.

| Сообщение посчитали полезным:

поискать строку и посмотреть ссылки на неё?

| Сообщение посчитали полезным:

>> поискать строку и посмотреть ссылки на неё?

Если вы про заголовок, то я его нашёл, как и текст сообщения, но соль в том, что строка присваивается посредством SetWindowTextW, окно же создаётся раньше где-то в другом месте. А когда я по <Ctrl+F9> пытаюсь выйти в предыдущую функцию, вываливаюсь в код системных библиотек и в конце концов дохожу до появления этого диалога без возврата в MSO.dll.

| Сообщение посчитали полезным:

FalseMaster пишет:
CreateWindowExA/W

А если начать с RegisterClass(Ex) ?

| Сообщение посчитали полезным:

>> А если начать с RegisterClass(Ex) ?

И что это даст?

| Сообщение посчитали полезным:

Rainbow пишет:
А если начать с RegisterClass(Ex) ?
afaik свои окна система сразу через syscall создаёт, не поймаешь

Предположение - сообщение это не мессаджбокс а диалог, а SetWindowText вызывается во время обработки WM_INITDIALOG, попробуй поймать user32.DialogBoxIndirectParamAorW или что-то подобное.

А вообще, подход считаю неверным. У офиса ведь куча разной фигни распихана по папкам. К примеру
%COMMONPROGRAMFILES%\Microsoft Shared и %APPDATA%\Microsoft, и для каждого компонента в реестре прописаны пути. Лучше бы взять ProcMon да посмотреть на чём эта длл обламывается, а не просто патчить всё без оглядки.

| Сообщение посчитали полезным:

-=AkaBOSS=- пишет:
А вообще, подход считаю неверным

да можно начать с самого начала: хардкод вместо промышленного решения (thinstall) имеет смысл для самообразования. В этом случае нужно рыть самостоятельно, а не искать солюшен.

| Сообщение посчитали полезным:

-=AkaBOSS=- пишет:

>> Предположение - сообщение это не мессаджбокс а диалог

Диалог и есть. Знаю точно, т.к. на нём контрол офисовый.

>> а SetWindowText вызывается во время обработки WM_INITDIALOG

У меня тоже такая мысля была (и есть), но что делать-то в таком случае? Ведь из колбека этого диалога мне никак не выйти на инструкцию, следующую за вызовом создающей его функции.

>> попробуй поймать user32.DialogBoxIndirectParamAorW

Так я это первым делом и пробовал вместе с MessageBox(ExA/W). DialogBoxIndirectParamAorW вызывается только один раз при создании главного окна Word'a. Откуда берётся мессаговый диалог, ума не приложу, мистика какая-то.

>> У офиса ведь куча разной фигни распихана по папкам.

Перед тем как приступить к основному действу, я расковырял рабочую Thinstall-сборку и воссоздал всю файловую и реестровую структуру офиса – результат был в точности такой же как сейчас.

>> Лучше бы взять ProcMon да посмотреть на чём эта длл обламывается

Я привык по отдельности FileMon и RegMon юзать. Так вот, первый вообще не обламывается, второй конечно выдаёт множество NOT FOUND'ов, но большей части ненайденных ключей нет и в виртуальном реестре Thinstall'а, а те что есть, я загонял из reg-файла перед стартом офиса – никакого влияния их наличие не оказывало. Так что остаётся только патчить со всей жестокостью… знать бы только где.

Gideon Vi пишет:

>> …нужно рыть самостоятельно, а не искать солюшен.

Да мне и самому стрёмно "клянчить", просто рою уже который день, а толку ноль.

| Сообщение посчитали полезным:

FalseMaster пишет:
Перед тем как приступить к основному действу, я расковырял рабочую Thinstall-сборку и воссоздал всю файловую и реестровую структуру офиса – результат был в точности такой же как сейчас.
Файловая и реестровая структура, ладно. А переменные окружения процесса?

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

| Сообщение посчитали полезным:

FalseMaster пишет:
И что это даст?

Как известно любое окно имеет свой класс и регается он в системе, как правило, при помощи этой функи. У WNDCLASSEX есть замечательное поле - WNDPROC lpfnWndProc. Выдираем для конкретного окна в нужный момент и смотрим обработчики сообщений оконной процедуры, в т.ч. WM_INITDIALOG. Оно ?

| Сообщение посчитали полезным:

Rainbow, а попробуй сам вызвать тот же мессаджбокс и отследить регу его класса

| Сообщение посчитали полезным:

-=AkaBOSS=- пишет:
а попробуй сам вызвать тот же мессаджбокс и отследить регу его класса
Он появляется изниоткуда? o.O ..Демоны !!!

| Сообщение посчитали полезным:

-=AkaBOSS=- пишет:

>> А переменные окружения процесса?

Об этом я как-то не подумал. Дебаггер показал, что читаются две (отсутствующие): "_CLUSTER_NETWORK_NAME_" и "msooaopt". Первая, судя по названию, погоды не делает, а вот вторая – вполне возможно, только мне от этого не легче, значения-то я не знаю.

>> …и делаем поиск референсов к начальному адресу колбэка

Только его для начала надо каким-то образом определить.

Rainbow пишет:

>> Как известно любое окно имеет свой класс

А вот с названием класса я дал маху. С чего-то мне втемяшилось, что значение #32770, выданное утилитой, надо переводить в число, а ведь WNDCLASS(EX).lpszClassName можно присвоить его и в виде строки. Забрезжила надежда, но увы, хоть я и нашёл место, где идёт обращение к упомянутой строке, перехода на этот код не происходит… но, сцуко, как-то же оно работает, не верю я в чудеса (но такими темпами скоро поверю).

>> Он появляется изниоткуда? o.O ..Демоны !!!

Демоны живут в линуксах, а встроенные классы винды создаются ещё на этапе загрузки системы.

| Сообщение посчитали полезным:

FalseMaster пишет:
бряки на "CreateWindowExA/W", и выяснилось, что окно такого класса не создаётся
Попробуйте просто поставть на секцию кода user32.dll бряк.
Выложите собственно саму MSO.dll

| Сообщение посчитали полезным:

>> Попробуйте просто поставть на секцию кода user32.dll бряк.

И? К этой библе 100500 обращений в секунду.

>> Выложите собственно саму MSO.dll

Я отсюда брал (та что для Office 2003).

| Сообщение посчитали полезным:

Ну всё оказалось как и предполагалось ранее
30F45991 - обработка WM_INITDIALOG
30F46A54 - собственно сам DialogProc
Референсы ведут в офигенно большую процедуру 30F45DF8
Поднимаясь выше по вызовам, выходим на развилку - 30F4673E. Дальше надо отладчиком мониторить, откуда её зовут.

| Сообщение посчитали полезным: FalseMaster

От треклятого диалога я таки избавился (благодаря подсказке AkaBOSS'а), и Word отрабатывает до конца. Я уж было обрадовался в предвкушении победы, но не тут-то было – практика показала, что номер проходит только под отладчиком, и не просто под отладчиком, а патчи (2 шт.) приходится вводить последовательно по HBP, если же вписать оба патча на первом бряке, в ходе дальнейшего выполнения происходит выброс на какой-нибудь левый адрес. Более того, установка INT3-бряка в любом месте кодовой секции MSO.dll приводит к тому же эффекту. Похоже, что в отдельном потоке периодически проверяется целостность кода. Обнаружилась очень подозрительная процедура по адресу 315FD360, в которую в качестве параметра передаются указатели на секцию кода. В свою очередь, адрес сей процедуры выступает аргументом 5-ти процедур по адресам: 30CA4C53,30CA6864,30CA7208,30CA557C,30CA5ED7, вызываемых из 35 мест. Скипанье любой из процедур ведёт к описанному выше плачевному финалу… В общем жопа полная, полнейшая. Теперь я понимаю, почему в своё время крякнут был инсталлятор офиса, а не он сам – мелкомягкие индусы вместо оптимизации своего блевотного кода и устранения багов, занимались и занимаются вставлянием палок в колёса приличным людям.

| Сообщение посчитали полезным:

FalseMaster
а проверить условие долбанного диалога не, никак?
изменив условие - избавляемся от необходимости патча.
в противном случае - придётся инлайнить. Перехватывать ближайшие к месту патча апи и проверять рва возврата, после чего патчить


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

| Сообщение посчитали полезным:

-=AkaBOSS=- пишет:

>> а проверить условие долбанного диалога не, никак?

Если б я был ядрёным кулхацкером, то может и как, но увы и ах… Для изменения условий требуется знание структуры файла "%ALLUSERSPROFILE%\Application Data\Microsoft\Office\Data\opa11.dat" и ветки реестра "[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Common\BaseSuite]", по сути ты предлагаешь мастырить keygen.

>> в противном случае - придётся инлайнить.

Так я и поступил. Но пошёл напролом и засплайсил не ближайшие API'шки, а саму проверочную процедуру, точнее 3 из 5 (как выяснилось по ходу колупания… даа, хитры мелкомягкие), и подсовываю им оригинальные байты. В общем с грехом пополам Word завёлся, но тестировать конечно надо тщательно – на 90% уверен, что в самый неожиданный момент вылезет какая-нибудь бяка, да и портабелизации ещё непочатый край – на данный момент я только предохранился от создания новых ключей реестра (файлы/папки вообще не трогал), но существующие подвержены изменениям, и, как я успел заметить, сие непотребство имеет место. Такие дела.

За помощь премного благодарен. Если б ты мне не подарил адрес диалоговой функции, ничего бы у меня не вышло. Кстати, не сочти за наглость, но очень хочется узнать, как ты его выудил (если конечно это не профессиональный секрет) – в будущем мне это знание может пригодиться, версий-то у этой DLL'ки немало.

| Сообщение посчитали полезным: