Ассемблер (ASM) для AVR в вопросах и ответах

[GP1]

???
флаг установится в том случае, если выдвигаемый бит=1
а в какую сторону двигать - без разницы.

[МитяРа]

GP1..
[color=green]а в какую сторону двигать - без разницы. [/color]
Это точно..
..
В AVR-ках пока не знаю, а в МК51 есть разные команды сдвига..
Или через бит переноса или не через бит..
..
Подробно - смотри описание команд...

[GP1]

МитяРа
да у них и мнемоники почти один-в-один

[МитяРа]

Во-во.. разве, что - почти..
Смотри патронов не хватит - мя кремень..

[dymon]

У меня вопрос относительно дизассемблеров для AVR. И вопрос заключается в следующем:
1) Насколько хорошо выполняется дизассемблирование (в смысле 100% восстановления кода)?
2) Какой дизассемлер лучше?
3) Как защитить свой код от дизассемлера?
Весь вопрос впринцыпе затевался ради 3-го пункта. Очень нужно защитить свой код от нелегального использования. Думаю тема актуальна для всех....

[smac]

У меня вопрос относительно дизассемблеров для AVR. И вопрос заключается в следующем:
1) Насколько хорошо выполняется дизассемблирование (в смысле 100% восстановления кода)?
2) Какой дизассемлер лучше?
3) Как защитить свой код от дизассемлера?
Весь вопрос впринцыпе затевался ради 3-го пункта. Очень нужно защитить свой код от нелегального использования. Думаю тема актуальна для всех....

1. Если есть хекс файл (ну или дамп прошивки) то восстанавливается на 100%, собственно иначе и быть не может.
2. Я в этом не копенгаген, может кто другой подскажет.
3. Если Вы предоставляете конечному пользователю изделие с запрограммированным контроллером, то просто программируйте лок-биты (если поставлены лок-биты то стоимость взлома вашего девайса будет на уровне нескольких тысяч евро). Если Вы распространяете прошивки, то нужно в микроконтроллер сначала прошить бутлоадер (программа, осуществляющая самопрограммирование микроконтроллера) с шифрованием, т.е. прошивка будет распространяться в шифрованном виде, а расшифровка прошивки и программирование будут производиться бутлоадером внутри конроллера.
Вот как-то так.

[SII]

На 100% восстановить невозможно в принципе: дизассемблер не может гарантированно определить, где код, а где данные, не говоря уже о том, что он не может восстановить имена меток и подобную информацию.

[Yellow Tiger]

дизассемблер не может гарантированно определить, где код, а где данные,

Точчна! Особенно трудно ему будет понять что именно - код или данные - находится в том месте, куда указывает вектор ресета, он прямо голову сломает, размышляя над этим регбусом! А уж как трудно будет без имен меток, ... да еще если всё было писано на ЯВУ и никаких меток не имело в принципе(!)... В общем, полная безнадёга...

[Pooher]

На 100% восстановить невозможно в принципе

Ну, это просто полный 3,14! Ну как можно говорить такие вещи?
"В принципе", дизассемблеры для того и создаются, чтобы этот код восстанавливать. Еслибы они не могли этого сделать на 100%, нафига, скажите, они нужны?

где код, а где данные

этим Вы хотели сказать про это?:

Код: Выделить всё

   .db 'O', 0xBF, 0xBA, 0xBB, '.',' ','c', 0xB8, 0xB4, 0xBD, 'a', 0xBB, '$'

такой код дизассемблируется так:

Код: Выделить всё

   out   $3F, R20
   out   $1A, R27
   and   R2, R14
   out   $03, R6
   out   $24, R27
   out   $11, R22

Если так, то это проблема программиста, который и должен понять, что это есть, дизассемблер ни при чём.

[SII]

На 100% восстановить невозможно в принципе

Ну, это просто полный 3,14! Ну как можно говорить такие вещи?
"В принципе", дизассемблеры для того и создаются, чтобы этот код восстанавливать. Еслибы они не могли этого сделать на 100%, нафига, скажите, они нужны?

Глупость говорите. Которую сами же фактически и опровергаете чуть ниже:

Если так, то это проблема программиста, который и должен понять, что это есть, дизассемблер ни при чём.

Дизассемблер не способен полностью заменить человека. И его задача -- не думать за человека, а брать на себя рутинную работу вроде преобразования машинного кода в мнемоники ассемблера.

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

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

А уж как трудно будет без имен меток, ... да еще если всё было писано на ЯВУ и никаких меток не имело в принципе(!)... В общем, полная безнадёга...

Глупость сказали. В ЯВУ имеются имена переменных и функций -- а в результатах работы дизассемблера их не будет. Ну а принципиальных различий между именами функций в ЯВУ и метками на ассемблере нет.

