/*продублировано*/
Уважаемый All!
Есть один вопрос и предложение.

(Прошу Вас по возможности высказать свое "фи" по моему посту и разобрать "по косточкам")

Вопрос в следующем.
Начальные условия и предпосылки:
1. Холиварами не увлекаюсь, т.к. считаю, что инструменты разработки должны выбираться исходя из решения прикладной задачи и области ее применения, граничных условий и проч., а так же вкуса и предпочтения.
2. Пишу в принципе на всем, что возможно, но искренне люблю дельфу.

Суть задачи:
Пишу коммерческий проект. Веб интерфейс. Тяжелое наследие предыдущего аффтара :( (использование технологии мелкомягких (behavior) в качестве компонента ядра веб интерфейса). apache + php + mssql (блиа).
Акромя самого проекта есть сопутствующие задачи:
- сделать код проекта недоступным для модификации. Подцели:
1 внедрить лицензионные ограничения
2 сделать какое-то подобие "защиты" от прочтения кода (и прочих ресурсов, js, css, картинок и т.д.)
3 защиту от случайной (намеренной) модификации кода
4 поддержка версионности
5 легкая установка (для клиента - относительно легкая)
6 необязательное наличие выделенного сервера (т.е., чтобы мог установить хоть где).

Перед тем, как "лабать" свой велосипед просмотрел готовые решения.
Zend Encoder - в принципе хорошо, но есть минусы: 1) платный 2) есть deZender
Есть другие бесплатные аналоги. Они тоже в принципе хороши, но все они не выполняют полностью пунктов: 2,4,5

Использовал следующую технологию:
1. Взял простой алгоритм архивирования. Допилил его поддержкой RSA шифрования (думаю это лишнее). Упаковал все ресурсы по разным пакетам (отдельно js и css и статические вспомогательные html, отдельно картинки, отдельно - php скрипты)
в итоге - получилось несколько файлов-архивов.

2. Для Apache написал подключаемую библиотеку, распаковывающую нужные архивы в память и обрабатывающую входящие реквесты и при запросе ресурсов - отдаются (потоком) распакованные и найденные данные. При запросе скрипта - управление передается php
3. Для php так же - написан экстеншн, который распаковывает скриптовой архив и работает только с ним.
(это и будет далее - основной вопрос)
для написания расширения для php - использовал дельфу + допиленный php4delphi
суть работы - почти такая же как и у зенда. на этапе загрузки - переопределяется адрес нативной функции на собственную, которая и отрабатывает загрузку и подготовку скрипта к выполнению. За исключенем того, что в зенде и проч - загружается уже предкомпилированный код. Я решил не заморачиваться пока что этим (ибо время - дорого), а подгружаю нужный скрипт из распакованного ранее архива (понятно, что объем памяти, занимаемый распаковкой предкомпилированного кода будет меньше, да и плюсуется время компиляции скрипта, но это пока не критично).

как решены мои запросы:
п.2 - все (абсолютно) файлы проекта находятся в архивах (т.е. вместо 100500 файлов по куче папок в апаче - 4 файла архива с данными внутре). Прочитать их в принципе можно - запустить отладчик и найти область памяти, куда распаковываются данные, но - дорого по времени и ресурсам относительно стоимости ПО.
п.3 - фактически на веб сервере нет ни картинок и проч. файлов (в виде физических файлов). Случайно или намеренно удалить или модифицировать их содержимое - невозможно.
п.4 (очень важный). решен тем, что при загрузке архива последовательно загружаются файлы с одинаковым префиксом и при загрузке - данные с одинаковыми ключами - просто перезаписываются (получается сборка версии). например есть файл PACK_1 и файл PACK_1_V2. Логика - простая - сначала загружается и распаковывается PACK_1, потом PACK_1_V2 и при распаковке - идет проверка если элемент с ключом есть - перезаписывается, если нет - добавляется. т.е. получается новая версия и т.д. (так для всех ресурсов).
Соответственно при новой версии - просто добавляется архив с новой версией. Если нужно перейти на старую - либо удаляем, либо меняем префикс.
самый важный момент (для меня в версионности - синхронизация кода приложения и структуры, кода, набора данных в БД). Это все включается в спец пакет обновления, в котором есть временнЫе метки по версии обновления, хранящиеся в БД и подготовленный код модификации структуры БД для данной версии). Ну и плюс в БД идет последовательное наращивание версии...
п.5 - соответстенно установка - новой версии достаточно прозрачна. Скопировал новые архивы в папку и перезапустил апач.

