Посоветуйте, пожалуйста, с чего начать

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

W>Посоветуйте, пожалуйста, с чего начать
W>В смысле, какие драйвера написать в домашних условиях, чтобы можно было опыта и знаний набраться и чтобы было, что предъявить потенциальному работодателю?

руткиты

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

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

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


А знания можно получить гораздо быстрее и объемнее (на старте) без написания чего-то своего этакого. И мучительной отладки своего этакого, отнимающей дни и ночи напролет, без гарантий приемлемого в т.ч. потенциальными работодателями результата. При этом, очевидно, время тратится менее эффективно — проще прочитать\понять как надо и почему, чем доходить до этого понимания на своих шишках, часто пользуясь неверными посылками и опираясь на свои непроверенные догадки — так можно никогда не дойти. Кстати, руткиты я бы не стал рекомендовать трогать, зная качество исходников в открытом доступе (в основной массе) — большие шансы что это будет провокация начать неправильно мыслить, что впоследствии будет вызывать в лучшем случае непроизвольную тягу к обходу правильных но иногда тяжеловесных инженерных решений с помощью легких и не очень хаков + позднее понимание (на своих ошибках) почему это все не есть хорошо. Хотя конечно руткиты разные бывают.

Короче, я бы порекомендовал сначала не писать, а читать.

Читать доки и примеры из DDK\src, разделы по убыванию general, input, kernel/ser*, storage, filesys и факультативно что там покажется интересно еще — но для старта хватит на долго уже перечисленного выше. Говоря читать, не имею ввиду пассивное чтение в FAR или студии. Будет гораздо полезнее собрать, проставить, подкцепить отладчик и уже потом читать активно, проверяя поведение в динамике и отлаживая непонятные места для разрешения вопросов, которые появляются в процессе чтения опять же. Соотв. я бы порекомендовал сосредоточиться на формулировании вопросов — ибо правильно поставленный вопрос часто на половину содержит в себе ответ.

Алгоритм мог бы быть примерно такой:

— DDK help: выбираем тему типа архитектура WDM, смотрим картинки, читаем (можно подключить Walter Oney в параллель, если речь о WDM. Важно пользоваться правильными и по возможности оригинальными источниками и не тратить время на неавторитетные вроде книг на русском, разве что Руссинович годится). Заодно прививаем правильные привычки.

— определяем какой раздел в DDK\src содержит примеры по теме, напрямую рекомендуемые (это есть в DDK или описаниях к самим примерам — там пишут "кто они, что они"). К примеру, берем "пример на все времена" toaster и начинаем его собирать\ставить и затем активно читать.

— появился вопрос? сразу не бежим на форум или в гугль, думаем. А именно придумываем конкретные вопросы, которые бы помогли однозначно ответить на первый. Стараемся придумывать\ставить их такими, чтобы можно было тут же проверить. Например в отладчике или каком известном инструменте системного разработчика, которые также должны быть всегда под рукой — из раздела downloads на sysinternals да OSR, бинари к книгам Рихтера Брауна Они и т.п. Практика показывает, что бОльшая часть вопросов таким образом может быть снята самостоятельно (сколько ответов в форумах состоящих из ссылок на форум? просто авторы даже не искали ответов, а летели на форум) — кроме того это несет и реальный эффект, набор самого что ни на есть реального опыта ибо "в бою" ситуация мало чем отличается — часто спросить не у кого (возможно какие-то вещи вообще никто не делал или делал но тщательно скрывает сей факт) и полагаться остается на себя, да на отладчик. Так что привыкаем.

— что делать если все равно остались\появились новые неразрешенные старым добрым методом "разделяй и влавствуй" подвопросы? А нужно стараться "разделять", то бишь учиться выделять ключевые слова и формулировать вспомогательные вопросы так, чтобы можно было потом прогуглить. Это заодно и критерий — если ты сам не можешь внятно и кратко сформулировать, выделить ключевые моменты — что-то не так, нужно еще подумать\почитать. Итак, не получилось как предложено выше — гуглим. Найдя ответ, проверяем в отладчике\текстах\доках так ли это! ибо мало ли кто что сказал. Это важно и это выработка еще одной хорошей привычки в наш век гугления в непроверенных источниках, поможет не только в ядре. Далее пытаемся ответить на оригинальный вопрос с учетом нового полученного знания. Возможно имеет смысл перечитать какие-то места в книгах\доках\исходниках.

