from:"Jerry"


Здравствуйте, Ded.

Вы писали 21 сентября 2007 г., 21:58:30:

D Jerry wrote:

 Hello Ded,
 
 Всего тебе хорошего и побольше.

DЫтц! Фигасе! Наверное самый редкий гость из стариков, а именно ты и
D вспомнил
D Спасибо
   Не за що. :-)
   У меня дочка в один день с тобой родилась :-)

-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re[2]: Похоже на пятничное чтение


Здравствуйте, Ded.

Вы писали 21 сентября 2007 г., 21:37:54:

D  Щаззз... Как воттку сувенирную - так в одно жало в снегах рядом с
D поездом хомячить, а как закусить - так подавай ему питерский лемончик
Иэх.. Были времена. :-)

D Сами и порежем и закусим
Хорошо. :-)
Обещаю при свидетеля: как буду в Питере, с меня бутылка
бульбашки с бульк-метками :-)
Про лимончики - договаривайся с Олегом. :-)
Я тока сало могу :-)

-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re[4]: Похоже на пятничное чтение


Здравствуйте, Игорь.

Вы писали 24 сентября 2007 г., 14:27:02:

ИГ Я так понимаю, прочитав перенесёную тему, что мы уже делаем свои выводы и
ИГ оставим этого заблудшего дурой помирать (с) народный анекдот
Заблудший как-то сам отошел от обсуждения :-)
Вместо него теперь следующий адепт монументальной архитектуры.
Что-то как-то народ отмирает при переходе к конкретике.

P.S. Не умеют на RSDN вести жарких аргументированных споров. То ли
дело на эпсилоне когда-то :-)

-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re[2]: Похоже на пятничное чтение


Здравствуйте, Dmitriy.

Вы писали 24 сентября 2007 г., 15:48:28:

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

-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re[2]: Похоже на пятничное чтение


Здравствуйте, Kovalenko.

Вы писали 24 сентября 2007 г., 16:23:10:

 Згадала стара, як молодою була... (С)
 Мульён лет прошло с тех пор, до нашей эры.
 Да и нетикет той поры, ни в какое сравнение
 с нынешним нигилизмом и тотальной безграмотностью...

KD Насчет а где миниоткат в RC транзакции и затяжного молчания, я так
KD понимаю ты не можешь вылезти из под стола от смеха?
KD http://www.rsdn.ru/Forum/message/2668632.aspx

Да, да да...
Алекс, ждём!

А то я не выдержу, но у меня не так смешно получицоо. :-)


-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re[2]: Про IB неправ и все такое


Здравствуйте, Fanis.

Вы писали 24 сентября 2007 г., 16:14:48:

F Добро, я на днях выложу на своем сайте все, что наработаю.
F Фанис

Не забудь минимальную сопроводиловку к коду.
И адреса, куда слать изменения/апдейты.

-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re[2]: Похоже на пятничное чтение


Здравствуйте, Alex.

Вы писали 24 сентября 2007 г., 17:30:20:

Блин.
Стёб не закончился. Sheridan очь тонко в КСВ на RSDN отметился:
http://rsdn.ru/Forum/Message.aspx?mid=2668791only=1

или, что бы уж сразу:
http://realurix.livejournal.com/2052.html


-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re[2]: Похоже на пятничное чтение

Здравствуйте, Kovalenko.

Вы писали 24 сентября 2007 г., 18:26:20:

KD Пусть прочитай о себе всю правду-матку
KD Вдруг вернется с лозунгом - Я видел свет!
Не. Вряд ли. Это ж революция в мозгу у человека должна
произойти. Особенно после вот таких перлов:

---

КДВ Есть коннект. в его рамках можно одновременно стартовать несколько
транзакций.
IB: Вот это уже не логично.

---
comment: До этого в топике не было ни слова про многопоточность.

