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

Подскажите, можно ли как-то запутать символы в 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 от нужной винды оно само выкачает?