Здравствуйте!

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

Может у кого-нибудь есть рецептик?

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

A>Здравствуйте!

A>Подскажите, можно ли как-то запутать символы в PDB?
A>Хотелось бы поставлять отладочную информацию с релизными билдами, чтобы в трассировке стека были более осмысленные координаты. Но с другой стороны не хочется выдавать символьную информацию, которая будет полезна при реверсинге моего приложения.
A>Для всяких дотнетов и яв обфускация встречается на каждом шагу, а вот для нативного кода не могу найти.

A>Может у кого-нибудь есть рецептик?

Мне кажется, это взаимоисключающие параграфы

А в обфусцированной дотнет-сборке Вы на стектрейсе получите как раз те самые каракули.

A>Подскажите, можно ли как-то запутать символы в PDB?
A>Хотелось бы поставлять отладочную информацию с релизными билдами, чтобы в трассировке стека были более осмысленные координаты. Но с другой стороны не хочется выдавать символьную информацию, которая будет полезна при реверсинге моего приложения.
А зачем распространять .pdb с дистрибутивом приложения? Чтобы потом героически его обфуцировать?

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

A>Может у кого-нибудь есть рецептик?

Есть! Поднять у се6я symbol server и хранить пдбхи в нем.

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

A>Подскажите, можно ли как-то запутать символы в PDB?
A>Хотелось бы поставлять отладочную информацию с релизными билдами, чтобы в трассировке стека были более осмысленные координаты. Но с другой стороны не хочется выдавать символьную информацию, которая будет полезна при реверсинге моего приложения.
A>Для всяких дотнетов и яв обфускация встречается на каждом шагу, а вот для нативного кода не могу найти.

A>Может у кого-нибудь есть рецептик?

Ключик /PDBSTRIPPED чем-то не устраивает?

A>Хотелось бы поставлять отладочную информацию с релизными билдами, чтобы в трассировке стека были более осмысленные координаты.
Они не будут осмысленными. Внешние компоненты все испортят, тот же С++ рантайм — для него вы тоже будете пдб-шники распространять? А user32 — через него идут почти все гуевые вызовы

A>Может у кого-нибудь есть рецептик?
symbol server + source server + делать мнидампы

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

A>>Подскажите, можно ли как-то запутать символы в PDB?
A>>Хотелось бы поставлять отладочную информацию с релизными билдами, чтобы в трассировке стека были более осмысленные координаты. Но с другой стороны не хочется выдавать символьную информацию, которая будет полезна при реверсинге моего приложения.
O>А зачем распространять .pdb с дистрибутивом приложения? Чтобы потом героически его обфуцировать?

Дело в том, что без полного набора pdb на x86 нет способа получить гарантированно правильный стек трейс (ну, или просто я такой способ не знаю). Хотя неполный трейс все равно лучше, чем никакой.

ТКС>Дело в том, что без полного набора pdb на x86 нет способа получить гарантированно правильный стек трейс (ну, или просто я такой способ не знаю). Хотя неполный трейс все равно лучше, чем никакой.
так .pdb оставляйте у себя, и получайте стек трейс из дампа. Или вы стек трейс на машине клиента получить пытаетесь? Смысл?

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

B>Есть! Поднять у се6я symbol server и хранить пдбхи в нем.

Есть много противопоказаний у сервера — от стоимости трафика и скорости соединения, до корпоративных политик безопасности и запрета на доступ в Интернет

Но интересно, это ведь такая же штука получится, как с символами Windows, которые студия складывает в %TEMP\SymbolCache ? Тогда непонятна разница между поставкой в дистрибутиве и загрузкой по сети.
И даже если софт не будет сохранять их локально, всё равно есть возможность их перехватить. Если я правильно понимаю, там ведь обычные PDB пересылаются, такие же как из-под линковщика вышли.

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

A>>Хотелось бы поставлять отладочную информацию с релизными билдами, чтобы в трассировке стека были более осмысленные координаты.
R>Они не будут осмысленными. Внешние компоненты все испортят, тот же С++ рантайм — для него вы тоже будете пдб-шники распространять? А user32 — через него идут почти все гуевые вызовы
Ладно, внутренности ОС так уж и быть, я переживу и понадеюсь, что ОС практически стабильна А вот отладочная информация рантайма, ЕМНИП, также складывается в получаемый .PDB (рантайм линкуется статически)