КДВ Как минимум, чтобы не открывать каждый раз новый коннект если потребуется
стартовать транзакцию.
IB: Как минимум это не логично потому, что коннект приходится шарить,
IB: значит надо где-то хранить состояние подключения.
IB: А stateful приложения писать существенно сложнее чем stateless.
IB: Так что наличие нескольких транзакций в одном подключении — фича не самая
полезная,
IB: если сервер в состоянии грамотно разрулить ресурсы при отдельном
подключении
IB: на каждую транзакцию (читай — поддерживает пулинг)

---
comment: Ниже в транзакции (1) данные непосредственно не изменялись ни разу. :-)

SMПример однопоточной параллельности:
SMстарт первой транзакции (1).
SMстарт вотрой транзакции (2).
SMв (1) фетч данных
SMв (2) адейт записи, входящей в отфетченный набор из (1)
SMcommit (2)
SMрефетч уже запрепаренного запроса в (1)
SMcommit/rolback (1) (не имеет значения, модификации не проводились).
SMИтого: в рамках одного подключения последовательно-параллельным способом
SMполучены данные, живущие в сервере.

IB: Транзакция обладает ACID-ностью.
IB: Буковка I — изолированность. На практике это означает, что транзакция (2)
не
IB: может увидеть результат работы транзакции (1), до тех пор, пока (1) не
зафиксировалась.
IB: Если позволить делать такие фокусы, то это приведет к эффекту
IB: Cascading Aborts — если ранзакция (2) зафиксируется, а транзакция (1) по
каким-то причинам
IB: не сможет, то и (2) надо тоже откатывать. Более того, надо откатывать все
транзакции,
IB: которые к этому времени успели попользоваться изменениями всесенными (2) —
и далее по цепочке.
IB: Если этого не делать, то окажется что транзакция (2) зафиксировала данные,
IB: которые никогда не существовали.

---

Я специально (не для себя, не подумайте) выбрал особо клинические места.
На языке психиаторов называется пограничный синдром.

P.S. Я не специально, друг диссер пишет, просил помочь :-)

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

--
С уважением,
Jerry mailto:[EMAIL PROTECTED]

Re[2]: Про IB неправ и все такое


Здравствуйте, sasha.

Вы писали 24 сентября 2007 г., 18:39:39:

   Кутю легче освоить чем mfc и с борланда очень легко
 перескочить. Очень хороший пример проект по бухгалтерии - Ананас,
 написан на Куте 3-й версии. Зачем привязываться к платформе? Может
 стоит уже нормально взглянуть на вещи и начать уходить от навязываний
 мелкософта? Сейчас с проверками ОБЭПа многие начали думать о переходе
 на Линукс, да только отсутствие нормальной замены 1С, Парус
 останавливает. Может стоит сделать замену?

s А связывание с данными там как происходит? (DataBinding которое)

Мы IBPP юзаем. Правда непосредственно сам биндинг (statement
fetch-App level-UI) ручками сами :-(


-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re[2]: Про IB неправ и все такое


Здравствуйте, ArtGal.

Вы писали 24 сентября 2007 г., 18:47:02:

A А про это можно подробнее? Где почитать? С чего начинать?
A Чтобы не засорять ветку:
A - можно начать другую;
A - можно в мыло artgal27 собака mail точка ru.

http://doc.trolltech.com/

-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re[2]: Про IB неправ и все такое


Здравствуйте, panter.dsd.

Вы писали 24 сентября 2007 г., 18:57:56:

Для начала видимо нужно познакомиться с местными правилами.

http://ibase.ru/conf.htm
http://groups.google.com/group/ru-firebird/web/%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%B0%20%D0%BA%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B8

-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re: QT + FB


Hello ArtGal.

A В нашем дельфинарии выбираем куда уйти от MS.
A Вернее на чем начинать новые прожекты под SuSE.
A Какую среду разработки выбрать.
A Как и чем коннектится к FB. Как делать формы.
   Ну, там (в доке) всё есть. И описание, и примеры.
   Правда после делфы будет сложновато.

A Пока, по совету Jerry читаю http://doc.trolltech.com/
A Много не понятного.
   А ты спрашивай, что не понятно :-)

-- 
Best regards,
 Jerry  mailto:[EMAIL PROTECTED]

Re[2]: Похоже на пятничное чтение

