А что получается через ILDasm можно посмотреть весь управляемый код? Т.е. написать декомпилятор для конктетного dotNET-языка (вроде Jad для Java) — раз плюнуть? Т.е. управляемый код совершенно незащищен?

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

N>А что получается через ILDasm можно посмотреть весь управляемый код? Т.е. написать декомпилятор для конктетного dotNET-языка (вроде Jad для Java) — раз плюнуть? Т.е. управляемый код совершенно незащищен?

Есть такой момент...
Но есть и такие весчи, как обфускаторы.
Подробнее
здесь
здесь
здесь

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

N>А что получается через ILDasm можно посмотреть весь управляемый код?

Ага, на ILAsm

N>Т.е. написать декомпилятор для конктетного dotNET-языка (вроде Jad для Java) — раз плюнуть?

Ну это вряд ли.

N>Т.е. управляемый код совершенно незащищен?

Что ты понимаешь под защищенностью?

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

AVK>Ага, на ILAsm

точно
N>>Т.е. написать декомпилятор для конктетного dotNET-языка (вроде Jad для Java) — раз плюнуть?

AVK>Ну это вряд ли.
Раз-не раз но во-много раз проще чем для нативных I86 кодов — по крайней мере сам IL этому оччень способствует

N>>Т.е. управляемый код совершенно незащищен?

AVK>Что ты понимаешь под защищенностью?

Наверное имеется в виду всякие там Copy rights для алогритмов хитрых

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

AVK>Ну это вряд ли.
M>Раз-не раз но во-много раз проще чем для нативных I86 кодов — по крайней мере сам IL этому оччень способствует

Насчет во много раз я бы не стал утверждать. Несколько попроще возможно. Трудность восстановления исходных кодов больше определяется компилятором. К примеру исходный код дельфевого модуля восстановить вполне реально, несмотря на то что он скомпилирован в x86, а вот код на МС++ с включенной оптимизацией для того же IL восстановить автоматически не так то просто. Хотя конечно наличие метаданных в исполняемых файлах простоте декомпиляции способствует.

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

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

AVK>>Ага, на ILAsm

M>точно

он вроде ILDasm называется, или я что-то путаю? Я имел в виду шнягу для просмотра сборок, которая входит в VS.NET.

N>>>Т.е. написать декомпилятор для конктетного dotNET-языка (вроде Jad для Java) — раз плюнуть?

AVK>>Ну это вряд ли.
M>Раз-не раз но во-много раз проще чем для нативных I86 кодов — по крайней мере сам IL этому оччень способствует
Ну вот, и я не вижу особых сложностей декомпиляции

N>>>Т.е. управляемый код совершенно незащищен?

AVK>>Что ты понимаешь под защищенностью?

M>Наверное имеется в виду всякие там Copy rights для алогритмов хитрых
M>

Ага, именно это.

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

Что из исходного кода не сохраняется в метаданных? Во-первых, естественно, не сохраняется сам код (он превращается в ILASM), но его достаточно легко восстановить. Во-вторых, не сохраняются имена локальных переменных функций (здесь уже никуда не деться, придётся придумывать самому). В-третьих, напрочь теряются комментарии. Ну, а им-то уж теряться положено по статусу. Имена типов, их организация и так далее — всё это есть в метаданных. Отсюда мораль — если использовать ТОЛЬКО изменения имён, то в любом случае восстановить мысль автора программы будет намного проще, чем, скажем, в native-коде. Говорят, правда, что Salamander какие-то хитрые вещи выделывает, но я, к сожалению, его не видел.
Отсюда мораль — если важно не показать какие-то алгоритмы, присутствующие в программе, то лучше всё же использовать какие-то специальные (в т.ч и сделанные специалистами по защите, а не самопальные) средства внутри программы, а не помещать всё в код в голом виде. А если код к тому же и управляемый...
С другой стороны, насколько дороги эти алгоритмы? Будет ли кто-то хотя бы пытаться понять, как работает программа? Она действительно уникальна в своём роде? Никто не знает даже подходов к решению задач? Если так, то стоит, наверное, потратиться на действительно хороший обфускатор. Если нет, то имеет ли вообще смысл огород городить с защитой?

