Преимущества Asm над С

kaspersky

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

Тем, что неизвестно, что именно будет. Уровень контроля кода ниже.

Да неужели? Напишите-ка на си код, который меняет местами значения двух областей памяти так, чтобы гарантированно ни один регистр (кроме неявного изменения esp) не был при этом задействован.

Неужели точно так же с трудом, как и на си?

 

Я конечно извиняюсь, что врываюсь в вашу высокоинтеллектуальную беседу, но в природе есть макрос, который переделывает следующее ?:
при вызове процедуры чтобы локальные переменные генерились основываясь не на ebp, а на esp ?
т.е

proc someproc,z,zz,zzz
variable1 dd ?
variable2 dd ?
xor eax,eax
mov eax,[variable1]
ret
endp

генерило кодес:
xor eax,eax
mov eax,[esp-4]

вместо
xor eax,eax
mov eax,[ebp-4]

 

common_up
Я так понимаю, речь о fasm. Нет такого, насколько мне известно. Потому что это очень нетривиально, т.к. при этом необходимо точно отслеживать изменения esp. Гарантированно это возможно только в том случае, если на пользовательский код накладываются значительные часто неприемлемые для кода ассемблерного уровня ограничения. В яву это возможно, т.к. эти ограничения уже наложены.

 

Ну так в цэ насколько мне известно стековые переменные основываются как раз на esp. Хм...м...чем это чревато ? Не чревато ли это тем, что при генерации мусорного кодеса(я еще не дошел до оного) будет палиться АВ на основе того, что фасм будет генерить локальные переменные основываясь на ebp? Еще раз повторюсь: я несколько плаваю в мусорной кодогенерации(не дошел еще до него). Просто пробиваю как бе.
Если вопрос трололо, то можете удалить его с темы.

 

common_up

тогда вам потребуется не 1, а целый комплекс макросов: как минимум переопределить проц, пуш и поп. возможно, рет. кроме того, в точках перехода потребуется применять эмитеры (можно переопределить команды), а в точках цели перехода вписывать синхронизаторы. причем, если в точках цели перехода будут сходится несколько ветвей или переходов, то может потребоваться синхронизировать не только счетчик, но и стек.
вобщем, есть над чем поработать.
если хотите использовать стек, то есть и такая техника
вы стразу цвеличиваете стек на размер локальных, временных и максимальную цепочку параметров, а потом не пользуетесь пуш и поп даже для вызова функций. только mov reg,[esp + offs] и mov [esp + offs],reg

 

common_up

Зависит от кода. Для совсем небольших функций — esp. Чаще всё-таки ebp.

Можете попробовать что-нибудь из этого:
http://board.flatassembler.net/topic.php?t=5938
http://board.flatassembler.net/topic.php?t=7764
Я, видимо, плохо искал в своё время.

 

l_inc
>> покажите мне компилятор, который транслирует в and eax, 0.
> Ну предположим, нет такого. И что? Одну лишнюю инструкцию нашли, и решили,
> что это доказывает, что у яву и асм идентичный уровень контроля кода?
это доказывает, что контроль дает только hex-редактор. все остальное это только разные уровни контроля. разницу между "дает контроль/не дает контроля" и "дает больший или меньший контроль" надеюсь вы и сами понимаете.

>> ну и чем оно отличается от xor eax, eax?
> Тем, что неизвестно, что именно будет. Уровень контроля кода ниже.
блин, ну напишите for = for ^ foo. форсировать использование регистра можно ключевым словом. то, что компиляторы его игнорируют ничего не значит. можно и свой написать. вы же предложили мне допилить транслятор асма

>> матчасть. память -- можно.
> Да неужели?
volatile

> Напишите-ка на си код, который меняет местами значения двух областей памяти так,
> чтобы гарантированно ни один регистр (кроме неявного изменения esp) не был при этом задействован.
а напишите это же самое на асме, только чтобы esp тоже не был зайдейстован. вопрос был про то, как гарантированно обеспечить размещение переменной в памяти. желательно уточнить в какой. а то ведь процессор тоже не гарантирует, что при записи mov [123456], eax оно вообще куда-то попадет. и возможности проконтролировать это нет. во всяком случае на прикладном уровне. да и на уровне ядра все не так однозначно. процессор может кешировать результат и если страница дропается, то ему не нужно вытеснять это в кэш вышестоящего уровня.

 

kaspersky

Правда? А проконтролируйте в hex-редакторе использование процессором конкретных транзисторов. Бинарное описание кода/данных — такой же всего лишь уровень, как и всё остальное. И в ассемблере db — вполне стандартное средство описания как данных, так и кода, не обязывающее, но дающее при необходимости не меньший контроль, чем hex-редактор. А упомянутый _emit к си имеет такое же отношение, как xor eax,eax к питону. Либо цитату из стандарта в студию.

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

И что? volatile никак не предотвратит помещение значения переменной в регистр при даже простом переприсвоении вида a = b. Т.е., как я и сказал, нельзя гарантировать, чтобы использовалась только память или только регистры.

Ничего я не предлагал допиливать. Или смайл в данном случае указывает на осознание несостоятельнсоти аргументации?

Переменная — это место (причём не обязательно одно), где хранится её значение. Если это значение каким-то образом попадает в регистр, значит уже не удалось обеспечить размещение в памяти. Можете на си гарантировать, чтобы значение переменной не попало в РОН? Не можете.

 

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