Проблема находилась в екстеншине для php и связана она была с многопоточностью.
В принципе, саму проблему "сбоя" я решил


Пока больше писать не буду (дабы не сильно утомлять Вас).
Если будет желание - выложу ассемблерные вставки, выполняющие функцию перенаправления для их "разбора" (это и есть - основной вопрос).

Спасибо!

WarstoneПросили - отвечаем. Это невозможно.
Php интерпертатор. Если строить защиту именно им, то это будет что-то типа "обернуть кучу раз в eval". Это достается хуком на сам евал.
Если строить защиту не только им, то надо ставить что-то "байт-кодовое". А это черевато и так-же вытаскивается (байт-код обфускаторов всего чуть).
Лицензионные ограничения можно сделать только путем отсутствия части модулей/кода. А это в уже написанном проекте сложно.
Под версионностью - непонятно что подразумевается.

Это все были мысли по поводу задачи. Теперь по поводу реализации. Вообще - здраво. Вопрос скорости - сам понимаешь. Она - никакая. Вопрос надежности - такие вещи, которые ты написал, ловятся за 1-2 вечера. Я так словил работу протокола УО. Но это я. Мне было интересно.

Спасибо за ответ.

Про защиту - вопрос не в защите, а скорее в ограничении прямого доступа к сорсам и физическим файлам, а так же сокращении их количества на целевой (клиентской) системе.
Целиком и полностью осознаю, что отловить, "разобрать" и воспроизвести для спеца - дело 1 вечера (а может и меньше).

Я не строю защиту самим php. Это (для меня) был бы нонсенс.

Вот как я сделал собственно подстановку:

1. инициализация библиотеки
var p: integer;
...
p:= integer(GetProcAddress(PHPLib, 'zend_compile_file'));
asm
mov edx, dword ptr [p]
mov eax, [edx] // получаем адрес функции compile_file ;
mov dword ptr _pzend_compile_file, eax // сохраняем его в переменной указалеле функции
mov dword ptr [edx], offset _zend_compile_file // заменяем функцию на нужную.
end;
...


2. Сама функция - перенаправляющая запрос на компиляцию (первый запрос и далее директивы include и require, встречающиеся в php

asm
sub esp, $1000 { смещаемся вверх по стеку (в свободную область к младшим адресАм) }
push[esp+$1004] { сохраняем значения указателя на fileHandle }
push[esp+$1004] { адреса возврата (его можно и не сохранять)}
{ сохраняем состояние регистров !!! важно }
push eax
push ebx
push ecx
push edx
push edi
push esi
end;

asm
push [esp+$1C] { передаем в процедуру параметр - handle структуры файла. }
call dword ptr [_bcp] { вызываем нашу процедуру замены данных }
end;

asm
add esp,$4 { после вызова процедуры смещаемся на 1 позицию вверх по стеку т.к. возврат из процедуры не смещает ESP }
pop esi { восстанавливаем регистры }
pop edi
pop edx
pop ecx
pop ebx
pop eax

add esp,$1008 { возвращаемся к исходной позиции }
jmp [_pzend_compile_file]; { переходим по адресу родной процедуры - без вызова, чтобы небыло модификаций стека и регистров}

end;

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

"магические" числа смещения по стеку - честно говоря "от балды". Затык (для меня) состоял в том, чтобы вызов других процедур и функций не менял значений стека младших адресов, т.к. при исследовании самого вызова родной процедуры php было замечено неоднократное смещение по стеку как вниз так и вверх. взял 1000 (для верочки :):) - по ламерски конечно)...

WarstoneПод версионностью - непонятно что подразумевается.

Самая что ни на есть версионность софта (middleware в сопряжении со структурой базы данных).
Ну, вот есть у тебя софтина какая-то. Она же у тебя не заморожена в развитии.
Понятно какой-нибудь винрар ... программа-функция. Выпустил новую версию (с новым алгоритмом, улучшенным или более стабильным) - суть лишь прямое добавление нового функционала в релиз.