С уважением,

OldDino

N>А что получается через ILDasm можно посмотреть весь управляемый код? Т.е. написать декомпилятор для конктетного dotNET-языка (вроде Jad для Java) — раз плюнуть? Т.е. управляемый код совершенно незащищен?

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

AVK>Насчет во много раз я бы не стал утверждать. Несколько попроще возможно. Трудность восстановления исходных кодов больше определяется компилятором. К примеру исходный код дельфевого модуля восстановить вполне реально, несмотря на то что он скомпилирован в x86, а вот код на МС++ с включенной оптимизацией для того же IL восстановить автоматически не так то просто. Хотя конечно наличие метаданных в исполняемых файлах простоте декомпиляции способствует.

Фигню говоришь. Оптимизации в Дельфи ничем не хуже (код корежет дай дорогу). А вот востановить с машинного кода что-либо очень трудно. А с мсил-а как раз влет. Та же Анакрина востанавливает оптимизированный мсил влет. Он скоре спотыкается на нестандартные расширения МС++ которые дотупны и без оптимизации.

Есть такая вещь, называется Salamander .NET Decompiler

Я чуть в обморок не упал, когда увидел исходники моей программы, причем код был лучше отформатирован, чем оригинал

Если кого то интересует, это здесь
(Предупреждаю:не для слабонервных)

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

4>Есть такая вещь, называется Salamander .NET Decompiler

4>Я чуть в обморок не упал, когда увидел исходники моей программы, причем код был лучше отформатирован, чем оригинал

4>Если кого то интересует, это здесь
4>(Предупреждаю:не для слабонервных)

Ха-ха, а я увидел следуещее, попробовав свои коммерческие сборки:
Слева A, B, C...
Справа This assembly is protected by Remotesoft .NET Obfuscator, decompiling aborted.

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

MMP>Здравствуйте, 4mbi3nt, Вы писали:

4>>Есть такая вещь, называется Salamander .NET Decompiler

4>>Я чуть в обморок не упал, когда увидел исходники моей программы, причем код был лучше отформатирован, чем оригинал

4>>Если кого то интересует, это здесь
4>>(Предупреждаю:не для слабонервных)

MMP>Ха-ха, а я увидел следуещее, попробовав свои коммерческие сборки:
MMP>Слева A, B, C...
MMP>Справа This assembly is protected by Remotesoft .NET Obfuscator, decompiling aborted.
MMP>)

По какому принципу работают обфускаторы? И почему MS не включает их в состав NET SDK?

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

N>По какому принципу работают обфускаторы? И почему MS не включает их в состав NET SDK?

Я ж давал тебе ссылки на статьи
И вроде в SDK'е есть какой-то (точно не помню какой)

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

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

N>>А что получается через ILDasm можно посмотреть весь управляемый код? Т.е. написать декомпилятор для конктетного dotNET-языка (вроде Jad для Java) — раз плюнуть? Т.е. управляемый код совершенно незащищен?

D_S>Есть такой момент...
D_S>Но есть и такие весчи, как обфускаторы.

Хмм ... а что значит вот такая галочка на страничке саламандры ?

de-obfuscate(turn any obfuscated code into recompilable format)

С Уважением, Andir!

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

N>По какому принципу работают обфускаторы? И почему MS не включает их в состав NET SDK?

Работает, насколько я помню, в основном изменяя названия функций и переменных на нечто неудобоваримое.

Есть обфускатор в составе VS 2003. Никто не пробовал, как оно?

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

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

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

N>>>А что получается через ILDasm можно посмотреть весь управляемый код? Т.е. написать декомпилятор для конктетного dotNET-языка (вроде Jad для Java) — раз плюнуть? Т.е. управляемый код совершенно незащищен?

D_S>>Есть такой момент...
D_S>>Но есть и такие весчи, как обфускаторы.

A>Хмм ... а что значит вот такая галочка на страничке саламандры ?
A>