Здравствуйте, Мишень-сан, Вы писали:

МС>Мне кажется, это взаимоисключающие параграфы
Не совсем так, уважаемый любитель фольклора.
Если при перетряхивании символов производить замены осмысленного на неосмысленное с сохранением этого сопоставления в отдельный файлик, то потом им же можно воспользоваться для определения что за метод скрывается за "up8p6N".

МС>А в обфусцированной дотнет-сборке Вы на стектрейсе получите как раз те самые каракули.
А разве нет обпускаторов, которые бы сохраняли информацию о том, что на что заменилось?

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

ТКС>>Дело в том, что без полного набора pdb на x86 нет способа получить гарантированно правильный стек трейс (ну, или просто я такой способ не знаю). Хотя неполный трейс все равно лучше, чем никакой.
O>так .pdb оставляйте у себя, и получайте стек трейс из дампа. Или вы стек трейс на машине клиента получить пытаетесь? Смысл?

Ну это как минимум придется полностью сохранять стек всех интересующих нитей, т.е. пересылать несколько мегабайт. Да и операционка у клиента может оказаться другая, соответственно придется собирать информацию о всех загруженных модулях, плюс где-то брать потом pdb к ним.

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

O>так .pdb оставляйте у себя, и получайте стек трейс из дампа. Или вы стек трейс на машине клиента получить пытаетесь? Смысл?
Да, трассировка выполяется на машине клиента.
Достаточно сложно будет "уговорить" наших клиентов, чтобы они присылали нетекстовые данные.
Но спасибо, что пытаетесь решить вопрос в топике другим способом

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

A>>>Хотелось бы поставлять отладочную информацию с релизными билдами, чтобы в трассировке стека были более осмысленные координаты.
R>>Они не будут осмысленными. Внешние компоненты все испортят, тот же С++ рантайм — для него вы тоже будете пдб-шники распространять? А user32 — через него идут почти все гуевые вызовы
A>Ладно, внутренности ОС так уж и быть, я переживу и понадеюсь, что ОС практически стабильна

Это не очень важно в данном случае — стабильна ОС или нет. В GUI коде возникает полно ситуаций, когда прикладной код многократно перемежается с user32, а падает все потом где-нибудь в EnterCriticalSection из-за неправильных параметров.

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

ТКС>Ключик /PDBSTRIPPED чем-то не устраивает?
Спасибо, прозевал его. Правда, судя по описанию, похоже, что не совсем то. Ведь "only contain public symbols" это значит информация о protected/private методах классов вырежется?

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

A>Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>>Ключик /PDBSTRIPPED чем-то не устраивает?
A>Спасибо, прозевал его. Правда, судя по описанию, похоже, что не совсем то. Ведь "only contain public symbols" это значит информация о protected/private методах классов вырежется?

By default, stripped PDB files contain the following information:

Public symbols (typically only non-static functions and global variables)

A list of object files that are responsible for sections of code in the executable

Frame pointer optimization information (FPO)

ТКС>>>Дело в том, что без полного набора pdb на x86 нет способа получить гарантированно правильный стек трейс (ну, или просто я такой способ не знаю). Хотя неполный трейс все равно лучше, чем никакой.
O>>так .pdb оставляйте у себя, и получайте стек трейс из дампа. Или вы стек трейс на машине клиента получить пытаетесь? Смысл?

ТКС>Ну это как минимум придется полностью сохранять стек всех интересующих нитей, т.е. пересылать несколько мегабайт.
Типичный размер минидампа — меньше 100кб.

ТКС>Да и операционка у клиента может оказаться другая, соответственно придется собирать информацию о всех загруженных модулях, плюс где-то брать потом pdb к ним.
В "другой" операционке нету .pdb .pdb есть только в тех операционках где есть miniDumpWriteDump

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

ТКС>>>>Дело в том, что без полного набора pdb на x86 нет способа получить гарантированно правильный стек трейс (ну, или просто я такой способ не знаю). Хотя неполный трейс все равно лучше, чем никакой.
O>>>так .pdb оставляйте у себя, и получайте стек трейс из дампа. Или вы стек трейс на машине клиента получить пытаетесь? Смысл?

