Не ругайте пианиста - он играет, как умеет... (тестирование IDD)

GPcH
Давай ссыль на либу - нефиг заниматься демагогией.

Вобщем вот тебе пример с заполнением массива в рантайме:
Было:

Код (Text):

1. const ByteArray: array [0..5] of byte = (1,2,3,4,5,6)

Стало:

Код (Text):

1. var ByteArray: array [0..5] of byte;
2. ...
3. initialization
4.  ByteArray[0]:=1;
5.  ByteArray[1]:=2;
6.  ByteArray[2]:=3;
7.  ByteArray[3]:=4;
8.  ByteArray[4]:=5;
9.  ByteArray[5]:=6;

 

Blowfish ведь использует число Пи - что мешает в рантайме его вычислить?

 

ssx
Криптооанлизаторы используют сигнатуры массивов констант если они имеют достаточную длину (как например массив констант для CRC32). Никто по числу ПИ ничего искать не будет )

 

dermatolog

http://www.vb-decompiler.org/files/clsBlowfish.cls

Смотри поцедуру Private Sub Class_Initialize()

Так в Visual Basic все массивы заполняются в рантайме. Я думал у тебя есть идея рентайм криптовать и декриптовать увеличивая размер EXE в разы за счет вызова типа:

Код (Text):

1. var ByteArray: array [0..5] of byte;
2. ...
3. initialization
4.  ByteArray[0]:=Decode("sdfsdf");

Там строго забиты 765 двордов. Или ты предлагаешь их вычислять по формуле? Формулу правда не встречал, хотя может и существует в природе.

PS: А вообще хватит оффтопить, давайте вернемся к вопросу декомпиляции Delphi.

 

GPcH

Смотри еще раз мой пример на Delphi - достаточно присваивать элементы массива динамически - этого вполне хватит от поиска констант криптоалгоритмов.

Ты не поверишь, но в природе помимо VB много разных языков и авторы криптоаналайзеров как раз разарбатывают свои инструменты направленные на самые распространенные сигнатуры и компиляторы. Никто не будет заморачиваться твоей поделкой на VB.

 

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

 

Лучше скомпиль тот файл что я выложил на VB и проверь CANAL'ом - он его определит как BlowFish, несмотря на то что все там присваивается динамически.

Говорю же рантайм вариант детектится также легко поиском Dword'ов

Ага, точно, этот гонор мне знаком. Типа дельфя и вмпротект круче всех, все остальное говно и "поделки". Умерь амбиции Взгляни здраво на рынок и задумайся есть ли дело конечному пользователю начем написана программа, если она работает лучше других в своем классе? А все эти амбиции не из пустоты а привитые сначала институтом, потом коллегами, что мол все что на VB - "поделки", все что на C++, Delphi - мегакруто. А зачем менять стереотипы, верно? А еще стереотип есть, что тот у кого сертификат MS и диплом "инженера программиста" в МГУ в любой ситуации программирует быстрее и качественнее того кто закончил не относящуюся к программированию специальность. Ты тоже подерживаешь этот стереотип?

 

-

 

GPcH

Кстати ты а свой протектор до сих пор вмпротектом защищаешь?

 

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

 

GPcH

Да нет - тут как раз все с точность наоборот - сказать нечего как раз тебе. Я заметил любой спор ты постоянно пытаешься свести к своим "мегакрутым" продуктам (хоть WASM, хоть RSDN, хоть СРЯКЛАБ), это такой новый вид рекламы что-ли?

 

Спора никакого небыло. Был разговор о совершенствовании декомпиляторов, об этом тут и говорим.
А ты начал тут спорить про криптоанализаторы, CRC и прочее. Ok, выяснили это. Так может прекратим всеже флеймить? Смысл тут меряться писюками чей продукт круче? Это ты видишь во всех конкурентов, я же наоборот за всестороннее сотрудничество.

 

разговор переходит в интересное русло

 

GPcH

Спорить начал ты. Я тебе на пальцах доказал как можно обойти ЛЮБОЕ нахождение криптоалгоритма - либо это массив констант (через динамическое заполнение массива), либо это исполняемый код (через обфускацию). Тоже самое с сигнатурами VCL - простейшая обфускация тех же самых методов по работе со строками сведет результат работы твоего декомпилятора к нулю !!! Причем все что я говорю - это уже проверено и РЕАЛЬНО работает.

Ну ну - про гуано и вмпротект начал не я )

