@Flasher, ну есть еще другие перехватчики, можно и самому написать. Это первое что под руку попало. Да хоть даже через Rohitab, можно поставить брейкпоинт на ту функцию, и самому открыть память процесса тем же WinHex или целиком сделать дамп памяти в этот момент времени хоть через Диспетчер задач и по указанному там адресу вычитать полную строку. В api monitor просто сделано ограничение, чтобы его не перегружать.
А если бы вы не догадывались про COM и Scripting Runtime (без него не работает, хотя раньше его в программе не было), т. е. мы бы не затрагивали vbs, как бы тогда действовали?
Действия зависят от контекста. Я ведь должен знать, с какой целью анализирую исполняемый файл. Если мне нужно знать, что и куда шлёт, я ставлю сетевой перехватчик, или в коммерческих инструментах эту роль выполняет прокси-сервер, установленный как MitM. Если подозревается шифровальщик, то юзаю инструменты мониторящие файловую систему, и даю соответствующий корм (документы и т.п.). Если там защита от запуска в среде виртуализации, то запускаю на грамотно сэмулированной среде или на реальном лабораторном компьютере.
В конкретном случае ничего не зашифровано, и я сразу через Sysinternals Strings статически увидел, что за объект заюзан. Список загруженных модулей (dll) также намекает о том, откуда дальше дергаются функции.
В общем виде, есть множество методов и инструментов:
99+ беÑплаÑнÑÑ Ð¸Ð½ÑÑÑÑменÑов Ð´Ð»Ñ Ð°Ð½Ð°Ð»Ð¸Ð·Ð° зловÑедов
Но главный инструмент голова: знать где, как, чем и зачем что-либо анализируешь.
В лоб ваш вопрос решают, запуская отладчик и смотрят, на какой инструкции остановилось (например, тот MessageBox), затем отматывают исполненный код назад и смотрят, кто и каким образом эту функцию дернул. Вопрос только в опыте и кол-ве времени, которое готов затратить на анализ конкретного семпла.