Hello Андрей Кручинин.

IB: Транзакция обладает ACID-ностью.
IB: Буковка I - изолированность. На практике это означает, что транзакция
(2) не
IB: может увидеть результат работы транзакции (1), до тех пор, пока (1) не
зафиксировалась.
IB: Если позволить делать такие фокусы, то это приведет к эффекту
IB: Cascading Aborts - если ранзакция (2) зафиксируется, а транзакция (1) по
каким-то причинам
IB: не сможет, то и (2) надо тоже откатывать. Более того, надо откатывать
все транзакции,
IB: которые к этому времени успели попользоваться изменениями всесенными (2)
- и далее по цепочке.
IB: Если этого не делать, то окажется что транзакция (2) зафиксировала
данные,
IB: которые никогда не существовали.

АК Мне кажется или это блокировочное мышление проскальзывает у IB?
Да нет, я не о том. Мой пост был немного про другое. :-)
Но объяснение этого другого - это тема не данной конференции и здесь
это будет жестким офтопом.
Может как-нить в пятницу :-)

--
Best regards,
Jerry mailto:[EMAIL PROTECTED]

Re[2]: Похоже на пятничное чтение


Hello Kovalenko Dmitry.

 Этот флейм на рсдн видимо уже вошел в анналы конфы. Этой.
 Наравне с юмором  

KD Ага. Там модераторы по очереди тупят. Хотя, в прочем, Синкляир очень
KD осторожно общался  
Ну, посмотрим, что будет завтра.
Мы ещё и WolfHound' там зацепили :-)
Там, если конечно от него не стёб пошёл, тупизна конкретная
проскакивает :-)

-- 
Best regards,
 Jerry  mailto:[EMAIL PROTECTED]

Re[2]: Похоже на пятничное чтение


Здравствуйте, Игорь.

Вы писали 21 сентября 2007 г., 12:19:02:


ИГ Кстати насчет затирки сообщений, я позавчера вечером в районе 18:00 по киеву
ИГ отправлял в эту ветку сообщение с помощию Януса, и Янус мне показал, что оно
ИГ дошло, но на следующий день проведя синхронизацию, своего сообщения не
ИГ увидел. Вопрос к следившим за дисскусией моего сообщения небыло вообще или
ИГ его затерли ??? 
Затёрли. Как и пару моих (SmlMouse) :-)
Но у мну база форумов RSDN в [EMAIL PROTECTED] на FB. И бэкап имеется. Так что:
рукописи не горят! :-)

Вообще тама ж детский сад. Я туда только для разнообразия хожу.
Из толковых форумов с натяжкой тока C++ и COM/ActiveX. Всё остальное
сильно похоже на набивание авторитетов в песочнице. :-)
Особенно если почитать статьи некоторых модераторов :-)

-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re[2]: Похоже на пятничное чтение


Здравствуйте, Kovalenko.

Вы писали 21 сентября 2007 г., 13:12:54:

 С уважением ( жители этого дома)
 Igor_123

KD Сойдет, наверное. Только согласуй слова в первом предложении. И про
KD права чела выкинь  

KD В подпись меня тоже включай.
И меня.


-- 
С уважением,
 Jerry AKA Сергей Русакович mailto:[EMAIL PROTECTED]

Re[2]: Похоже на пятничное чтение


Здравствуйте, Игорь.

Вы писали 21 сентября 2007 г., 16:05:14:


ИГ  - банит неугодных оппонентов
Уже разбанил.
Так что можно вычёркивать этот пункт.

ИГ Коваленко Дмитрий

ИГ SmlMouse(SmlMouse Забанен)
Можно оставить только SmlMouse. :-)

ИГ какие ещё замечания и пожелания???
Больше вроде нет.



-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Ded'а с днюхой!


Hello Ded,

Всего тебе хорошего и побольше.

-- 
Best regards,
 Jerry  mailto:[EMAIL PROTECTED]

Re[2]: Похоже на пятничное чтение

Здравствуйте, Oleg.

Вы писали 21 сентября 2007 г., 20:36:31:

