1. Если есть хекс файл (ну или дамп прошивки) то восстанавливается на 100%, собственно иначе и быть не может.dymon писал(а):У меня вопрос относительно дизассемблеров для AVR. И вопрос заключается в следующем:
1) Насколько хорошо выполняется дизассемблирование (в смысле 100% восстановления кода)?
2) Какой дизассемлер лучше?
3) Как защитить свой код от дизассемлера?
Весь вопрос впринцыпе затевался ради 3-го пункта. Очень нужно защитить свой код от нелегального использования. Думаю тема актуальна для всех....
Точчна! Особенно трудно ему будет понять что именно - код или данные - находится в том месте, куда указывает вектор ресета, он прямо голову сломает, размышляя над этим регбусом!SII писал(а):дизассемблер не может гарантированно определить, где код, а где данные,
А уж как трудно будет без имен меток, ... да еще если всё было писано на ЯВУ и никаких меток не имело в принципе(!)... В общем, полная безнадёга... 
Ну, это просто полный 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Глупость говорите. Которую сами же фактически и опровергаете чуть ниже:Pooher писал(а):Ну, это просто полный 3,14! Ну как можно говорить такие вещи?На 100% восстановить невозможно в принципе
"В принципе", дизассемблеры для того и создаются, чтобы этот код восстанавливать. Еслибы они не могли этого сделать на 100%, нафига, скажите, они нужны?
Дизассемблер не способен полностью заменить человека. И его задача -- не думать за человека, а брать на себя рутинную работу вроде преобразования машинного кода в мнемоники ассемблера.Если так, то это проблема программиста, который и должен понять, что это есть, дизассемблер ни при чём.
Кажется, Вы забываете, что в природе существуют не только точки входа по сбросу и прерываниям. И гарантированно, во всех возможных случаях дизассемблер не определит, код перед ним или данные. Ну а что касается упомянутых точек входа, то это лишь частный случай, когда дизассемблеру действительно известно, что это код.Yellow Tiger писал(а):Точчна! Особенно трудно ему будет понять что именно - код или данные - находится в том месте, куда указывает вектор ресета, он прямо голову сломает, размышляя над этим регбусом!
Глупость сказали. В ЯВУ имеются имена переменных и функций -- а в результатах работы дизассемблера их не будет. Ну а принципиальных различий между именами функций в ЯВУ и метками на ассемблере нет.А уж как трудно будет без имен меток, ... да еще если всё было писано на ЯВУ и никаких меток не имело в принципе(!)... В общем, полная безнадёга...
по меньшей мере глупо. Даже извините за выражение, полный дебил поймёт, что дизассемблер без программиста - это всё равно, что автомобиль без водителя, вроде всё работает, а не едет.На 100% восстановить невозможно в принципе
На что я и ответил, что 100% восстановление невозможно в принципе -- как раз по той причине, что невозможно гарантировать 100% разделение кода и данных. Хороший дизассемблер, возможно, справится самостоятельно с достаточно простой программой, сумев разобраться, где код и где данные, но если программа сложная, такое разделение станет проблематичным. Например, в программе возможна передача управления с помощью запихивания в стек адреса, вычисляемого по хитрому алгоритму, и выполнения инструкции возврата из подпрограммы. Чтобы определить адрес перехода (а значит, обнаружить дополнительные фрагменты кода), необходимо выполнить эти вычисления, ну а дизассемблеры на такое неспособны хотя бы потому, что исходные данные для вычислений могут поступать извне.1. Если есть хекс файл (ну или дамп прошивки) то восстанавливается на 100%, собственно иначе и быть не может.
могу сказать, что это, увы, не так: встречаются ещё более полные дебилы. Во всяком случае, мне попадались деятели, которые возмущались тем, что ассемблерный файл, сгенерированный дизассемблером, не хотел транслироваться либо транслировался, но результат оказывался неработоспособным...Даже извините за выражение, полный дебил поймёт, что дизассемблер без программиста - это всё равно, что автомобиль без водителя, вроде всё работает, а не едет.
Вот вот, глупость в том, что не имелось в Вашем высказывании замечательного слова "автоматического". Ну, в прочем, мне кажется вопрос снят. Просто изначально меня очень смутило Ваше высказывание, согласитесь, оно в корне не верно. Я повторюсь, дизасмы и пишут для того, чтобы "на 100%" из машинного кода получить читаемые мнемоники.Или Вы считаете, что в принципе возможно гарантировать 100% правильность автоматического дизассемблирования?
Дизассемблер нужен главным образом для того, чтобы понять логику работы программы, а для этого одних мнемоник будет недостаточно. Любой мало-мальский квалифицированный программист сможет за достаточно короткое время сделать простой дизассемблер, тупо разбирающий входной файл по командам, но использовать результаты его работы будет тяжело. Другое дело, если речь идёт об инструменте типа IDA Pro -- но его функции заключаются далеко не только в переводе машинных кодов в мнемоники. В общем, этот перевод -- вещь необходимая, но не достаточная для настоящего дизассемблера.Я повторюсь, дизасмы и пишут для того, чтобы "на 100%" из машинного кода получить читаемые мнемоники.
Мне довольно часто приходится работать с IDA Pro, правда, не с кодом для микроконтроллеров. И этот мощнейший инструмент далеко не во всех случаях справляется с программистскими извратами, хотя код, созданный на ЯВУ, он почти всегда дизассемблирует корректно. Что же касается неактуальности извратов на МК, то тут Вы ошибаетесь. Даже для несчастной АТмеги можно написать весьма запутанный код, который сорвёт крышу не только дизассемблеру, но и человеку (хотя последний, конечно, сможет в конце концов разобраться в логике работы программы, если приложит достаточные усилия). Но ведь существуют и более сложные микроконтроллеры, где возможностей для запутывания ещё больше. Нередко в их роли, кстати, выступают и клоны интеловских процессоров.интересно, кто из вас реально работал с нормальным дизассемблером?
и переходы методом запихивания в стек адреса и выполнение затем RET, и косвенные вызовы процедур, и даже изврат с генерацией ложных прерываний нормальный дизассемблер отлавливает на ура. что касается разделения кода и данных, то тут так же ситуация весьма четкая: если не предприняты какие-то особые меры по типу шифрования программного кода (для МК неактуально) - дизассемблер практически не ошибается. метки и имена переменных, конечно, он подставляет свои собственные, не те, что изначально были в программе, но все более-менее понятно
Код: Выделить всё
;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