Да, кстати, в ЯВУ обычно предусматривается оператор перехода goto, а значит, существуют и метки, хотя их синтаксис и отличается от ассемблерного.

[Pooher]

Я не виноват, что Вы не способны точно выражать свои мысли. Выражение

На 100% восстановить невозможно в принципе

по меньшей мере глупо. Даже извините за выражение, полный дебил поймёт, что дизассемблер без программиста - это всё равно, что автомобиль без водителя, вроде всё работает, а не едет.

[SII]

Pooher

Свою мысль я выразил совершенно точно. smac написал, что

1. Если есть хекс файл (ну или дамп прошивки) то восстанавливается на 100%, собственно иначе и быть не может.

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

Ну а насчёт этого:

Даже извините за выражение, полный дебил поймёт, что дизассемблер без программиста - это всё равно, что автомобиль без водителя, вроде всё работает, а не едет.

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

А вот в чём заключается глупость моего выражения, извините, не пойму. Или Вы считаете, что в принципе возможно гарантировать 100% правильность автоматического дизассемблирования? Вопрос-то был о качестве работы дизассемблеров, а не тех, кто ими пользуется.

[Pooher]

Или Вы считаете, что в принципе возможно гарантировать 100% правильность автоматического дизассемблирования?

Вот вот, глупость в том, что не имелось в Вашем высказывании замечательного слова "автоматического". Ну, в прочем, мне кажется вопрос снят. Просто изначально меня очень смутило Ваше высказывание, согласитесь, оно в корне не верно. Я повторюсь, дизасмы и пишут для того, чтобы "на 100%" из машинного кода получить читаемые мнемоники.

[ARV]

интересно, кто из вас реально работал с нормальным дизассемблером?
и переходы методом запихивания в стек адреса и выполнение затем RET, и косвенные вызовы процедур, и даже изврат с генерацией ложных прерываний нормальный дизассемблер отлавливает на ура. что касается разделения кода и данных, то тут так же ситуация весьма четкая: если не предприняты какие-то особые меры по типу шифрования программного кода (для МК неактуально) - дизассемблер практически не ошибается. метки и имена переменных, конечно, он подставляет свои собственные, не те, что изначально были в программе, но все более-менее понятно.

что касается программ для AVR, то если ее возможно считать из МК - можно дать 100% гарантию, что с дизассемблером или без, но она будет "взломана" очень быстро (не очень понимаю, правда, что под этим следует понимать).

[Pooher]

Я с дизассемблерами не работал и пока не собираюсь. Но это не мешает мне понимать те ФАКТЫ, про которые я говорил выше.

[SII]

Pooher

Не в порядке спора, а, так сказать, для разъяснения...

Изначально вопрос звучал следующим образом: "У меня вопрос относительно дизассемблеров для AVR. И вопрос заключается в следующем:
1) Насколько хорошо выполняется дизассемблирование (в смысле 100% восстановления кода)?"

На него последовал ответ: "1. Если есть хекс файл (ну или дамп прошивки) то восстанавливается на 100%, собственно иначе и быть не может."

Так вот, из вопроса мы видим, что речь идёт о качестве выполнения дизассемблирования именно программой-дизассемблером, а не человеком. Ну а без вмешательства человека (не было же спрошено что-нибудь вроде "с помощью какого дизассемблера я смогу при желании полностью восстановить код программы?") 100% восстановление в общем случае невозможно.

Ну а вот с этим Вашим утверждением я не соглашусь:

Я повторюсь, дизасмы и пишут для того, чтобы "на 100%" из машинного кода получить читаемые мнемоники.

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

ARV

интересно, кто из вас реально работал с нормальным дизассемблером?
и переходы методом запихивания в стек адреса и выполнение затем RET, и косвенные вызовы процедур, и даже изврат с генерацией ложных прерываний нормальный дизассемблер отлавливает на ура. что касается разделения кода и данных, то тут так же ситуация весьма четкая: если не предприняты какие-то особые меры по типу шифрования программного кода (для МК неактуально) - дизассемблер практически не ошибается. метки и имена переменных, конечно, он подставляет свои собственные, не те, что изначально были в программе, но все более-менее понятно

Мне довольно часто приходится работать с IDA Pro, правда, не с кодом для микроконтроллеров. И этот мощнейший инструмент далеко не во всех случаях справляется с программистскими извратами, хотя код, созданный на ЯВУ, он почти всегда дизассемблирует корректно. Что же касается неактуальности извратов на МК, то тут Вы ошибаетесь. Даже для несчастной АТмеги можно написать весьма запутанный код, который сорвёт крышу не только дизассемблеру, но и человеку (хотя последний, конечно, сможет в конце концов разобраться в логике работы программы, если приложит достаточные усилия). Но ведь существуют и более сложные микроконтроллеры, где возможностей для запутывания ещё больше. Нередко в их роли, кстати, выступают и клоны интеловских процессоров.