> Бинарное описание кода/данных — такой же всего лишь уровень, как и всё остальное.
> И в ассемблере db — вполне стандартное средство описания как данных, так и кода,
на си есть uchar code[]="тут код". и что?

> не обязывающее, но дающее при необходимости не меньший контроль, чем hex-редактор.
> А упомянутый _emit к си имеет такое же отношение, как xor eax,eax к питону. Либо цитату из стандарта в студию.
на асм вообще стандарта нет. каждый изголяется как хочет. или ссылку на стандарт. хотя бы в рамках IA32. а uchar в си в стандарте есть.

> Если это значение каким-то образом попадает в регистр, значит уже не удалось обеспечить
> размещение в памяти. Можете на си гарантировать, чтобы значение переменной не попало
> в РОН? Не можете.
не могу. и что? если вы упомянули транзисторы, то вы тоже за асм ничего не можете гарантировать. особенно на прикладном уровне. при обращении к странцие возникает исключение и как оно будет обработано и что вам подсунут -- хз. или вы хотите сказать что push [xxx] не меняет регистры за исключением eip и esp? а если оно eax меняет это как? тем более, что оно его действительно меняет во многих случаях и не восстанавливает.

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

 

Интересно, а пример можно?
Только без обработки исключений.

 

kaspersky

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

 

kaspersky

У Вас неправильные шеллкоды.

 

кстати последний шелл-код, что я делал, был сделан на с помощью g++ с несколькими минимальными асм-вставками в роли компилятора, ida в роли средства вытащить код и python в роли перегнать шелл-код во всякие строковые представления... и кстати шелл-код x86 и x64 совместимый)))

 

kaspersky

Это я уже с горяча в противовес "это доказывает, что контроль дает только hex-редактор".

А то, что "тут код" попадёт не туда, куда я захочу, а куда компилятору вздумается. Так что массив uchar'ов — это уж никак не аналог db.

Вот как раз благодаря тому, что стандарта нету, Вы ну никак не сможете доказать, что ассемблер не даёт максимальный контроль над кодом. Тем более, что любой компилятор позволит определить произвольные код/данные в произвольном месте программы. А _emit существует только в студии, да и то в рамках блока __asm. Будете писать в блоке __asm на ассемблере и невозмутимо утверждать, что пишете на си?

Ага. А ещё в стандарте есть if. И толку? В общем, по поводу uchar выше.

А я и не говорил, что ассемблер даёт контроля больше, чем hex-редактор. Я говорил, что он даёт не меньше контроля (но при этом гораздо более удобен).

Моё скромное: потому что запиханы они в сишный uchar. А отчасти я с K10 соглашусь.

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

Код (Text):

1. л<[SГишяяяѓГ6‹3ѓль‹;ѓльЃоAAAAЃпAAAAСзСзСзСзчЦчЧ!ючЦVЃ;0000uСяФлЕKODAFFMJOAFNDAHOBAGAANEIBCKGDNIBAFJAOACNAJCBMIMMDGCBMFFDIPOKNFFFLEGBIAJAHMBOHBANHEGLLBFIEBOPCANAMOLHDBIHLNONOOFICDHEEIMAJIEGDMHAFAAACAAAHBOIDANONMOLIDBIOABCBCDNIGLEHFIHGMLGHDIHHJODFINAPFCGPNFFGPAGFPNFBHFAGGGANFDDGGHHPEFAGGGCPOADGGCGFDEJGGHGAJOKAEGGIHAAOBAAFDLAHGGAPEAMGGCGAAHPAAEGGIKAFOAACAAADAAAMGPIPFCOJDJNIMLFMAPAGAPNCOEMDCGGDFCDHGHDAAAFAAAHAAILAAOADIAAFOFAJHHELHHBAAJFAAIMGIMANOFAJBHALFMPLLLIBIFALLMLIFBIALLMAIFANAAABDAABGELDPGI0000

 

kaspersky
> а для тех же шелл-кодов и некоторых фрагментов защит -- асм слишком высокоуровневый.
парочку примеров?
пусть для шеллкода - недопустимость некоторых паттернов в аутпуте, но это что, повод полностью все писать
в машкоде? бред же, очевидно. '\0' и прочий стафф можно выпилить уже после трансляции с мнемоники и не
*бать мозг.

l_inc
> Я говорил, что он даёт не меньше контроля (но при этом гораздо более удобен).
Прослойка которой является сам транслятор - это на йоту и есть потеря контроля.

55 push ebp хотим вот так:
8b ec mov ebp, esp ---> 89 e5 mov ebp, esp

Как будем делать без db и прочих эмитов? Они не считаются, тк уже чистый хекскод (:

 

Еще 1 преимущество Асма:
При кодинге под винду в лузермоде (ринг3) вам не надо помнить о десятках типов вида LPCSTR LSTR LTSTR и т.п. ахинеи. У вас есть DWORD и BYTE, и на этом все. А Сишники пусть себе парят мозги.

 

M0rg0t

А при переносе на x64 нужно всего-то переписать весь код, из-за того что указатели становятся в 2 раза длиннее, что куда проще, чем запомнить десяток основных типов в C.
Или это такой вброс гуано в вентилятор?

 

Под x64 не писал, поэтому не знаю. Смотрел мануалы - там ужас (если на асме), этот фасткал это ад какой-то.

 

Люди о чем спор вообще?

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

 

Не, типы данных могут быть полезны в качестве комментариев.
Input dq ? ;какая-то переменная на 8 байт
Input HWND ? ;хэндл какого-то окна

Главное отличие, то что в асме это все добровольно, а в C добровольно-принудительно.