Здравствуйте, 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 не показываются тела его конструкторов, методов и т.д. и ума не приложу как это обойти