Закрыли почемуто топик http://exelab.ru/f/action=vthread&forum=2&topic=17807.

Вот небольшой пруфкод. Ищет модификации кода для функции LdrLoadDll(взял которая побольше). Графом описывается ~43k инструкций

Откатано на XPSP3.

--> Link <--

c87c_26.02.2011_CRACKLAB.rU.tgz - Reloc.zip

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

Спасибо.
Попробовал на том что есть под рукой (w7x64), падает тут, при вызове LdrLoadDll, завтра погляжу что под xp происходит. А вообще - как то смахивает на хардкод, похоже под некоторыми осями будут траблы.



-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

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

Закрыли почемуто топик

+1, рановато закрыли.

Smon

Если есть интересн по поводу ЛС, то можно будет ещё подумать и, возможно, придумать что-то практическое (ну, чтоб это не была абстрактная теория).

-----
Stuck to the plan, always think that we would stand up, never ran.

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

Нормально тот топик закрыли, своим постом Clerk как раз и доказал ахтунг хардкода, когда нативный код можно написать за пару часов и он будет стабилен и совместим.

-----
Yann Tiersen best and do not fuck

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

В общем, я подумаю и изложу свои мысли более конкретно.

-----
Stuck to the plan, always think that we would stand up, never ran.

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

На xp работает, но очень медленно всё это, реализация с маппингом и сравнением crc будет на порядок быстрей по всей видимости.

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

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

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

-----
продавец резиновых утёнков

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

Идея стара, как мир. Одна сурьезная контора как раз енто и применяет для контроля целок своих либ. Доли секунды мапинг и прогон релоков.

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

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

Smon
> На xp работает, но очень медленно всё это, реализация с маппингом и сравнением crc будет на порядок быстрей по всей видимости.
Пропускная способность данного движка ~170k/sec инструкций(P4, U-mode, normal priority). Таким образом граф для 43k инструкций создаётся примерно за 260ms. Это весьма малое время, визуально задержка фактически не заметна.
Чексуммы не позволят вам найти функции используемые целевой. Таким образом вы не можите узнать перехвачена/изменена ли текущая функа.

ajax
> Идея стара, как мир.
Идея стара, но реализации в паблике нет, за исключением данной. Тупо проверка с оригинальной либой на диске тривиальна и интереса не представляет, так как в этом случае нет возможности определить принадлежность изменённого кода целевой процедуре.

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

Clerk пишет:
Таким образом вы не можите узнать перехвачена/изменена ли текущая функа
в этом случае нет возможности определить принадлежность изменённого кода целевой процедуре
В таком контексте - ес-но согласен.

-----
От многой мудрости много скорби, и умножающий знание умножает печаль

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

ajax
> Доли секунды мапинг и прогон релоков.
Как выше написали про тормоза, это не на парсинг время уходит а на загрузку оригинальной либы. Это и понятно, ведь весь загрузчик трассируется. Для рабочего(софт) примера это совсем не нужно, решается элементарно множеством способов, просто для данного семпла это излишне.

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