Ну а что любой код можно взломать, тут я, конечно, согласен. И не только для AVR, а для процессора любой архитектуры. Вопрос только во времени.

[Yellow Tiger]

Глупость сказали.

Её не я сказал - я её только подчеркнул, довёл до логического завершения, чтобы труднее было не заметить. Хотя, кое-кто её так и не увидел...

[IlyaJ]

подскажите как заставить таймер 1 в нижеприведенной программе считать до 128 и вообще как то можно управлять скоростью счета таймера 1 в ATtiny 2313 и числом до которого он считает


код программы

Код: Выделить всё

;ATtiny2313 
.CSEG 
.INCLUDE "tn2313def.inc" 
.org 0 
rjmp reset 
.DEF Step=r30 
.DEF Data=r0 
.DEF SSREG=r23 
.EQU Set_Tabl=16 
.EQU Offset=Set_Tabl<<1 
.EQU END_Tabl=Offset+196 
.org OC1addr 
rjmp TIM1_COMP 
.org OVF1addr 
rjmp TIM1_OVF 
.CSEG 
.org 16 

SinTab: 
.DB 5, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60, 64 
.DB 67, 71, 75, 79, 83, 86, 90, 94, 98, 101, 105, 109, 112, 116, 119, 123 
.DB 126, 130, 133, 136, 140, 143, 146, 150, 153, 156, 159, 162, 165, 168, 171, 174 
.DB 177, 180, 183, 185, 188, 191, 193, 196, 198, 201, 203, 206, 208, 210, 212, 214 
.DB 217, 219, 221, 223, 224, 226, 228, 230, 231, 233, 234, 236, 237, 239, 240, 241 
.DB 242, 243, 244, 245, 246, 247, 248, 249, 249, 250, 250, 251, 251, 252, 252, 252 
.DB 252, 252, 253, 252, 252, 252, 252, 252, 251, 251, 250, 250, 249, 249, 248, 247 
.DB 246, 245, 244, 243, 242, 241, 240, 239, 237, 236, 234, 233, 231, 230, 228, 226 
.DB 224, 223, 221, 219, 217, 214, 212, 210, 208, 206, 203, 201, 198, 196, 193, 191 
.DB 188, 185, 183, 180, 177, 174, 171, 168, 165, 162, 159, 156, 153, 150, 146, 143 
.DB 140, 136, 133, 130, 126, 123, 119, 116, 112, 109, 105, 101, 98, 94, 90, 86 
.DB 83, 79, 75, 71, 67, 64, 60, 56, 52, 48, 44, 40, 36, 32, 28, 24 
.DB 20, 16, 12, 8, 5, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255 

TIM1_COMP: 
in SSREG, SREG 
lpm 
out OCR1AL, Data 
out SREG, SSREG 
reti 
TIM1_OVF: 
in SSREG, SREG 
inc Step 
out SREG, SSREG 
reti 
reset: 
clr r31 
ldi Step, Offset 
ldi r20, 0xdf 
out SPL, r20 
ldi r20, 0xfc 
out DDRB, r20 
ldi r20, 0xf0 
out PORTB, r20 
ldi r20, 0x3f 
out PORTD, r20 
ldi r20, 0x00 
out MCUCR, r20 
LDI r20, 0x00 
out GIFR, r20 
ldi r20, 0x00 
out OCR1AH, r20 
ldi r20, 16 
out OCR1AL, r20 
ldi R20, 0xC0 
out TIMSK, R20 
ldi r20, 0xB1 
out TCCR1A, r20 
ldi r20, 0x04 
out PORTB, r20 
WDR 
ldi r20,0x0D 
out WDTCR, r20 
ldi r20, 0x01 
out TCCR1B, r20 
cbi PORTD, 6 
cbi PORTB, 3 
sei 
m1: 
cpi Step, END_Tabl 
breq m2 
rjmp m1 
m2: 
cli 
wdr 
ldi Step, Offset 
sbic PORTB, 7 
rjmp m3 
sbis PORTB, 7 
rjmp m4 
m3: 
cbi PORTB, 7 
sei 
rjmp m1 
m4: 
sbi PORTB, 7 
sei 
rjmp m1

Спасибо.

[GP1]

для управления скоростью существует прескалер.
а для изменеия модуля счета два регистра OCRA и OCRB и режис сброс по совпадению.
код не смотрел, занят

[IlyaJ]

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

Будьте так добры посоветуйте как это сделать нужно очень