de-obfuscate(turn any obfuscated code into recompilable format)

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

A>Хмм ... а что значит вот такая галочка на страничке саламандры ?
A>

de-obfuscate(turn any obfuscated code into recompilable format)

Кстати с точки зрения декомпиляции эта байда (в смысле обфускация имен) усложняет жизнь совершенно не на много — просто при разыменовании токена за именем не в CIL таблицу лезеш — а в свою динамически построенную Ж-)

A>>Хмм ... а что значит вот такая галочка на страничке саламандры ?
A>>

de-obfuscate(turn any obfuscated code into recompilable format)

Ну свой обфускатор они не подставляют — в нем есть спечиальная опция, типа, запретить саламандеру декомпилировать сборку.

А на деле, и до обфускации _хрен разберешься_ в сложном/большом проекте (и декомпиляторы не помогут), так что обфускаторы скорее мешают декомпилировать-изменить-закомпилировать сборку, + использовать сбоку на стороне, а не в составе продукта.

А вот еще вопрос. Вы думаете MS будет выпускать свои продукты под dotNET

Они же фактически станут OpenSource

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

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

N>А вот еще вопрос. Вы думаете MS будет выпускать свои продукты под dotNET

А сам дотнет или куски студии это не продукт что ли?

N>Они же фактически станут OpenSource

Ну и что? MS вобще то никогда не отличался особой страстью к защитам, за исключением разве что активации.

N>Не значит ли это, что неуправляемый код будет жить еще очень долго если не всегда

Естественно в определенных областях обычный нативный код будет еще очень долго, по крайней мере до тех пор пока процессоры не научаться выполнять напрямую IL.

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

N>>Не значит ли это, что неуправляемый код будет жить еще очень долго если не всегда

AVK>Естественно в определенных областях обычный нативный код будет еще очень долго, по крайней мере до тех пор пока процессоры не научаться выполнять напрямую IL.

Скорее, проблема в GC. IL замечательно JIT-уется.

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

4>Если кого то интересует, это здесь
4>(Предупреждаю:не для слабонервных)

Причем тут .NET Decompiler? Мы говорили о Дельфи. К тому же если код после декомпайлера лучше читается, чем оригинал, то в самое время задуматся о стиле и качестве кодирования.

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

Кстати, на счет качества работы этого чуда. Подсунул вот одну из своих сборок и вот что он выдал в одно из методов:

        protected unsafe void ReadStream(STORAGESTREAM* pStorStream, int pMetadataBegin)
        {
            if (lstrlenA(pStorStream + 0) < 2)
            {
                wsprintfA(&$ArrayType$0x7692bedb2, "Incorrect stream name (%s).", pStorStream + 0);
                throw new ApplicationException(new String(&$ArrayType$0x7692bedb2));
            }
            int i = *(pStorStream + 0);
            switch (45)
            {
            case 0:
            case 81:
                m_pTblsStream = pMetadataBegin + *pStorStream;
                break;

            case 38:
                m_szStrings = pMetadataBegin + *pStorStream;
                break;

            case 21:
                m_pBlobs = pMetadataBegin + *pStorStream;
                break;

            case 26:
                m_pGuids = pMetadataBegin + *pStorStream;
                break;

            case 40:
                break;

            default:
                wsprintfA(&$ArrayType$0x7692bedb1, "Incorrect stream name (%s).", pStorStream + 0);
                throw new ApplicationException(new String(&$ArrayType$0x7692bedb1));
            }
        }

Бред выделен жирным.

Но все равно куда лучше чем Анакрина.

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

MMP>Ну свой обфускатор они не подставляют — в нем есть спечиальная опция, типа, запретить саламандеру декомпилировать сборку.

Ладно. Скоро мы это положение исправим.

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

N>А что получается через ILDasm можно посмотреть весь управляемый код? Т.е. написать декомпилятор для конктетного dotNET-языка (вроде Jad для Java) — раз плюнуть? Т.е. управляемый код совершенно незащищен?