Так, изложу свою теорию (больше на гипотезу похоже), а вы скажите, кто что думает. В общем, задача стоит следующая - имеется динамическая библиотека, а в ней какая-то функция. Нужно узнать, перехвачена ли она методом пропатчивания её кода. Так вот, при загрузке динамической библиотеки её секция кода загружается в физическую память лишь однажды, и доступна для чтения всем процессам, которые того потребуют, подгрузив эту библиотеку в своё адресное пространство. Но, как только какаой-то процесс вызывает, например, VirtualProtectEx + WriteProcessMemory, модифицируя тем самым страницу кода, эта страница копируется в адресное пространство процесса (по соответствующему #PF), и её уникальная копия (модифицированная) содержится в процессе вместо первоначальной. Так вот, если мы знаем линейный (виртуальный) адрес пропатченной функции, знаем размер страницы (вызов GetSystemInfo), то можем вычислить линейный адрес страницы, далее вычислить её физический адрес, и если он не совпадёт с физическим адресом той же страницы в адресном пространстве другого процесса (в котором эта функция заведомо неперехвачена), то ахтунг, перехват имел место быть. Для его снятия нужно восстановить содержимое этой страницы из физической памяти другого (чистого) процесса. Метод должен без поправок работать на ntdll.dll и kernel32.dll, базы которых всегда постоянны (справедливо для ХР, для других не проверял), с небольшими модификациями можно юзать и для других билиотек. Вопрос только - где взять эти чистые процессы? Для PoC подойдёт, например, winlogon.exe, или csrss.exe, но, в общем случае - хз. Что скажете?

-----
Stuck to the plan, always think that we would stand up, never ran.

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

Ты плохо читал прошлый топик. Речь про аверов и прочий гавнософт. Они хукают апи во всех без исключения процессах. Тут вопрос больше в другом, для какой цели это нужно. Если для каких то своих дел, то больше подойдет всякая нестабильная херь которую постоянно предлагает клерк, если для нормальной эксплуатации софта, с совместимостью - легально короче, то метод один: мап библиотеки и расчет релоков. Так делает Themida, мало того, она потом и работает только с этими виртуальными копиями а не с основными библами и ничего, на всех виндах пашет, юзеры довольны.

-----
Yann Tiersen best and do not fuck

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

PE_Kill
> больше подойдет всякая нестабильная херь которую постоянно предлагает клерк
Не совместимость с разными архитектурами(напр. IA64) не является не стабильностью. Герь это аверские механизмы, всякие патчи, чексуммы и прочая хуйня, которая реально обходится элементарно. Вы привыкле решать задачи в десять срок, независимо от качества решения
Как на васме подьебали - какбы не менялась ось, вместо секций пайпы не начнут применяться, также не изменяться прототипы функций и значения статусов. Про какой хардкод идёт речь не понятно.

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

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

Clerk пишет:
Не совместимость с разными архитектурами(напр. IA64) не является не стабильностью.
Поиск нужных значений по сигнатурам является нестабильностью. Вам бы написать хоть раз коммерческий софт этак на 50-60 тысяч строк кода, и заявить клиентам что он у вас виндовс совместим. Судя по вашим кодесам в следующей же винде софт и свалится, а у меня работает и на последней семерке, хотя и писался под Win2000, и не переписывался при выходе новой OS.

-----
Yann Tiersen best and do not fuck

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

PE_Kill
> Поиск нужных значений по сигнатурам является нестабильностью.
Где вы у меня видили сигнатурный поиск ?
Если понимать в вашем контексте, то и импорт тоже использует сигнатуры, в виде имен или ординалов апи(например "RtlAddVectoredExceptionHandler" - в младших версиях системы её нет)

> Судя по вашим кодесам в следующей же винде софт и свалится
По каким причинам свалится ?
Прототип искомой функи я вытянул из сурсов 2000. Он не меняелся в XP и 7 и вобще маловероятно что изменится. А значения статусов вобще никогда не поменяются.

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

Но мы импорт не перебираем руками, а юзаем GetProcAddress, а не нативные апи.

Clerk пишет:
По каким причинам свалится ?

Smon пишет:
Попробовал на том что есть под рукой (w7x64), падает тут, при вызове LdrLoadDll

No comments

-----
Yann Tiersen best and do not fuck

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

> w7x64
Данный код 32-х битный. No comments.

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

Clerk пишет:
Данный код 32-х битный. No comments.

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

No comments.

Теперь внимание, сосредоточтесь, простая задача для вашего логического аппарата.

Дано:

заказчик софта, например софтфирма, бюджет 1мегарубль (к примеру, берем рашу)
конкурс на котором, первый претендент это Вы, второй например PE_Kill. Прочие норм.усл.

Как вы считаете, чье решение победит?

имхо не дай бог вам когда-нибудь писать что-то действительно системное и критически важное.

пы сы
Смысл ваших постенгов потешить ЧСВ и развести срач в комментах как вы любили делать на васме, пока вас откуда наконец-то (слава богу) не забанили.

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

Alchemistry пишет:
Как вы считаете, чье решение победит?
Это даже не вопрос ) Идеи Clerk-а всегда были интересны только с теоретической точки зрения и когда дело доходило до практики все его конструкции разваливались на раз-два и в коммерческом софте их использовать очень НЕ рекомендуется.

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

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

-----
продавец резиновых утёнков

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

Alchemistry
> Ваш ахтунговый харкод не актуален потому что существует внятная легальная документация
Во первых где вы видите хардкод, сосредоточтесь. Во вторых внятная легальная документация это сурсы, в частности 2000 и открытые wrk.

> Причем их порт на х64, IA-64 и далее будет заключаться в предельно простой настройке проекта
Данный код работает непосредственно с бинарным кодом, тотже LDE 32-х битный и не дизасмит 64-х разрядные инструкции. Универсальный, по вашему "портабельный" код это скрипт, где всё за вас делает компилятор.

> Как вы считаете, чье решение победит?
Моё решение всегда побеждает, так как это сильное решение.

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

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