ТКС>>Ну это как минимум придется полностью сохранять стек всех интересующих нитей, т.е. пересылать несколько мегабайт.
O>Типичный размер минидампа — меньше 100кб.

Либо ты сохраняешь весь использованный стек (который иногда действительно может в 100 кило уложиться), либо у тебя есть pdb, содержащая FPO, либо у тебя в трейсе будут пропущены часть вызовов (после функций, скомпилированных без кадра стека). По другому — никак. Или я чего-то упустил?

ТКС>>Да и операционка у клиента может оказаться другая, соответственно придется собирать информацию о всех загруженных модулях, плюс где-то брать потом pdb к ним.
O>В "другой" операционке нету .pdb .pdb есть только в тех операционках где есть miniDumpWriteDump

Эээ — ну вот у меня скажем 32 бит виста установлена, а у клиента XP 64-бит. Как мне поможет тот факт, что у него на машине работает miniDumpWriteDump?

ТКС>>>Ну это как минимум придется полностью сохранять стек всех интересующих нитей, т.е. пересылать несколько мегабайт.
O>>Типичный размер минидампа — меньше 100кб.
ТКС>Либо ты сохраняешь весь использованный стек (который иногда действительно может в 100 кило уложиться), либо у тебя есть pdb, содержащая FPO, либо у тебя в трейсе будут пропущены часть вызовов (после функций, скомпилированных без кадра стека). По другому — никак. Или я чего-то упустил?
Именно так. Редко когда стек используется хотябы на половину, в противном случае скорее всего увидим глубокую рекурсию с переполнением в конце. А минидампы с рекурсией отлично жмутся зипом, хотя и без рекурсии минидампы тоже замечательно жмутся.

ТКС>>>Да и операционка у клиента может оказаться другая, соответственно придется собирать информацию о всех загруженных модулях, плюс где-то брать потом pdb к ним.
O>>В "другой" операционке нету .pdb .pdb есть только в тех операционках где есть miniDumpWriteDump
ТКС>Эээ — ну вот у меня скажем 32 бит виста установлена, а у клиента XP 64-бит. Как мне поможет тот факт, что у него на машине работает miniDumpWriteDump?
Получите дамп и откроете его. 32хбитный windbg (адекватной свежести) прекрасно понимает дампы с 64хбитной винды.

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

ТКС>>>>Ну это как минимум придется полностью сохранять стек всех интересующих нитей, т.е. пересылать несколько мегабайт.
O>>>Типичный размер минидампа — меньше 100кб.
ТКС>>Либо ты сохраняешь весь использованный стек (который иногда действительно может в 100 кило уложиться), либо у тебя есть pdb, содержащая FPO, либо у тебя в трейсе будут пропущены часть вызовов (после функций, скомпилированных без кадра стека). По другому — никак. Или я чего-то упустил?
O>Именно так. Редко когда стек используется хотябы на половину, в противном случае скорее всего увидим глубокую рекурсию с переполнением в конце. А минидампы с рекурсией отлично жмутся зипом, хотя и без рекурсии минидампы тоже замечательно жмутся.

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

ТКС>>>>Да и операционка у клиента может оказаться другая, соответственно придется собирать информацию о всех загруженных модулях, плюс где-то брать потом pdb к ним.
O>>>В "другой" операционке нету .pdb .pdb есть только в тех операционках где есть miniDumpWriteDump
ТКС>>Эээ — ну вот у меня скажем 32 бит виста установлена, а у клиента XP 64-бит. Как мне поможет тот факт, что у него на машине работает miniDumpWriteDump?
O>Получите дамп и откроете его. 32хбитный windbg (адекватной свежести) прекрасно понимает дампы с 64хбитной винды.

pdb от нужной винды оно само выкачает?

ТКС>>>Либо ты сохраняешь весь использованный стек (который иногда действительно может в 100 кило уложиться), либо у тебя есть pdb, содержащая FPO, либо у тебя в трейсе будут пропущены часть вызовов (после функций, скомпилированных без кадра стека). По другому — никак. Или я чего-то упустил?
O>>Именно так. Редко когда стек используется хотябы на половину, в противном случае скорее всего увидим глубокую рекурсию с переполнением в конце. А минидампы с рекурсией отлично жмутся зипом, хотя и без рекурсии минидампы тоже замечательно жмутся.
ТКС>Ну тут еще и ниток легко может с десяток оказаться, да и не все настолько доверяют поставщикам софта, чтобы разрешать слать хотя бы сотни килобайт непонятно чего.
Из моей практики у приложений с десятком ниток в минидампы получаются крайне мизерные в зипах. А вопрос доверия в несколько иной сфере лежит.


