На сайте Лукоморье на эту тему написана типа-забавная статья. Однако мой вопрос происходит из иного отношения к данному вопросу. Мне нужно действительно понять, как разбираться в чужом коде. Этот сайт - сайт, насколько я понимаю, профессионалов по отладке, вирусам, антивирусам, взлому, защите и другим вещам, в процессе занятия которыми приходится разбираться в чужих мыслях и коде. В том числе, я предполагаю, может встречаться плохой код (в разных смыслах). Как разбираться в чужом коде? Существуют ли какие-то рекомендации? Существует ли какая-то литература? Где-нибудь об этом написано? Что об этом написано здесь? Предполагается, что я обычный, совсем обычный программист - макросы, запросы БД, обычные языки программирования. Я новичок (в смысле как участник форума). Плохо знаком с данным сайтом, с его обитателями, ценностями. Догадываюсь, что эти ценности существуют. Извините, если что. Спасибо.
По-моему никакой литры, кроме юмора на лурке нет по сабжу. Как до меня, то есть 2 варианта: 1) Код с комментами, объяснённый. Т.е нет проблем в его понимании, главное представить алгоритм, дальше будет просто разбираться. 2) Просто кусок кода. Знаешь лишь, что должно получиться в итоге. Над алгосом думаешь сам - мол, как бы я делал? Потом уже сидишь, пытаешься сопоставить работу кодесса. Я даже над сабжом никогда не задумывался, собственно...
IMHO, начать с реверсинга программ на тех языках, которые лучше знаешь (неважно, исходный это код или бинарный). Знание идиом языка, типовых приемов, среды программирования - все в плюс. Нужно время, чтобы осмотреться и освоиться (типичная кривая обучения имеет очень длинное плато). Требуется терпение - "нет царского пути". Как ни банально, начинать с малого: задачи должны быть посильны, а успех стимулирует. Ну, и как в любом деле, результаты приходят после того как упрешься лбом в стену - и бодаешься, пока не проломишь
если код плохой - doxigen'ом пытаться понять хоть что-то, дропать и переписывать. если код чистый - то и проблем нет.
Когда впервые начал читать ассемблеровские екземплы то было очень тяжело разбираться... Приходилось читать все по очереди, начинал с точки входа и по порядку... Увидел функцию или макрос, нашел ее и попытался понять как она действует, потом возврат и дальше разбираешься в коде... Примерно через месяц такого вот чтива для меня простенькие програмки читались "налету"... Тот же совет. Много разбираешь экземплов и опыт сам собой придет. Как кстати многие и советовали. Удачи!
Спасибо всем. Кстати, псевдонимы мне представляются выбранными со вкусом. И этот вкус может быть довольно строгим. Igor1024, я имел в виду ситуацию, когда не известно, что должен дать алгоритм, что было в голове у автора кода и т.д., а когда надо имея код, понять, что он делает, какой результат дает, какой его смысл и т.д.
Никаких других советов точно нету? В таком случае, где по-вашему их есть шанс получить? В каких книгах? Может быть, на другом сайте? Хоть какой-нибудь совет. Неужели реально нет никакой теории? И еще я рассчитывал именно на этот сайт, потому что реверсерам и специалистам по вирусам, по защитам и т.д. ПРИХОДИТСЯ вникать в чужие коды, да еще и не самые простые и явные, как я понимаю. Неужто я ошибаюсь? Тогда в чем?
Надо сначала определиться с целями. Зачем это надо? Затем... А затем нет никаких единых рекомендаций =) Есть лишь различные методы, как можно найти ответы на те или иные вопросы, относительно кода. Например, можно найти main, и дальше трейсить программу (можно даже в дебуггере), смотря что, когда и зачем вызывается. Можно трейсить не выполнение программы, а потоки данных. Скажем я так в gtk/gdk разбирался: я нашёл в gdk код, который читает из сокета X11, и потом отслеживал как прочитанное событие сначала разматывает стек вызовов, в процессе которого XEvent превращается в GdkEvent, потом как это событие уходит в функцию dispatch, откуда закидывается в gtk'шный коллбек, и так далее, и тому подобное. А вообще, идеальный способ -- это найти bugtrack программы, взять описание любого действующего бага и попытаться этот баг исправить. Сначала локализовать, выяснить откуда ноги растут, а затем подумать как исправить. Написать патч. Потом, посмотреть на патч, которым разработчики закрыли этот баг. Сравнить и подумать чем их патч лучше. Если же разработчики не написали ещё патча, то надо предложить свой патч в багтрек, добавив к нему слова о том, что "опыта мало, но много желания, и если с патчем что не так, вы говорите, я исправлю". При этом, стоит вообще баг на себя записать, и нести полную ответственность за его исправление. Так несколько багов закрыть, и в голове будет уже достаточно полное представление о коде. Кроме того, разработчики будут относится уже не как к случайному человеку со стороны, и поэтому будут более склонны отвечать на глупые вопросы типа: "а как это работает". Но с багтреком работает только если программа с базарной моделью разработки. Если же это не так, то придётся разбираться самостоятельно, не надеясь на помощь разработчиков.
