у нас серьезная прблема: у клиента падает прога, почему падает понять не можем. Логи не помогают. Есть система крешдампов которая автоматом пишет в лог состояние стека и полную инфу где упало впроть до адреса С++ ной строки из исходников. юзает ехе (неупакованный) + pdb файл
но не работает если ехе упакован.
Хоть какое то решение есть? Очень хочется чтобы была возможность отладки уже защищенного ехе или длл по крешдампам
Особенность VMProtect-а заключается в том, что если падение происходит внутри промутированного/завиртуализированного кода, то “реальный” адрес падения (из незащищенного приложения) практически невозможно определить. В принципе можно подправить размер файла в крешдампе чтобы его можно было грузить совместо с незащищенной программой, но опять же повторю - если адрес падения завиртуализирован, то такой разбор не поможет.
В любом случае вы можете прислать пример своей программы (оригинал exe/dll+map+vmp файлы) - мы попробуем помочь вам разобраться в проблеме.
P.S. Если случай падения проявляется только у одного клиента, то свяжитесь с нами по электронной почте - возможно что у нас уже есть решение для вас.
нет. приложение падает из-за каких то внутренних ошибок в логике прграммы, наших ошибок. Но поскольку мы не можем раздать всем клиентам незащищенную версию чтобы в случае падения по крешдампу получить где упало, состояние стека то… то имеет место быть проблема ибо мы не можем понять где упало, почему упало и как лечить (((
Особенность VMProtect-а заключается в том, что если падение происходит внутри промутированного/завиртуализированного кода, то “реальный” адрес падения (из незащищенного приложения) практически невозможно определить.
Может быть глупая идея (не знаю логику работы вашей программы, но выскажу)
А что если вести таблицу соответвий промутированого/виртуального кода с реальным кодом (+ привязка к pdb файлу если он указан во время мутации/виртуализации)?
Вы же строите таблици логических переходов/состояния регистров на входе выходе и.т.д. Почему бы эту служебную инфу на основе которой происходит мутация/виртуализация потом не использовать для back-trace анализа если глюк произошел в защищенном участке?
Понятное дело что таким файлом разработчик будет дорожить и никому на сторону давать его не будет, так что стойкость системы не нарушится, тем более он сам будет решать использовать такую возможность или нет.
Другое дело что возможно написание анализатора во много раз усложнит логику програмы… но вам виднее 
Но поскольку мы не можем раздать всем клиентам незащищенную версию чтобы в случае падения по крешдампу получить где упало, состояние стека то…
Как мне кажется есть два тупи решения:
а) доверится порядочному клиенту и выслать ему версию которая сможет собрать информацию… иначе будите терять порядочных клиентов пока не разберетесь с проблеммой сами;
b) вести более прогрессивный процесс логирования вплоть до: функция/параметры, чтобы понять в каком именно месте падает и уже более детально изучать возможные причины ошибки, но в этом варианте входные параметры логирования могут выдавать логику функции (если вы очень сильно ею дорожите)
А что если вести таблицу соответвий промутированого/виртуального кода с реальным кодом (+ привязка к pdb файлу если он указан во время мутации/виртуализации)?
Вы забываете про другую сторону баррикад - любая дополнительная информация в виде отдельного файла/таблицы и т.п. может существенно ускорить понимание логики программы со стороны взломщика (также нельзя забывать что взломщики могут вполне легально приобрести VMProtect и будут “тренироваться” на кошках у себя дома).
Мы обошли проблему, защитив только часть программы. Все работает (при помощи программки из комплекта ASProtect, чтобы корректировать размер программы в краш дампе)