То что делает сейчас Visual Assist X , в дельфи давно уже есть, пишется for и тут же строится конструкция и где тут лишнее нажатие кнопок ?
Не пользовался пакерами, а разве он при распаковке не восстанавливает в памяти тот код котрый был до изначально? можно подумать, что есть неломаемые защиты или что большинство юзеров не умеет гуглить кряки ) А если прога действительно нужная, то сколько её ни защищай кряки в сети появятся С дельфёй игрался давно - переписал на неё один из своих асм проектов с большим объёмом FPU вычислений и сначала порадовался, что тормоза всего-то раза в 1,5 - думаю классный код Дельфя сгенерила ) а потом заметил, что у меня в командной строке тасма потерялся ключик отключающий эмуляцию FPU )) т.е. тормоза оказались по сравнению с тормозным FPU эмулятором, и это с учётом того, что я тогда про оптимизацию на асме почти ничего не знал ) Полностью согласен - дельфя закрывает чакры, а без них нормальную прогу не напишешь )
EvilsInterrupt Как раз ПАКЕР после выполнения распаковки оставляет код нетронутым, да и протекторы хм.. не уравнивают педально-избыточный код с нормальным. Как уже тут не раз писали, те кому приходилось реверсить делфи-программы, вряд ли будут думать, что делфи -- хороший язык, ничем не хуже си и т.д. =) А вообще замечал, что если вопрос по реализации чего-нибудь на делфи, то он ставится "подскажите, где реализовано", а не "подскажите, как сделать", хотя возможно мне просто так везло на посты =)
Y_Mur Фигня какая-то. Нормальный человек не считает "нажимы на клавиши", на кнопкоклацанье вообще уходит (по крайней мере, должно уходить у профпригодного программиста) неизмеримо меньше времени, чем на выгрызание умных мыслей из шариковой авторучки. А у меня больше всего рабочего времени так и вообще уходит на мысли о том, что вот сейчас дочитаю очередной номер "Эго" или там "Космо", и надо бы написать хоть пару процедурок, а то неудобно как-то.
Clerk - Доводилось пересобирать звуковую WDM дровину, ( иногда падала в BSOD при сильной нагрузке). Делалось так. Проприетарный дроф (вероятно писаный на сях) запихивался в IDAPRO, из нее вытаскивалсо ASMЪ сорц, немного доводилсо до ума, компилялся TASM-ом, после чего сей obj'ик, был заюзан в PAS-сорце и все это дело скармливалось дельфе компилю, а тот в свою очеред делал DLL (она потом хачилась в SYS простейшей тулзой). Некоторые часте из ASM сорса выносились в PAS, в целях оптимизации... Выглядело примерно так: Code (Text): library viaaudio; const hal = 'hal.dll'; ntkrnl = 'ntoskrnl.sys'; prtcls = 'portcls.sys'; //; Imports from HAL.dll procedure READ_PORT_ULONG; external hal; procedure WRITE_PORT_ULONG; external hal; procedure WRITE_PORT_USHORT; external hal; procedure WRITE_PORT_UCHAR; external hal; procedure READ_PORT_USHORT; external hal; procedure READ_PORT_UCHAR; external hal; procedure KeStallExecutionProcessor; external hal; procedure KfAcquireSpinLock; external hal; procedure KfReleaseSpinLock; external hal; //; Imports from ntoskrnl.exe procedure PoSetPowerState; external ntkrnl; procedure IofCallDriver; external ntkrnl; procedure KeInitializeEvent; external ntkrnl; procedure IoInitializeIrp; external ntkrnl; procedure IoAllocateIrp; external ntkrnl; procedure KeSetEvent; external ntkrnl; procedure IoDeleteDevice; external ntkrnl; procedure IoInvalidateDeviceRelations; external ntkrnl; procedure IoFreeIrp; external ntkrnl; procedure KeWaitForSingleObject; external ntkrnl; procedure ExAllocatePoolWithTag; external ntkrnl; procedure MmMapIoSpace; external ntkrnl; procedure KeInitializeMutex; external ntkrnl; procedure KeReleaseMutex; external ntkrnl; procedure KeInitializeSpinLock; external ntkrnl; procedure ExFreePool; external ntkrnl; procedure PoStartNextPowerIrp; external ntkrnl; procedure IofCompleteRequest; external ntkrnl; procedure RtlInitUnicodeString; external ntkrnl; procedure RtlAppendUnicodeToString; external ntkrnl; procedure RtlIntegerToUnicodeString; external ntkrnl; procedure RtlAppendUnicodeStringToString; external ntkrnl; procedure IoCreateDevice; external ntkrnl; procedure ObfDereferenceObject; external ntkrnl; procedure ObfReferenceObject; external ntkrnl; procedure InterlockedIncrement; external ntkrnl; procedure InterlockedDecrement; external ntkrnl; procedure _alldiv; external ntkrnl; procedure _allmul; external ntkrnl; //;Imports from portcls.sys procedure PcNewPort; external prtcls; procedure PcRegisterPhysicalConnection; external prtcls; procedure PcRegisterAdapterPowerManagement; external prtcls; procedure PcNewMiniport; external prtcls; procedure PcRegisterSubdevice; external prtcls; procedure PcAddAdapterDevice; external prtcls; procedure PcNewInterruptSync; external prtcls; procedure PcGetTimeInterval; external prtcls; procedure PcNewRegistryKey; external prtcls; procedure PcNewServiceGroup; external prtcls; procedure PcNewResourceSublist; external prtcls; procedure PcInitializeAdapterDriver; external prtcls; procedure sub_10716;// proc near //; DATA XREF: .rdata:00011B18o asm //arg_0 = dword ptr 4 xor eax, eax push eax push eax push eax push eax mov eax, [esp+10h+dword ptr 4] add eax, 50h push eax call KeWaitForSingleObject ret 4 end; procedure _DriverEntry; external; {$L viaud} asm leave jmp _DriverEntry end. так что, чем дельфе не асмЪ?
SII Мир. Мир. Я сам когдато пасил. Ничего плохого в пасоподобных лангах не вижу и пользую их когда надо (напр, пасоподобный луа - имхо наиболее оптимальный вариант в разрезе - функционал/размеры/скрость среди скриптовых языков). Оберон и оберсемейство даже очень нравится (непонятно чего пасеры так на дельфу подсели, обероны имеют приятнее синтаксис, открыты, имеют кучу реализаций под разные платформы, идея интерфейса - это чтото с чемто. Немного довести интерфейс (имхо), разобраться с компоновщиком и импортером (или это есть уже?) ). Ну, а мне ветка С приятнее. Вкус такой. Для себя втыкаю в инферно с лимбо (отСшный модульный поточноориентированый, с очень строгой типизацией (двойная проверка) язык). Здорово смесь уних с обероном напоминает + есть там еще. Идея на идее. Очень до ума довести охота.
Как по мне это скорее недостаток чем достоинство. Хотя и в Дельфи это реализуется очень просто. Достаточно наследовать класс от TInterfacedObject - и подсчет ссылок и автоматический вызов деструкторов обеспечен. Такая операция была всегда.
>>автоматический вызов деструкторов обеспечен. причем изначально это было применено в васике, а потом Delphi и токо потом в с++. на заметку: всем привычное Ctrl+space подсказка по дописыванию ф-ции\переменной и т.д. перекочевала из васика, может не будем пользоваться этим ?
/offtop Я думаю, Clerk'у тоже пригодится.. Прилось в свое время написать, чтобы мостиков не было: Code (Text): inv0ke macro fname, params: VARARG count = 0 FOR param, <params> count = count+1 @CatStr(var,%count) TEXTEQU <param> ENDM nparam = count REPT count push @CatStr(var,%count) count = count -1 ENDM %echo @CatStr(_imp__,fname,@,%(nparam*4)) extern @CatStr(_imp__,fname,@,%(nparam*4)): dword call @CatStr(_imp__,fname,@,%(nparam*4)) ENDM По мотивам уроков по оптимизации от _Mikl.
Aspire чтобы мостиков не было достаточно подключить правильные инклюды, и не надо никаких извращений с макросом Правда куда то они тут на васме задевались... прикрепляю модифицированную версию под современные версии masm
Y_Mur Не могу скачать. Залейте куда-нить ктонить. Спасибо. На сей момент сижу за изучением Си. После масма тяжеловато, если честно. Сложный синтаксис, очень много скобок, особенно при разименованиях/приведениях, с которыми тоже не просто разобраться. Код генерится очень близкий к масму. При отключенной оптимизации постоянно вижу такую картину в отладчике: call LoadLibraryA mov dword ptr [ebp-c], eax mov eax, mov dword ptr [ebp-c] ... При включенной оптимизации такого конечно же нет, что радует. Стандартной библиотекой стараюсь не пользоваться, у очень увеличивается объем экзешника - это во-первых, а во-вторых теряется смысл проиходящего в системе. Возмем тот же malloc vs VirtualAlloc или _try & _catch по сравнению с обычной реализацией сеха с помощью асма. Пользуясь случаем, хочу спросить, какой сишный компилятор наиболее полно поддерживает синтаксис асма? А то в VS Express 2008 с этим проблема. PS. Огромный респект Great! Огромный респект censored!
Да, да, видел где-то вроде на рсдн, примерно такой пример, что не нравится С-никам Code (Text): var Obj: TSomeClass; begin Obj:=TSomeClass.Create; // тут что-то делаем с обьектом Obj.Free; // Нужно явно освободить обьект, иначе будет утечка end; И чем-то им это не понравилось. Помоему все логично: обьект создается - обьект уничтожается... Еще бы так написали: Code (Text): var Buffer: Pointer; begin Buffer:=VirtualAlloc(.... // Здесь что-то делаем с памятью VirtualFree(Buffer, ... // Память надо освободить, иначе будет утечка Или Ц и память освободит автоматически? Code (Text): var P: PChar; // любой типизированный указатель begin ... inc(P, 10); ... Вот я когда-нибудь соберусь с духом и перепишу DDK на Делфи
Aspire Спасибо, но мне это не нужно. Не имеет значения есть ли ссылка. Даа, в макросах ты разбираешся.. и только.. Partner К примеру, сегодня я продолжил писать трассировщик, чистый шелкод режима ядра. Другой язык кроме асма не подходит. Ну юзайте хлам - а я будем юзать асм).
Clerk Ты как всегда категоричен. А ведь согласись, как и у всех здесь присутствующих, у тебя есть свои пристрастия. Вот ты юзаешь масм. С какого перепугу? Ведь фасм гораздо более гибкий и низкоуровневый. Не нравится синтаксис, верно? Так это примерно тоже самое разлчичие, которое обсуждается здесь для ЯВУ )) Тебе даже Y_Mur указал _некоторые_ недочеты масма. Юзай фасм: импорт - руками, экспорт - руками, все руками. Про шеллкод здесь никто не спорит - и так понятно что асм. На самом деле, правильно кто-то сказал, что задача определяет язык. Если мне нужно написать вирус - я выберу асм, если многооконное, многофункциональное приложение - однозначно ЯВУ. Профессионалы со мной, я думаю, согласятся. Для тебя и меня - это хобби, а для них - это хлеб. И вылизывать каждый байт кода, чтобы Clerk это оценил (а реальный юзер _никогда_ не заметит разницы), им не надо. Отсюда разные подходы. Все ИМХО.