— все равно не прет? вот теперь идем на форум и выкладываем уже продуманные и понятно (хотя бы себе) сформулированные (под)вопросы, на которые не удалось ничего нагуглить (имется ввиду поиск не только в гугле но и по этому форуму ). При этом стоит, задавая вопрос, не писать своих предполагаемых ответов\домыслов, а лучше писать что именно, где и как уже смотрели\искали. Впрочем это уже описано в бессмертном тексте "Как правильно задавать вопросы".

— получаем ответ и едем дальше, читаем следующий раздел в DDK help, смотрим след sample и т.д.

Да, процесс итеративный (как и все у нас в софтостроении) и долгий, однако зарыться со своими поделухами можно не в пример дольше + остаться с пробелами "в образовании" по описанным выше причинам. Где-то так.

PS Поиском по форуму можно найти и другие посты по теме "с чего лучше начать" — с конкретными ссылками, поэтому это сообщение оставлю от них свободным.

VAB>Короче, я бы порекомендовал сначала не писать, а читать.

IMHO, прочтение правил ПДД никого не приблизили к управлению автомобилем, хотя для тех, кто таки им управляет — это чтиво необходимое, вплоть до "учить наизусть". Так и тут — чтение технической литературы принесет наибольшую пользу, когда ее читают по делу, для разрешения конкретных назревших вопросов. Конечно, в итоге полученные знания страдают некой неупорядоченностью, зато это настоящие знания — теория, проверенная практикой. Я вот, допустим, знаю по книжкам, теоретически, что существуют файловые фильтры. Это никак не приближает меня к написанию антивируса. Т.е мое IMHO: нужно почитать что-то обзорное, потратить пару часов — а дальше взять топор и идти рубить.

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

VAB>>Короче, я бы порекомендовал сначала не писать, а читать.
именно. иначе будет "чукча не читатель, чукча писатель, однака"

TC>Так и тут — чтение технической литературы принесет наибольшую пользу, когда ее читают по делу, для разрешения конкретных назревших вопросов.
именно. я предлагаю вопросы брать из чтения реальных исходников, которые в DDK более чем хорошего качества.

TC>Конечно, в итоге полученные знания страдают некой неупорядоченностью,
именно. поэтому и предложено книжные дела (уверен, человек уже что-то прочитал раз хотя бы нашел наш форум) идти закреплять-прояснять в DDK, а не идти набираться неизвестно чего в самопальные руткиты, которые очень разные.

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

Впрочем, с уровня "после примеров DDK" вполне сгодится и изучение руткитов, но не наоборот — вот я о чем! База должна быть. База должна быть правильной. Чтобы потом, читая — понимать, где автору лениво было делать правильно, а где он просто скорее всего ошибся. Не принимая все слепо на веру и не копируя потом копи-пастом в реальный проект че попало, вызывая сильнейшее непонимание коллег и, немного спустя, руководства\заказчиков.

TC>зато это настоящие знания — теория, проверенная практикой.
знание что "нажмешь вот на эту пимпочку и будет бум" конечно настоящее и полезно знать такие вещи на будущее.
Но еще лучше знать почему почему лучше не давить на "пимпочки" и почему получается "бум", разве не так?

«Закон опыта нужно восполнить философским познанием» (с) М.В.Ломоносов

TC>Я вот, допустим, знаю по книжкам, теоретически, что существуют файловые фильтры. Это никак не приближает меня к написанию антивируса.
ну. так предложено пойти и почитать сначала DDK по теме, первоисточники так сказать. А не руткиты, хукающие IoCreateFile каким хитрым способом, а то и просто CreateFile в user mode.

TC>Т.е мое IMHO: нужно почитать что-то обзорное, потратить пару часов — а дальше взять топор и идти рубить.
Саша, так я согласен Рубить надо! Без этого никак. И именно это и предложено: прочли Руссиновича с Уолтером, пошли в лес \читать DDK и далее по алгоритму\. Рубить \читать активно\ вестимо. И конечно же вооружившись топором \отладчиком и инструментами\

Так что все сходится у нас. ну почти все

PS настаивать не буду что мой алгоритм единственно верный и\или всем подойдет. Хозяин — барин.

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

W>Посоветуйте, пожалуйста, с чего начать
W>В смысле, какие драйвера написать в домашних условиях, чтобы можно было опыта и знаний набраться и чтобы было, что предъявить потенциальному работодателю?

Для начала выбери направление, в котором хотел бы писать (Native/Net/FS/Video/...).
Скорее всего, возникнет какая-нибудь задача или здесь попроси — дадут.
А потом как уже было предложено — достигай поставленной задачи через WDK/DDK/etc.