О безопасности программ на Delphi

← →
Kerk © (2015-01-08 21:44) [0]

Здесь некие парни ("Hack.Lu security conference") исследовали бинарники, которые делает компилятор Delphi 2009, на предмет потенциальных уязвимостей, в том числе уделили внимание менеджеру памяти.

Презентация не новая, это видно даже по версии делфи :)
Я особо глубоко не вникал, но может быть кому-то будет интересно.

http://archive.hack.lu/2009/exploiting_delphi.pptx

← →
DVM © (2015-01-08 22:00) [1]

Итоги конференции надо было в exe файле распространять.

← →
alexdn © (2015-01-09 00:00) [2]

> Kerk © (08.01.15 21:44)
> Здесь некие парни ("Hack.Lu security conference") исследовали
> бинарники, которые делает компилятор Delphi 2009, на предмет
> потенциальных уязвимостей
Что то мне сложно понять какая тут вообще может быть уязвимость? Ну в cms понятно, это доступ к аминке, а в эхешниках что..?

← →
DVM © (2015-01-09 00:26) [3]

> alexdn © (09.01.15 00:00) [2]

> а в эхешниках что..?

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

← →
Германн © (2015-01-09 01:02) [4]

Удалено модератором

← →
Германн © (2015-01-09 01:04) [5]

Удалено модератором

← →
Кто б сомневался © (2015-01-09 01:42) [6]

Те кто пишут на C# и вообще .net - вот там весело.
Почти исходный код можно получить за пару кликов.
http://www.red-gate.com/products/dotnet-development/reflector/

← →
Кто б сомневался © (2015-01-09 01:48) [7]

> Почти исходный код

* Почти весь исходный код.

Ну конечно если спецом не перемешивать обфуфускатором. От которого код станет еще медленнее, в итак тормозном .net.

← →
Kilkennycat © (2015-01-09 02:35) [8]

> обфуфускатором. От которого код станет еще медленнее,

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

← →
Jeer © (2015-01-09 02:53) [9]

Удалено модератором

← →
DVM © (2015-01-09 10:25) [10]

> Кто б сомневался © (09.01.15 01:42) [6]

> Почти исходный код можно получить за пару кликов.

Это не исходный код, это код аналогичный исходному. Правда скомпилировать его сложно будет обратно. То же самое и в Java. Почти любое приложение из GooglePlay декомпилируется обратно.

> От которого код станет еще медленнее, в итак тормозном
> .net.

Не такой он уж и тормозной.
Этот "тормозной" уже местами быстрее нативного кода Delphi.

> Kilkennycat © (09.01.15 02:35) [8]

> есть сомнения у меня, что обфускатор влияет на скорость
> исполнения. именно в дотнете.

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

← →
Kilkennycat © (2015-01-09 10:35) [11]

> смотря как производится запутывание кода.

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

← →
jack128 © (2015-01-09 12:18) [12]

Бред какой то. Авторы внезапно выяснили, что дельфи - нативный язык с прямым доступом к памяти, соотвественно подвержен всем тем уязвимостям, что и С. Молодцы, чё.

← →
Rouse_ © (2015-01-09 13:15) [13]

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

← →
mailch © (2015-01-09 13:54) [14]

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

Полная фигня

← →
Дмитрий С © (2015-01-09 14:43) [15]

"Здесь вам не равнина - здесь климат иной!"

← →
Кто б сомневался © (2015-01-09 17:07) [16]

> Не такой он уж и тормозной.
> Этот "тормозной" уже местами быстрее нативного кода Delphi.
>

Звучит как - "А еще я на этих высоких каблуках бегать умею". ;)

← →
DVM © (2015-01-09 17:50) [17]

> Кто б сомневался © (09.01.15 17:07) [16]

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

← →
Кто б сомневался © (2015-01-09 18:23) [18]

> DVM © (09.01.15 17:50) [17]
> Если серьезно, то нет особенных причин тормозить у .net
> приложений.

Ну значит внутренняя реализация .net не совсем удачная. Не зря же программа отжирает столько памяти.
Судить нужно по конечному результату, как правило .net программы которые попадались мне, были очень неповоротливые по сравнению с аналогами (из последних "удивительных" открытий - ProgDVB (долго пользовался пока не заменил на DVB Dream, случайно попалась, на Delphi кстати ), Evernote итд - если надо вспомню остальные).

Кстати, Evernote переписали с нуля с C# на плюсы.
http://habrahabr.ru/company/evernote/blog/106994/

Как тут не вспомнить поделки апплета для Радеона итп.

← →
Кто б сомневался © (2015-01-09 18:31) [19]

> Как тут не вспомнить поделки апплета для Радеона итп.

Я кстати именно из за тормозного и глючного ПО для Radeon стал покупать видеокарты Geforce.
Вот вам пример, как одно влияет на другое.

← →
DVM © (2015-01-09 18:56) [20]

> Кто б сомневался © (09.01.15 18:23) [18]

> Не зря же программа отжирает столько памяти.

Есть такое. Результат компиляции и все промежуточные результаты надо где то хранить.

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

Под .net написать тормозной код имхо на порядок проще, чем где бы то ни было. Но при соблюдении определенных правил, потеря производительности по сравнению с с++ будет порядка 20%, что вобщем то немного.

← →
Inovet © (2015-01-09 19:29) [21]

Из комментов выше я сделал вывод: Си - плохой, Делфи - лучше, Нет - совсем так между, а вообще - всё плохо.

← →
картман © (2015-01-09 19:45) [22]

> Я кстати именно из за тормозного и глючного ПО для Radeon
> стал покупать видеокарты Geforce.

тьфу, блин - хотел было избавиться от Geforce - по причине крайне глючного ПО. Кто там вообще разработкой занимается? Никогда не встречал нормального ПО для железок.

http://pascalabc.net/

> Под .net написать тормозной код имхо на порядок проще, чем
> где бы то ни было.

Да ладно, куда уж проще плюсов
void my_func(vector<int> data) {}

> тьфу, блин - хотел было избавиться от Geforce - по причине
> крайне глючного ПО.

Поверь, на той стороне дела с этим обстоят еще хуже, причем с самым базовым функционалом - переустановить ATI или просто открыть окошко с настройками видяхи - не так то просто в определенных ситуациях (были случаи на тестовой Win 7, когда Catalyst вообще не хотел запускаться, ничего не писал при этом). :)
Поэтому нужно юзать апплеты от сторонних разработчиков - ATI Tray Tools например.

Если не веришь можешь набрать "Catalyst .net error" - и удивиться кол. проблем связанным именно с .net фрэмфорком у юзеров.
Т.е. мало того что надо решать собственные проблемы, дык еще и фрэймворк добавил гемора.

Так вот, для того чтобы переустановить этот Каталист мне пришлось удалять все .net (причем при помощи супермегаультра костыля .Net Framework Cleanup Tool (зрители кричат "вау!") ), а потом ставить его по новой.
Потом я не выдержал, и закатал свежий образ.

Такую же радость я испытываю к Windows Installer - просто чудо технология на инвалидной коляске, и тоже с костыльком Windows Installer Cleanup Uninstall.
Обалдеть просто.

> Кто б сомневался © (09.01.15 21:38) [26]

Да проблема то не в .net framework, а в кривом софте, который его использует. Delphi IDE вот тоже под .net написана, но вроде проблем с этим не испытывает, как и Visual Studio.

О безопасности программ на Delphi Найти похожие ветки