В продолжение разговора об ILDASM’е, точнее, о возможности "закрытия" каким-либо образом управляемого кода.
Вчера мне совершенно случайно попался в руки обфускатор – оптимизатор (XenoCode). Ничего не могу сказать о его свойствах в сравнении с другими обфускаторами. Меня в нём заинтересовало только то, что о себе он громко заявляет, что может-де заставить ILDasm «упасть» во аремя обработки. Не более.
Посмотрел я на xc.exe (непосредственно этот обфускатор и есть), им же и обфусцированный. Что сказать? При первой попытке упало ВСЁ, кроме тупого (действительно тупого) Asmex’а – IlDasm, Reflector, DotNetExplorer. Researcher .NET тоже упал, но перед «смертью» успел показать мне смещение того DWORDа, которое его «убило». А дальше всё было делом техники… Сразу скажу, что «вскрытие» этой, с позволения сказать, защиты, заняло вместе с изменением кода, компиляцией и повторным запуском Researcher’а примерно 5-6 минут. После этого я увидел всю структуру файла. Естественно, имена, скажем, типов, были совершенно нечитабельными, например, «b2c0d7d08438eaf6». Но, скажем, зная, что этот тип наследуется от System.Windows.Forms.Form (имена из системных библиотек обфускатор изменять, естественно, не имеет права), какие выводы можно сделать? Намного ли это усложнило жизнь тому, кто хочет понять алгоритм работы программы?
Кстати, по моему мнению, анти-ILDasm’овские приёмы, используемые этой программой, крайне просты, наивны и известны, наверное, любому, кто хоть чуть-чуть знаком со структурой PE-файла. Подменить секцию, поменять указатель, вставить ложную строку в таблицу метаданных… Если кому-нибудь интересно, могу рассказать об этих приёмах подробнее.
Хорошая защита – эта такая защита, взламывать которую дороже, чем купить лицензионный продукт. А, с позволения сказать, защита, реализованная в XeonCode, рассчитана, вероятно, исключительно на «тётенек из бухгалтерии». Единственное, что мне понравилось в нём, это умение "зашифровывать" строки, определённые пользователем. Это, конечно, вызовет некоторые затруднения, но не более...
Возможно, я сужу слишком категорично, так как всё это, во-первых, происходило глубокой ночью, а, во-вторых, у меня не было цели исследовать XeonCore, я просто хотел сделать так, чтобы Researcher на этой мелочи не «падал».
С другой стороны, судя по этому XeonCode, написать «деантиилдасмер» не представляет большого труда. Обфускаторов на свете не так много, можно выяснить, что они делают (разгуляться-то им особо негде), и вперёд…

С уважением,

OldDino

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

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

N>Еще один вопрос. Если я применю обфускатор к публичной сборке, значит ее больше никто не сможет использовать?

Разумеется, не сможет. Возможно, есть "умные" обфускаторы, которые синхронно обрабатывают весь проект, к сборкам которого никто больше не обращается. Но, скажем, обрабатывать mscorlib.dll — это то же самое, что стрелять себе в голову без какой-либо надежды на то, что произойдёт осечка. Нужно ли это?

С уважением,

OldDino

N>Еще один вопрос. Если я применю обфускатор к публичной сборке, значит ее больше никто не сможет использовать?

OD>Разумеется, не сможет. Возможно, есть "умные" обфускаторы, которые синхронно обрабатывают весь проект

Можно просто не портить внешних интерфейсов. А "умные" обфускаторы, кстати, существуют.

Можно почитать об этом на сайте того обфускатора, который идёт в VS 2003, что-то вроде Preemptive Solutions, если память не изменяет. Там оба подхода присутствуют.

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

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

N>>Еще один вопрос. Если я применю обфускатор к публичной сборке, значит ее больше никто не сможет использовать?

OD>Разумеется, не сможет. Возможно, есть "умные" обфускаторы, которые синхронно обрабатывают весь проект, к сборкам которого никто больше не обращается. Но, скажем, обрабатывать mscorlib.dll — это то же самое, что стрелять себе в голову без какой-либо надежды на то, что произойдёт осечка. Нужно ли это?