[.skipped.]
Это ты изначальную ситуацию описал. Походу чел, начавший этот
топик сам не выдержал, и более общение не продолжал :-)

OL Посему чего вы там друг другу доказывали я непонял?!
Кто доказывал? Я развлекался :-)
Заодно проверяя пару психологических методов...

OL Разъясните мне так сказать суть проблемы?

Суть проблемы: модер пытался доказать, что несколько транзакций из
одного соединения - это очень не кошерно и плохо. И так делать
низзя :-) А то будет . Только вот про это он так и не
смог ничего рассказать. Начал уводить тему куда-то в лес (уровни
изоляции, многопоточность и т.д.). А закончил тем, что начал
удалять сообщения и банить :-)

OL P.S. Так что лучше я займусь лимончиком :-):-):-)
Всё-таки порежешь его? :-)
А в наклон растить не пробовал?

Если места не хватает - отдавай мне - у мну на офисе потолки
высокие :-)

--
С уважением,
Jerry mailto:[EMAIL PROTECTED]

Re[2]: Немного флейма. Транзакции

2007-09-20 Пенетрантность Jerry


Здравствуйте, Ded.

Вы писали 20 сентября 2007 г., 17:06:35:

D Ля, и когда вы всё успеваете, да ещё и работать...
А ты не в курсе, что теперь в сутках уже не 24 часа? :-)

-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re[2]: Немного флейма. Транзакции

2007-09-19 Пенетрантность Jerry


Здравствуйте, Kovalenko.

Вы писали 19 сентября 2007 г., 16:39:22:

KD http://www.rsdn.ru/forum/message/2662797.aspx

KD Встрял, и залег на дно... Ну что за люди...

KD Может он пятницу ждет?

Если ты про меня (SmlMouse), то мне просто надоело.
Жалко времени на такой примитивный стёб.
А про IB (FB, Yaffil) мне мог не рассказывать. :-)
Сам его юзаю с незапамятных времен (ещё до эпсилоновской конфы).

-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re: [OBORONA-SPAM] Re: OFF: Пятница 13-ое

2007-07-14 Пенетрантность Jerry


Hello Мадорский,

Friday, July 13, 2007, 1:23:44 PM, you wrote:

МГВ P.S. Я тут когда машину покупал, серьезно думал о саманте - Иранский
МГВ пежо-407. По качеству отзывы очень даже...
 Не знаю как у вас, а у нас в РБ тож саманды делать начали.
 Тока почему-то он на базе 405 пыжа. И пустой как мой каман за два
 дня до степухи был.
 
МГВ И всеж-таки не взял.
 И правильно.
 
МГВ Потому как  поездив года 3-4 захочется машину поменять.
 Мне захотелось поменять после одно дня поездок на ней.
 Все-таки моя 10-летняя верка гораздо комфортней и удобней
 20-летнего пыжа...

-- 
Best regards,
 Jerrymailto:[EMAIL PROTECTED]

Re: Re[4]: Товарищи, по поводу шифрования в YaP на sql.ru за разместил сообщение ч


Oleg LOA писал:
OL  Фемида может плодить виртуальные
процессоры как горячие пирожки ;-)
 А где на нее можно взглянуть?
OL  www.oreans.com

Не впечатлило. Тот же ASP, вид сбоку.
Добавили всякой всячины...
Размазали код. Но скрипт в отладчике по
прежнему рулит. И по прежнему можно
получить распакованный дамп. И по
прежнему это не занимает достаточно
много времени. При соблюдении
некоторых условий конечно :-)

Да, и при такой защите есть большая
вероятность замедления работы
время-зависимых кусков кода. 

--
WBR, Jerry

Re: Товарищи, по поводу шифрования в Y

Alexey Popov писал:
А это и не нужно. Ты сначала дрого и упорно будешь искать точки входа и
туда и туда.
Чего их искать. dll в памяти будет одним куском. Когда IP туда попадёт, то
вот и оно.

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

Тебе рассказать как простыми компандами типа mov, sub, xor размазывается
код?

