Активируй MS Office своими силами с помощью SoftICE. Вот и попробуешь себя "в области дизассемблирования ПО"

Здравствуйте, Фанатик, Вы писали:

Ф>Решение задачи должно быть до кодирования, а не во время, и уж никак не после

Если б это было возможно во всех случаях, не было бы обоснованной критики методы Waterfall, и возникновения альтернатив вроде Agile. Бывает, способы достижения целей в бизнес-задаче становятся понятны лишь в процессе её решения, или деже после длительного использования первого (второго, третьего,...) варианта решения.

Ф>Я давно стараюсь не делать работу, которую уже когда-то делал, за сим пришёл к ООП, ООД и даже пошёл немного дальше — вынашиваю идею порабощения мира

Ты не так понял. Переиспользование кода — это решение некоторых проблем кодирования и дизайна (не разработки!). Так же можно переиспользовать паттерны, приныипы построения архитектуры и другие уровни. Но бывают моменты, когда просто не знаешь как что-то можно сделать, но сделать надо.

Ф>Очень высока цена ошибки, и я не вижу, или не знаю никаких средств организовать работу так, чтобы минимизировать цену ошибки. Это не похоже на чтение чужого кода. Я довольно долго учился читать код, на него можно смотреть с высоты птичьего полёта, нужно уловить концепт, стиль мышления автора.

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

Ф>Если есть архитектура, то прежде всего нужно понять её, и уж потом переходить к частностям.

Это называется Waterfall и не всегда применимо, см. "если" выше Обратный процесс, а именно переход от реализации к пониманию (созданию, изучению чужой) архитектуры — есть reverse engineering. reverse code engineering — частный случая последнего.

Ф>В антивирусной индустрии приходится быть, в разработке никто толкать не будет, нужно самому решать и смотреть, т.е. быть паровозом, а не поездом.

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

Ф>гм.. "ничего нового изобрести нельзя, всё уже изобрели", всё решили — где-то я это уже видел..

Вот только не все об этом знают и/или могут. Поэтому на помощь приходит обратная разработка. Что бы осознать её необходимость, стоит выйти за пределы девелопмента, посмотреть почти на любую технику "созданную" в СССР

Резюме — RE (не RCE, хотя иногда и оно тоже) даёт возможность быть если и не паровозом, то хотя бы ближним к голове вагоном, а не плестись в хвосте индустрии.

Увидел что ты с Украины. С како-го города?
В Днепропетровске есть компаниия, где есть одтел который занимается реверсивной инженирией.
Не знаю знаком ли ты с сайтом cracklab.ru, хакерский сайт рунета. Там можешь найти автора c под ником Heх, он считается одним из лучших в СНГ, долгое время работал в этой компании. Вот, кстати, интервью с ним:
http://www.cracklab.ru/int/hex.php

Советую, так-же, от корки до корки прочитать wasm.ru (Все что касается низкоуровневого прораммирования и хакинга). Бесценно и очень интерестно.

>>дизассемблирование вирусов, патчей, алгоритмов и т.д.), что полезно почитать?
Дизасемблировать можно учиться на чем угодно. Научись ломать защиты. Реверсить куски функционала в С (это автоматически делается) и собирать его. В таком случае тебе необходимо будет познакомиться с языком С.

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