O>>>>В "другой" операционке нету .pdb .pdb есть только в тех операционках где есть miniDumpWriteDump
ТКС>>>Эээ — ну вот у меня скажем 32 бит виста установлена, а у клиента XP 64-бит. Как мне поможет тот факт, что у него на машине работает miniDumpWriteDump?
O>>Получите дамп и откроете его. 32хбитный windbg (адекватной свежести) прекрасно понимает дампы с 64хбитной винды.
ТКС>pdb от нужной винды оно само выкачает?
В смысле .pdb виндовые? да конечно, если настроить

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

ТКС>>>>Либо ты сохраняешь весь использованный стек (который иногда действительно может в 100 кило уложиться), либо у тебя есть pdb, содержащая FPO, либо у тебя в трейсе будут пропущены часть вызовов (после функций, скомпилированных без кадра стека). По другому — никак. Или я чего-то упустил?
O>>>Именно так. Редко когда стек используется хотябы на половину, в противном случае скорее всего увидим глубокую рекурсию с переполнением в конце. А минидампы с рекурсией отлично жмутся зипом, хотя и без рекурсии минидампы тоже замечательно жмутся.
ТКС>>Ну тут еще и ниток легко может с десяток оказаться, да и не все настолько доверяют поставщикам софта, чтобы разрешать слать хотя бы сотни килобайт непонятно чего.
O>Из моей практики у приложений с десятком ниток в минидампы получаются крайне мизерные в зипах.

А стек при этом для всех ниток дампили при этом или только у упавшей?

O>А вопрос доверия в несколько иной сфере лежит.

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

O>>>>>В "другой" операционке нету .pdb .pdb есть только в тех операционках где есть miniDumpWriteDump
ТКС>>>>Эээ — ну вот у меня скажем 32 бит виста установлена, а у клиента XP 64-бит. Как мне поможет тот факт, что у него на машине работает miniDumpWriteDump?
O>>>Получите дамп и откроете его. 32хбитный windbg (адекватной свежести) прекрасно понимает дампы с 64хбитной винды.
ТКС>>pdb от нужной винды оно само выкачает?
O>В смысле .pdb виндовые? да конечно, если настроить

Да, виндовые .pdb. Но от другой версии винды. windbg так умеет?

ТКС>>>Ну тут еще и ниток легко может с десяток оказаться, да и не все настолько доверяют поставщикам софта, чтобы разрешать слать хотя бы сотни килобайт непонятно чего.
O>>Из моей практики у приложений с десятком ниток в минидампы получаются крайне мизерные в зипах.
ТКС>А стек при этом для всех ниток дампили при этом или только у упавшей?
У всех. Да возьмите сами попробуйте — в windbg атачитесь к процессу, потом — команда

.dump c:\dump.dmp

после чего открываем получившийся дамп , и пишем в windbg последовательно:

.symfix
.reload
~*kv ffff

и любуемся стеками. Потом смотрим размер дамп файла и много думаем на тему "нафига городить парсинг стека на клиенте". + курим хелп по miniDumpWriteDump (и почти аналогичный хелп по команде .dump в виндбг)


O>>А вопрос доверия в несколько иной сфере лежит.
ТКС>Ну мы вот с таким проблемным клиентом просто показывали, что конкретно дампим. Когда имеется возможность проверить, и уверенность, что ничего существенного среди этих данных не спрятать, доверяют существенно легче.
ну мона показать hex/ascii view

O>>>>Получите дамп и откроете его. 32хбитный windbg (адекватной свежести) прекрасно понимает дампы с 64хбитной винды.
ТКС>>>pdb от нужной винды оно само выкачает?
O>>В смысле .pdb виндовые? да конечно, если настроить
ТКС>Да, виндовые .pdb. Но от другой версии винды. windbg так умеет?
Конечно

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