Так ведь нужно! Получается что если я хочу сделать библиотеку для общего использования, то я обязательно должен показывать исходный код

Видно придется все еще использовать DCOM

OD>Хорошая защита – эта такая защита, взламывать которую дороже, чем купить лицензионный продукт. А, с позволения сказать, защита, реализованная в XeonCode, рассчитана, вероятно, исключительно на «тётенек из бухгалтерии». Единственное, что мне понравилось в нём, это умение "зашифровывать" строки, определённые пользователем. Это, конечно, вызовет некоторые затруднения, но не более...
OD>Возможно, я сужу слишком категорично, так как всё это, во-первых, происходило глубокой ночью, а, во-вторых, у меня не было цели исследовать XeonCore, я просто хотел сделать так, чтобы Researcher на этой мелочи не «падал».
OD>С другой стороны, судя по этому XeonCode, написать «деантиилдасмер» не представляет большого труда. Обфускаторов на свете не так много, можно выяснить, что они делают (разгуляться-то им особо негде), и вперёд…

Уважаемые коллеги, я проверил эту возможность и могу подтвердить — действительно, программа resercher работает так, как здесь написано. То есть помогает остановиться в том месте кода, которое модифицировано обфускатором. Я прочитал всю ветку сообщений, и из интереса поставил себе Visual Studio 2003 — сегодня буду экспериментировать с его инструмениом Dotfuscator Community Edition. Интерсно проверить это еще каким то образом, но похоже что прогамма предоставляет интересные возможности по отслеживанию действий обфускаторов.

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

N>Так ведь нужно! Получается что если я хочу сделать библиотеку для общего использования, то я обязательно должен показывать исходный код

Все серьезные библиотеки уже давно идут с исходным кодом. И никаких проблем с этим нет. Более того, многие вообще не будут использовать библиотеку если она не от МС или у нее нет исходников.

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

OD>В продолжение разговора об ILDASM’е, точнее, о возможности "закрытия" каким-либо образом управляемого кода.
OD>Вчера мне совершенно случайно попался в руки обфускатор – оптимизатор (XenoCode). Ничего не могу сказать о его свойствах в сравнении с другими обфускаторами. Меня в нём заинтересовало только то, что о себе он громко заявляет, что может-де заставить ILDasm «упасть» во аремя обработки. Не более.
OD>Посмотрел я на xc.exe (непосредственно этот обфускатор и есть), им же и обфусцированный. Что сказать? При первой попытке упало ВСЁ, кроме тупого (действительно тупого) Asmex’а – IlDasm, Reflector, DotNetExplorer. Researcher .NET тоже упал, но перед «смертью» успел показать мне смещение того DWORDа, которое его «убило». А дальше всё было делом техники… Сразу скажу, что «вскрытие» этой, с позволения сказать, защиты, заняло вместе с изменением кода, компиляцией и повторным запуском Researcher’а примерно 5-6 минут. После этого я увидел всю структуру файла. Естественно, имена, скажем, типов, были совершенно нечитабельными, например, «b2c0d7d08438eaf6». Но, скажем, зная, что этот тип наследуется от System.Windows.Forms.Form (имена из системных библиотек обфускатор изменять, естественно, не имеет права), какие выводы можно сделать? Намного ли это усложнило жизнь тому, кто хочет понять алгоритм работы программы?
OD>Кстати, по моему мнению, анти-ILDasm’овские приёмы, используемые этой программой, крайне просты, наивны и известны, наверное, любому, кто хоть чуть-чуть знаком со структурой PE-файла. Подменить секцию, поменять указатель, вставить ложную строку в таблицу метаданных… Если кому-нибудь интересно, могу рассказать об этих приёмах подробнее.

Интересно, и еще как!!! Я сечас смотрю SmartPropertyGrid http://www.visualhint.com/index.php/propertygrid/downloads дак вот в ILDasme не показываются тела его конструкторов, методов и т.д. и ума не приложу как это обойти