Как разбираться в чужом коде?

Тема в разделе "WASM.BEGINNERS", создана пользователем missa1, 6 ноя 2011.

  1. missa1

    missa1 Михаил

    Публикаций:
    0
    Регистрация:
    6 ноя 2011
    Сообщения:
    63
    Адрес:
    Москва
    На сайте Лукоморье на эту тему написана типа-забавная статья.

    Однако мой вопрос происходит из иного отношения к данному вопросу. Мне нужно действительно понять, как разбираться в чужом коде. Этот сайт - сайт, насколько я понимаю, профессионалов по отладке, вирусам, антивирусам, взлому, защите и другим вещам, в процессе занятия которыми приходится разбираться в чужих мыслях и коде. В том числе, я предполагаю, может встречаться плохой код (в разных смыслах).

    Как разбираться в чужом коде? Существуют ли какие-то рекомендации? Существует ли какая-то литература? Где-нибудь об этом написано? Что об этом написано здесь?

    Предполагается, что я обычный, совсем обычный программист - макросы, запросы БД, обычные языки программирования.

    Я новичок (в смысле как участник форума). Плохо знаком с данным сайтом, с его обитателями, ценностями. Догадываюсь, что эти ценности существуют. Извините, если что.

    Спасибо.
     
  2. Igor1024

    Igor1024 Васил Троянов Боянов (Azis)

    Публикаций:
    0
    Регистрация:
    15 окт 2010
    Сообщения:
    345
    Адрес:
    Sliven, Bulgaria
    По-моему никакой литры, кроме юмора на лурке нет по сабжу. Как до меня, то есть 2 варианта:
    1) Код с комментами, объяснённый. Т.е нет проблем в его понимании, главное представить алгоритм, дальше будет просто разбираться.
    2) Просто кусок кода. Знаешь лишь, что должно получиться в итоге. Над алгосом думаешь сам - мол, как бы я делал? Потом уже сидишь, пытаешься сопоставить работу кодесса.
    Я даже над сабжом никогда не задумывался, собственно...
     
  3. TrashGen

    TrashGen ТрещГен

    Публикаций:
    0
    Регистрация:
    15 мар 2011
    Сообщения:
    1.173
    Адрес:
    подполье
    Учиться, учиться и есчо раз учиться. Вот и все рекомендации.
     
  4. Psionic

    Psionic Member

    Публикаций:
    0
    Регистрация:
    25 сен 2008
    Сообщения:
    156
    Надо иметь голову, знания и великий и могучий научный тык.
     
  5. gazlan

    gazlan Member

    Публикаций:
    0
    Регистрация:
    22 май 2005
    Сообщения:
    414
    IMHO, начать с реверсинга программ на тех языках, которые лучше знаешь (неважно, исходный это код или бинарный). Знание идиом языка, типовых приемов, среды программирования - все в плюс. Нужно время, чтобы осмотреться и освоиться (типичная кривая обучения имеет очень длинное плато). Требуется терпение - "нет царского пути". Как ни банально, начинать с малого: задачи должны быть посильны, а успех стимулирует. Ну, и как в любом деле, результаты приходят после того как упрешься лбом в стену - и бодаешься, пока не проломишь :)
     
  6. GoldFinch

    GoldFinch New Member

    Публикаций:
    0
    Регистрация:
    29 мар 2008
    Сообщения:
    1.775
    если код плохой - doxigen'ом пытаться понять хоть что-то, дропать и переписывать.
    если код чистый - то и проблем нет.
     
  7. Painter

    Painter New Member

    Публикаций:
    0
    Регистрация:
    1 окт 2011
    Сообщения:
    46
    Когда впервые начал читать ассемблеровские екземплы то было очень тяжело разбираться... Приходилось читать все по очереди, начинал с точки входа и по порядку... Увидел функцию или макрос, нашел ее и попытался понять как она действует, потом возврат и дальше разбираешься в коде... Примерно через месяц такого вот чтива для меня простенькие програмки читались "налету"... Тот же совет. Много разбираешь экземплов и опыт сам собой придет. Как кстати многие и советовали. Удачи!
     
  8. missa1

    missa1 Михаил

    Публикаций:
    0
    Регистрация:
    6 ноя 2011
    Сообщения:
    63
    Адрес:
    Москва
    Спасибо всем. Кстати, псевдонимы мне представляются выбранными со вкусом. И этот вкус может быть довольно строгим.

    Igor1024, я имел в виду ситуацию, когда не известно, что должен дать алгоритм, что было в голове у автора кода и т.д., а когда надо имея код, понять, что он делает, какой результат дает, какой его смысл и т.д.
     
  9. missa1

    missa1 Михаил

    Публикаций:
    0
    Регистрация:
    6 ноя 2011
    Сообщения:
    63
    Адрес:
    Москва
    Никаких других советов точно нету?

    В таком случае, где по-вашему их есть шанс получить? В каких книгах? Может быть, на другом сайте? Хоть какой-нибудь совет.

    Неужели реально нет никакой теории? И еще я рассчитывал именно на этот сайт, потому что реверсерам и специалистам по вирусам, по защитам и т.д. ПРИХОДИТСЯ вникать в чужие коды, да еще и не самые простые и явные, как я понимаю. Неужто я ошибаюсь? Тогда в чем?
     
  10. S_Alex

    S_Alex Alex

    Публикаций:
    0
    Регистрация:
    27 авг 2004
    Сообщения:
    561
    Адрес:
    Ukraine
    Поставь перед собой задачку и решай.
    Дорогу осилит идущий... (Конфуций).
     
  11. r90

    r90 New Member

    Публикаций:
    0
    Регистрация:
    26 ноя 2005
    Сообщения:
    898
    Надо сначала определиться с целями. Зачем это надо?
    Затем... А затем нет никаких единых рекомендаций =)
    Есть лишь различные методы, как можно найти ответы на те или иные вопросы, относительно кода. Например, можно найти main, и дальше трейсить программу (можно даже в дебуггере), смотря что, когда и зачем вызывается. Можно трейсить не выполнение программы, а потоки данных. Скажем я так в gtk/gdk разбирался: я нашёл в gdk код, который читает из сокета X11, и потом отслеживал как прочитанное событие сначала разматывает стек вызовов, в процессе которого XEvent превращается в GdkEvent, потом как это событие уходит в функцию dispatch, откуда закидывается в gtk'шный коллбек, и так далее, и тому подобное.
    А вообще, идеальный способ -- это найти bugtrack программы, взять описание любого действующего бага и попытаться этот баг исправить. Сначала локализовать, выяснить откуда ноги растут, а затем подумать как исправить. Написать патч. Потом, посмотреть на патч, которым разработчики закрыли этот баг. Сравнить и подумать чем их патч лучше. Если же разработчики не написали ещё патча, то надо предложить свой патч в багтрек, добавив к нему слова о том, что "опыта мало, но много желания, и если с патчем что не так, вы говорите, я исправлю". При этом, стоит вообще баг на себя записать, и нести полную ответственность за его исправление. Так несколько багов закрыть, и в голове будет уже достаточно полное представление о коде. Кроме того, разработчики будут относится уже не как к случайному человеку со стороны, и поэтому будут более склонны отвечать на глупые вопросы типа: "а как это работает".
    Но с багтреком работает только если программа с базарной моделью разработки. Если же это не так, то придётся разбираться самостоятельно, не надеясь на помощь разработчиков.