А вот и расскажи, как скомпилированный и оптимизованный код размазать без
декомпиляции автоматически, чтобы условные и безусловные переходы не
поплыли и т.д..
Условный и безусловные переходы тоже
виртуализируются :-)
И вызовы функций тоже :-)
И много еще чего :-)

Есть желание - скомпили какой-нить
hello word и защити триальным ASP или
фемидой. Начать рекомендую с ASP - у него
немного проще загрузчик.

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

Про injection code почитать можно много
где...

Короче, код не под ВМ элементарно уязвим.
Такого кода очень мало...

--
WBR, Jerry

Re: Re[4]: Товарищи, по поводу шифрования в YaP на sql.ru за разместил сообщение ч

Oleg LOA wrote:
не много времени. При соблюдении
некоторых условий конечно :-)

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

На распакованном дампе - много :-)
А на счет условий - это больше
относится к тому, кто будет снимать
защиту.
Я, честно говоря, ожидал от фемиды
большего. Кто им мешает сделать
продвинутую мутацию кода в VM? Тогда
взлом усложнился бы на порядки...

Да, и при такой защите есть большая вероятность замедления работы
время-зависимых кусков кода.

Причём ОЧЕНЬ СИЛЬНОЕ ЗАМЕДЛЕНИЕ. Я бы сказал ЭТО главный недостаток.
Виртуалки у ней шибко тормознутые.

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

На текущий момент разбор кода VM
возможен в полуавтомачискем режиме.
Пока не будет нормальной мутации, все
так и останется.
Но нормальная мутация может привести к
еще большим тормозам...

Итак, я пришел к выводу, что на данный
момент нормальная защита возможна
только при способствовании самого
разработчика софта. Он должен
заботиться о том, что бы программу было
трудно взломать. Протекторы нужны
только для большего усложнения взлома,
но никак не претендуют на
универсальную таблетку... :-(

--
WBR, Jerry.

Re: Товарищи, по поводу шифрования в Y

Чего их искать. dll в памяти будет одним куском. Когда IP туда
попадёт, то вот и оно.

Виртуализирован только небольшой процент
всего кода и возможно точки входа в длл.
Идея атаки состоит в использовании знании
о внутренних функциях dll, не подверженных
по объективным причинам защитой виртуализации.

Говорю по опыту: это дает достаточно мало.
Потому что:
1. Нужно прорваться через загрузчик.

2. Определить, где же находиться код DLL. Поиск по сигнатурам скорее
всего ничего не даст...

3. Таки найти нужную функцию. Это уже попроще, если найдешь, из какой VM
она вызвана...

4. Добиться реального выполнения кода под точкой останова...

Решить все эти задачи достаточно трудоемко. Проще поэтапно снять защиту,
и только потом отлавливать PDB.

Речь была не про виртуализацию, а про
замусоривание невиртуализоваронного кода.

Проблема в том, что код не просто замусоривается, но еще и крадется...
И местами мутирует...

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

Вот эту мысль я не понял вообще...

Это совсем другое. У нас на столе dll почти 2мега
кода и многмегабайтное приложение на дельфи набитое
очевидными сигнатурами в коде и данных.

Хм. А как еще можно исследовать защиту? Сразу на реальном
приложении - так это сильно много времени уйдет...

Про injection code почитать можно много
где...

Если надо найти тело жирной функции, то это
сильно не помешает.

Опять не понял...

Короче, код не под ВМ элементарно уязвим.

Такого кода очень мало...

Такого кода 95%, как признавался оппонент.

Это Олег погорячился :-)

--
WBR, Jerry

Re: Товарищи, по поводу шифрования в Y

On Mon, 16 Oct 2006 15:52:31 +0300, Alexey Popov wrote:

1. Нужно прорваться через загрузчик.

А зачем? Аттачимся с процессу уже в работе. Вариант
с драйверами пока не рассмативаем.

Даже если вариант с драйвером не рассматривать.
Аттач к процессу во время работы даст еще меньше, так как
нужные куски создания кода VM будут уже зашифрованы, а
прорываться через полученные в результате мутирующие VM еще
сложнее.