P.S. Всестороннее сотрудничество никогда не начиналось с наездов типа "гуано и чей продукт круче" - это просто несеръезно.

 

А кто спорит с этим. Против любого декомпилятора можно придумать обфускатор. Я и сам работаю параллельно над обфускацией (хотя первичная цель была именно обфускация)

Никто не спорит, что VMP справляется с поставленными для него задачами на уровне.

А это кто писал:

? Разве не ты?

Где я писал что IDD гуано? Речь шла о сотрудничестве с crypto и rnm.

 

GPcH

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

под поделкой имелось вот это:

А знаешь почему? Потому что для VB-ного p-code нужен совершенно другой подход и он совершенно не интересен 99% здесь присутствующим, т.к. только 1% в этой теме "профессионально" пишет на VB )

 

Обойти то можно но вот ценой увеличения размера EXE и добавлением тормозов в работе/загрузке программы, а это не всегда допустимо.

Вообще то clsBlowfish публичный класс, который используют практически все у кого в VB программах используется Blowfish. Да и P-Code тут при чем? В VB это Native Code который используется по умолчанию, а это тот же Delphi VCL, только VCL компилится к EXE, а MSVBVM60.DLL к EXE не компилится.

 

GPcH

Если учесть что программы на VB НИКОГДА не отличались хорошим быстродействием, то небольшая обфускация (не путать с виртуализацией) на общем фоне будет практически незаметна. С размером тоже самое.

Да при том, что я например не знаю что именно палит KANAL в твоей программе - кусок Blowfish скомпиляченного в p-code, или в натив. Если в p-code, то я тебе уже сказал выше - обфускатором для VB-ного p-code это отдельный продукт, если в натив - то подходы теже самые: динамическое заполнение массива констант или обфускация.

 

dermatolog

он палит константы, независимо от того, как они распиханы в коде
вот кусок из исходников KANAL'a:

crypt.h:

Код (Text):

1. long long_bf[] = {0x243f6a88L, 0x85a308d3L, 0x13198a2eL, 0x03707344L, 0xa4093822L, 0x299f31d0L, 0x082efa98L};
2. long bf_size = 7;
3.  
4. long long_bf2[] = {0x4B7A70E9L, 0xB5B32944L, 0xDB75092EL, 0xC4192623L, 0xAD6EA6B0L, 0x49A7DF7DL, 0x9CEE60B8L, 0x8FEDB266L};
5. long bf2_size = 8;

kanal.c:

Код (Text):

1.     if (offset=find_longs(long_bf2, bf2_size))
2.     {
3.         bf2_found=TRUE;
4.         AddRoot(hTree, offset,"Blowfish (check2)");
5.     }
6.     if ( (offset=find_longs(long_haval, haval_size)) && bf2_found==FALSE)
7.     {
8.         haval_found=TRUE;
9.         AddRoot(hTree, offset, "HAVAL");
10.     }
11.     if ((offset=find_longs(long_bf, bf_size)) && haval_found==FALSE && bf2_found==FALSE)
12.     {
13.         AddRoot(hTree, offset,"Blowfish");
14.     }

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

 

Может хватит уже говорить то чего нет? Повторяю, то что VB программы тормозные и большие - это стереотип со времен Windows 95, когда VB программы сравнивали с C++ по скорости. Размер же считали с MSVBVM60.DLL, который есть в комплекте со всеми современными версиями Windows. На данный момент тормоза натив кода VB почти сравнимы с тормозами Delphi программ, если их компилировать в режиме "With runtime packages". Размер VB программ такой же как у Cpp и Delphi (with runtime packages), потому мотивация с размером точно бредовая. В заключение скажу, что EXE файл моего декомпилятора VB без VMProtect'а занимает 250 килобайт (да да да ВСЕ 2 мегабайта исходников компилируются в 700 килобайт и жмутся пакером в 250), с VMP все это занимает 1,2 мегабайта (уже после паковки, если без паковки то около 2х мегабайт), при том что я виртуализирую всего одну крупную функцию. Так что это слишком огромное увеличение размера. И если я с этим мирюсь по причине необходимости, то врядли кто ради сомнительного скрывания крипто от CANAL'а будет смиряться с шестикратным увеличением размера EXE.

Если не видел исходники CANAL'а зачем две страницы формуа оспаривать свои предположения и еще употребляя фразы что я "болтаю ерундой"? Я например никогда не начинаю спорить не зная сути вопроса. Jupiter чуть выше даже привел кусок кода который ищет BlowFish.