ТКС>>>>Ну тут еще и ниток легко может с десяток оказаться, да и не все настолько доверяют поставщикам софта, чтобы разрешать слать хотя бы сотни килобайт непонятно чего.
O>>>Из моей практики у приложений с десятком ниток в минидампы получаются крайне мизерные в зипах.
ТКС>>А стек при этом для всех ниток дампили при этом или только у упавшей?
O>У всех. Да возьмите сами попробуйте — в windbg атачитесь к процессу, потом — команда
O>

O>.dump c:\dump.dmp

O>после чего открываем получившийся дамп , и пишем в windbg последовательно:
O>

O>.symfix
O>.reload
O>~*kv ffff

O>и любуемся стеками. Потом смотрим размер дамп файла и много думаем на тему "нафига городить парсинг стека на клиенте". + курим хелп по miniDumpWriteDump (и почти аналогичный хелп по команде .dump в виндбг)

У меня ситуация несколько другая — все уже 10 лет назад сгорожено. Есть ряд причин чтобы переделать, и разумеется есть куча более срочных задач. Поэтому предпочитаю сначала расспросить, насколько возможно. В хелпе к MiniDumpWriteDump я не понял, что именно будет собрано об остальных нитях, если не использовать коллбэки, поэтому и уточняю.

O>>>А вопрос доверия в несколько иной сфере лежит.
ТКС>>Ну мы вот с таким проблемным клиентом просто показывали, что конкретно дампим. Когда имеется возможность проверить, и уверенность, что ничего существенного среди этих данных не спрятать, доверяют существенно легче.
O>ну мона показать hex/ascii view

Но в принципе для таких случаев можно и старым кодом пользоваться.

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

A>Здравствуйте!

A>Подскажите, можно ли как-то запутать символы в PDB?

скорее всего нет — это закрытый формат

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

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

B>>Есть! Поднять у се6я symbol server и хранить пдбхи в нем.

A>Есть много противопоказаний у сервера — от стоимости трафика и скорости соединения, до корпоративных политик безопасности и запрета на доступ в Интернет

A>Но интересно, это ведь такая же штука получится, как с символами Windows, которые студия складывает в %TEMP\SymbolCache ? Тогда непонятна разница между поставкой в дистрибутиве и загрузкой по сети.
A>И даже если софт не будет сохранять их локально, всё равно есть возможность их перехватить. Если я правильно понимаю, там ведь обычные PDB пересылаются, такие же как из-под линковщика вышли.

Причем тут скорость трафика и корпоративные политики? Ты поднимаешь символ сервер у себя в офисе, на одном из компов, с доступом только во локальную сеть и настраиваешь студию на работу с символ сервером. Настраиваешь билдовый сервер (если есть) чтобы пдб-хи от каждого релизного билда он хранил на символ сервере. Далее когда тебе присылают крэшдамп, ты просто открываешь его в своей студии. Если надо дебужить у заказчика, то поднимаешь символ сервер на ноуте со студией и дебужишь.
З.Ы. Символ сервер это просто расшаренный каталог со специальной структурой, там нету ни каких постоянно работающих служб.

ТКС>У меня ситуация несколько другая — все уже 10 лет назад сгорожено. Есть ряд причин чтобы переделать, и разумеется есть куча более срочных задач. Поэтому предпочитаю сначала расспросить, насколько возможно. В хелпе к MiniDumpWriteDump я не понял, что именно будет собрано об остальных нитях, если не использовать коллбэки, поэтому и уточняю.
Бай дефолт там все правильно делается — дампятся стеки всех потоков

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

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

B>>Далее когда тебе присылают крэшдамп, ты просто открываешь его в своей студии.
A>Оно-то всё конечно так, но проблема в том, что crashdump не подходит Не разрешат мне такое прикрутить.
A>Такой объем непонятных данных юзеры не отдадут — а вдруг там пороли или еще какая-то до жути личная информация.
A>Поэтому и ищу способы преобразовать на месте стек в нечто понимабельное

Прикрутите вместо крэшдампа BugTrap который при отсутствии PDB сгенерит вам XML с простыми hex адресами. А вы уже на своей машине с PDB увидите осмысленные имена функций в стеке вызова. Уж XML с хекс-адресами юзеры отдадут наружу?

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

A>Может у кого-нибудь есть рецептик?
Можно сами исходники обфускатором обработать...