А ИС - это всегда сопряжение софта и БД. Тут скользкая дорожка. Например бывают такие запросы типа
insert into r2 select * from r1 ...
а чуть позже - в r1 добавили (или убрали) атрибут, или поменяли тип данных. и превед-медвед.
ну, это как один из самых простейших вариантов...

ну и вот ...
один клиент использует версию 1.0 и не хочет обновляться (к примеру)
другой - использует другую версию и т.д.
+ модульность.

и самое важное (для меня к примеру) - прозрачность сопровождения и его легкость.

Warstone,

Спасибо.
Обязательно воспользуюсь вашим кодом. Если не для прямого использования, то уж для изучения - точно.
То, что идет раскручивание и работа - это понятно.
К сожалению, я так и не понял, есть ли принципиальные возражения (по коду) или нет.

РосгоснанораспилтрестОМГ, только не говорите мне, что Apache+PHP работают ПОД ВЕНДОЙ, ладно?
Есть разные варианты. Надо, чтобы работало - везде. Или вы откажетесь от денег клиента, по религиозным соображениям, что "под вендой" это не "Тру"?

Росгоснанораспилтрестgrantviпропущено...

Есть разные варианты. Надо, чтобы работало - везде. Или вы откажетесь от денег клиента, по религиозным соображениям, что "под вендой" это не "Тру"?

HighLoad под вендой - это не то что не Ъ, это просто неработоспособно, особенно - в связке Apache+PHP, тем более - на "семерке". Это я не знаю, какие грибы надо курить (явно у Дедала покупать надо!), чтобы продакшн сколь-нибудь нагруженного сайта ставить на семерке.

1. Никто НЕ говорит что это highload. Задача даже НЕ БЛИЗКО к этой (хотя об этом тоже надо думать на перспективу)
2. Софтина - узкоспециализирована. Количество одновременных коннектов и нагруженность запросами - ограничено.
3. Софтина предназначена для внутрикорпоративного использования (целевая аудитория - максимум до 150-200 одновременных коннектов)

Согласен целиком и полностью, что системы с подобной предполагаемой нагрузкой НЕ должны использовать win платформу (в силу множества ограничений).

Наверное я неправильно выразил суть вопроса.
Суть была в оценке принципа предлагаемой компановки кода + жизнеспособность приведенного куска кода. Ассемблерная вставка вообще говоря не будет сильно зависеть от ЯП и платформы.

WarstonegrantviСуть была в оценке принципа предлагаемой компановки кода + жизнеспособность приведенного куска кода. Ассемблерная вставка вообще говоря не будет сильно зависеть от ЯП и платформы.Ну вы сначала на никсах попробуйте API перехватить, потом - говорите. Но вообще - я так желаю, когда ничего другого не остается. В принципе можно просто свою версию пхп поставлять и тогда не надо мучаться с ассемблером. Я-бы еще не трогал стек. Тут можно пойти несколькими путями. Самое простое - изучить VEH и просто поставить CC на адресе RET'а из оригинальной функции. Так как VEH работает до SEH и других EH технологий, то вы первым гарантированно поймаете код. В этом случае плюс в том, что вас нельзя обнаружить путем раскрутки стека, так как вы не меняете стек(вернее после своих "черных дел" вы его оставляете в том состоянии, который был до начала вызова). Правда методом анализа места возврата - легко.

Можно пойти по принципу ботов для ВоВ, но это уходить в 0-е кольцо и использовать шадоу память. ИМХО - гемор.

Спасибо большое за подробный комментарий!
Полностью согласен, что везде будут свои сложности и тонкости. Но, ведь "не будет сильно зависеть" и "не зависит" все же разные вещи. Я и не говорю, что это просто - но возможно. Ведь основной момент не в этом.
Да и к тому же я не сторонник - писать "все" самому. Есть куча готовых решений, примеров и т.д. (и думаю, что для никсов - по данной тематике - тоже), так что это лишь вопрос поиска и применения.
Про стек - согласен. По этому и возникла потребность в обсуждении.
Понимаете, у меня нет цели "запутать" кого-либо этим кодом. Была цель применить подстановку запрашиваемых данных своими.

Я думал об этом - модификации сорсов пхп. Но как-то по моему это неправильно будет. пхп - открытый и бесплатный. я же не буду открывать свои исходники. К тому же, что делать с новыми версиями пхп? опять пересобирать и тиражировать? это гемор.

В любом случае - Спасибо! Есть над чем работать.