2. Определить, где же находиться код DLL. Поиск по сигнатурам скорее
всего ничего не даст...

Поиск по сигнатурам - это только один из методов. Не верю что он
может не работать. Например, dll всегда использует какие до константные
данные, строки и прочее.

Тот же поиск, но по сигнатурам данных.
Данные лежат в сегменте данных...
Протектор мало того, что приводит их в нечитабельный вид,
так его загрузчик еще и размазывает все это добро по памяти.
В результате возвращаемся к п.1

Проблема в том, что код не просто замусоривается, но еще и
крадется...

Красть байты реально очень трудно ибо надо быть уверенным
что прога будет работать корректно. Обычно из ОЕП крадут.
В других случаях надо мощно анализировать код, чтобы быть
уверенным что прога не слетит.

Реально они крадутся. Например в исходном было так:
FF1518D35500 call DWORD PTR DS:[EDI] ; kernel32.getstdhandle
83C8FF or EAX,
E95C0F jmp 00F905000
83C0F5 add EAX, F0

в расшифрованном дампе:
E8F346D000 call 00568451 ; А это вызов kernel32.getstdhandle
посредством VM

10A574DF0D11 adc BYTE PRT SS:[EBP+74DF0D11]
33EF xor EBP,EDI
CC int 3
83C0F5 add EDX, F0

Как видишь, байт-длинна команд совпадает.
Но реально командны другие...
А все потому, что or EAX, и JMP
протектор выполнил где-то в недрах функции 00568451. А недра у
нее мутируют. К тому же RET из нее вышел на десяток байт позже.

Вот эту мысль я не понял вообще...

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

Вполне реально. Взлом на оборот...
Особенно если протектор заточен под определенный компилятор :-)
А они заточены :-)

Хм. А как еще можно исследовать защиту? Сразу на реальном
приложении - так это сильно много времени уйдет...

Метод взлома использует не снятие защиты а уязвимые места
конкретного хорошо известного приложения.

Попасть в эти уязвимые места трудно. Проще снять защиту.

--
WBR, Jerry

Re[2]: Товарищи, по поводу шифрования в YaP на sql.ru за разместил сообщение что и как.

Здравствуйте, Alexey.

Вы писали 12.10.2006, 10:09:59:

можно восстановить. Основная работа в реверсинге проги под ASP -
отловить настоящий EP. Имея VMWare + SI отлов EP делается за
день. Потом распакованная в памяти прога дампится вместе с вызовами
в VM.

AP У нас задача намного проще чем снять защиту. Напомню у нас стоит
AP задача расшифровать бд, которую юзает защищённая прога через
AP gds32.dll влинкованный в код. Ключ шифрования передаётся через dpb.
AP В памяти процесса кэш с рашифрованными страницами.

Не сняв защиту ты ничего нигде не увидишь. Потому что:
1. Во первых - нет возможности определить вход в API функции, так
как API вызывается из VM.
2. Стека возврата не будет
3. Сам вызов API в VM сильно не тривиален.
4. Кэш может быть и совсем не в памяти процесса, а в памяти VM,
причем раскидан кусками.

Но это вполне реализуемо. На автомате правда наврядли.
У меня на взлом Hello World, написанного на делфе и защищенного
AsProtect 2.1 ушло 3 дня.

AP Что там есть интересного?
Много чего :-)

--
С уважением,
Jerry mailto:[EMAIL PROTECTED]

Re[2]: Товарищи, по поводу шифрования в YaP на sql.ru за разместил сообщение что и как.

Здравствуйте, Oleg.

Вы писали 12.10.2006, 10:47:19:

OL AS 2.1 - это прошлый век. Таже фемида на порядок более
OL немморойная. Одно дело распаковать hellow word, другое дело
OL приложение с несколькими виртуальными машинами на каждый кусок
OL кода. Стоимость взлома возрастает на порядки.

Именно по этому и занимался с Hello World. Что бы оценить затраты
по распаковке, которые могут возникнуть на реальном приложении.
Вывод для такого рода защит не утешителен: имея отладчик с
поддержкой скриптов задача решается за приемлемое время.
Самое надежное - аппаратные ключи, в которых храниться контейнер с
ключами расшифровки кода.

