Лидеры форума

На самом деле все не совсем так Начнем с начала - ollydbg это достаточно простой usermode отладчик. Если мы под ним запустим малварь, то начнется исполнение кода малвари (если она ничем не упакована) или мы попадем в код пакера/криптора/протектора. Естественно, что если мы по шагам протрассируем этот код, то рано или поздно мы дойдем до того момента, когда работа кода того самого пакера/криптора/протектора закончится, и мы попадем в машинный код распакованной малвари и пойдем по нему. Однако следует понимать, что: 1. протектор может понять, что запуск и работа ведется под отладчиком, и как следствие либо "сорвет" отладку (и дальнейшее исполнение кода пойдет не под контролем ollydbg), либо прервет распаковку и симулирует какую-то ошибку 2. некая малварь может быть запакована "бутербродом" из нескольких пакеров/крипторо/протекторов. Т.е. протрассировав код первого мы вместо реального исполняемого кода попадем в код второго, потом третьего ... и каждый из них может детектировать отладку или бороться с ней 3. даже если мы добрались до реальной OEP и получили наконец код малвари, то рано радоваться Ибо: 3.1 код может модифицировать сам себя в процессе работы. Причем начиная от точечных замен (например, затереть JMP посредством NOP-ов, поменять JE на JNE и т.п.) и до достаточно радикальных модификаций 3.2 может распаковаться не весь код, а только его кусочек. Остальное будет распаковываться по мере надобности – в итоге мы не сможем дампировать весь код для анализа 3.3 отлаживаемый процесс может проинжектировать некий код в другой процесс и запустить его (например, создать удаленный поток). Если вовремя это не понять и не обеспечить трассировку такого инжектируемого кода, то мы утеряем полную картину работы зверя. Хуже еще то, что инжектированный код может быть неким перехватчиком, и понять его логику работы в отладчике может быть проблемно 3.4 часть логики зловреда может быть сделано по принципу интерпретатора. Т.е. распакованный код будет интерпретатором, который в свою очередь начнет выполнение некоего P-кода. Уловить логику работы в такой ситуации под отладчиком проблемно, равно как очень сложно дизассемблировать такой семпл (мы дизассемблируем интерпретатор, тогда как исполняемый им код будут не более чем константой с непонятными данными) 3.5 зловреды не обязан проявлять свое злобное поведение сразу. Т.е. трассируя его отладчиком мы можем и не увидеть зловредного поведения, котрое проявится при определенной ситуации. Простейший пример - были одно время модны примитивный троянцы, которые при изменении буфера обмена смотрели, что там - и если там скажем номер кошелька Webmoney, то меняли его на кошелек зловредописателя. Соответственно, пока в буфере не появится подходящий номер, не активируется меняющий его код. Другой пример - реакция на подключение флешки в червяке. Нет подключения - нет реакции... 3.6 если зверь дропнет что-то и запустит, а отлаживающий код специалист это упустит, то запуск дропнутого кода пойдет уже не под отладчиком. Еще хуже драйвер - если семпл дропнет некую kernelmode компоненту, и загрузит ее - то olly будет бессилен. Аналогично буткит – дроппер запишет его в заданные сектора и отребутит ПК … 3.7 в общем случае у зверя может быть много потоков. И если однопоточное приложение отлаживать более менее просто, то многопоточное сложнее, особенно если потоки активно взаимодействуют друг с другом. 3.x и т.п., и т.д. К этому можно прибавить обфускацию - как классическую (т.е. замусоривание кода ненужными операциями, кучами переходов, фрагментами неисполняемого мусорного кода и т.п.), так и поведенческую - т.е. семпл может осуществлять сотни и тысячи ненужных вызовов API (а в цикл это породит миллионы событий), проявляя в итоге бурную, но бестолковую активность - на случай, если кто-то захочет помониторить его чем-то типа processmonitor