По поводу нескольких VM на каждый кусок - такого пока нигде не
встречал. Да, в ASP есть отдельные VM для простых инструкций (cmp,
условные переходы), для вызовов функций, для вызовов API. Но они
не меняются для каждого сегмента.

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

OL Угу, возьми скачай демку с oreans. Как только за три часа
OL распакуешь, так мы тебя сразу внесём в топ-10 лучших кракеров :-):-):-)
Ну, я то говорил о двух-трех часах на распакованной
программе. Про распаковку я писал выше. :-)

--
С уважением,
Jerry mailto:[EMAIL PROTECTED]

Re[2]: Товарищи, по поводу шифрования в YaP на sql.ru за разместил сообщение что и как.


Здравствуйте, Alexey.

Вы писали 12.10.2006, 18:43:10:



AP Oleg LOA wrote:

 Причём тут количество потоков? Адресное пространство для всех
потоков едино за исключением тлс.
 
 
 При том что тебе нужны сттраницы не в момент работы с ней кода vio ;-), 
 иначе это будет не старница а мусор.

AP Ключевую точку на которую ставим бряк и снимаем дамп будет найти легко.

Ню-Ню :-)
Попробуй. Без получения дампа расшифрованной проги и большого траха с
переводом кода VM в что-либо более-менее читабельное об этом варианте
можно забыть. А если, как Олег писал, используется конечное множество
VM с псевдо-случайным выбором, то искать эту точку будет весело.


-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re[4]: Товарищи, по поводу шифрования в YaP на sql.ru за разместил сообщение что и как.

Здравствуйте, Oleg.

Вы писали 12.10.2006, 16:35:32:

Самое надежное - аппаратные ключи, в которых храниться контейнер с
ключами расшифровки кода.
OL
OL Здесь иная поставнока. Как можно больше гимора при отлаживании такого
кода.
OL Решается наличием множества виртуальных машин с разными виртуальными
OL процессорами на каждый скрамблируемый участок кода. У меня был опытный
вариант
OL шифрования аппартным ключём - очень медленно если шифровать всё. Правда
OL вариант с шифрованием только к примеру первых восьми байт от упакованной
OL rle-последовательности записи (или её дельты) вполне роботоспособен.

Я имел ввиду ключи на дешифрование кода приложения на лету.
В таком случае взломать программу, не имея такого ключа даже
теоретически очень и очень сложно. А защищать таким шифрованием
можно как VM, так и псевдо-код самой программы. Особых тормозов
при этом нет.

OL Фемида может плодить виртуальные процессоры как горячие пирожки ;-)

А где на нее можно взглянуть?

Достаточно получить дамп программы с вызовами в протектор,
заменить в нем вызовы в VM протектора на то, что было до этого,

OL Проблема в том чобы получить то что было то этого? А что у тебя
OL было если оригинального кода вообще нет, есть только набор
OL мутирующих псевдокинструкций реализующих алгоритм исходного кода.

Ну, с этим бороться можно. Анализом кода VM. Собственно в случае с
ASP я так и делал.

Ну, я то говорил о двух-трех часах на распакованной
программе. Про распаковку я писал выше. :-)

OL Дык после распаковки будет кучка виртуальных машин с набором
OL псевдокоманд для выполнения. Велкам как говорится разбираться с
OL каждой по отдельности. Здесь не то что часами, тут неделями
OL будешь сидеть. А большего и не надо.

Олег, не забывай, что теперь в отладчиках есть скрипты. :-)
И много рутинной работы перекладывается на них.
Да, задача будет не простой. Но в конечном итоге все-таки
решаемой. И, если посидеть потом над анализом составляющих VM,
можно найти алгоритм по переводу всего этого добра в нормальный
код. То есть, теоретически, могут появиться универсальные
программы-распаковщики для таких защит.

--
С уважением,
Jerry mailto:[EMAIL PROTECTED]

Re[2]: Товарищи, по поводу шифрования в YaP на sql.ru за разместил сообщение что и как.