Потихоньку пишем виртуализацию CIL. Пример того что было и что стало можно скачать здесь.

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

V> Потихоньку пишем виртуализацию CIL. Пример того что было и что стало можно скачать здесь.

Виртуализированный модуль падает на восьмерке.

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

R>Виртуализированный модуль падает на восьмерке.

Какой у вас там Framework?

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

V> Какой у вас там Framework?

4.5.1, Win 8.1 x64

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

V>Потихоньку пишем виртуализацию CIL. Пример того что было и что стало можно скачать здесь.

Windows Defender негодуэ

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

V>Потихоньку пишем виртуализацию CIL.
А можно в паре слов рассказать — что это и чем полезно?

Здравствуйте, Михаил Романов, Вы писали:

V>>Потихоньку пишем виртуализацию CIL.
МР>А можно в паре слов рассказать — что это и чем полезно?

Виртуализация — преобразование исходного кода в команды виртуальной машины. После этого исходный код выполняется виртуальной машиной и получить исходный код очень проблематично.

Например было:

private void btnCheckPassword_Click(object sender, EventArgs e)
{
    string s;
    if (this.CheckPassword(this.txtPassword.Text))
    {
        s = SDK.DecryptString("Correct password");
        MessageBox.Show(s, string.Format(SDK.DecryptString("Password check {0}"), a), MessageBoxButtons.OK, MessageBoxIcon.Asterisk);
        SDK.FreeString(ref s);
        return;
    }
    s = SDK.DecryptString("Incorrect password");
    MessageBox.Show(s, string.Format(SDK.DecryptString("Password check {0}"), a), MessageBoxButtons.OK, MessageBoxIcon.Hand);
    SDK.FreeString(ref s);
    this.txtPassword.Focus();
}

Стало:

private void btnCheckPassword_Click(object sender, EventArgs e)
{
    object[] args = new object[]
    {
        this,
        sender,
        e
    };
    new VirtualMachine().Invoke(args, 97242);
}

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

V>Виртуализация — преобразование исходного кода в команды виртуальной машины. После этого исходный код выполняется виртуальной машиной и получить исходный код очень проблематично.
V>Например было:
V>Стало:

Спасибо за ответ.
Однако у меня всё равно не сложилось до конца картинка...

Как я понимаю, преобразование (если мы говорим о .Net/IL) идет всё же не для исходного кода, а для уже скомпилированного (IL) кода. Т.е. вместо выполнения исходного IL-кода будет идти вызов некоего вашего интерпретатора (или всё же не интерпретатора, а скомпилированного/копилируемого на ходу кода?), который исполняет свой собственный байт-код, полученный из исходного IL.
Так?

И если я правильно понял схему, то объясните, пожалуйста, почему восстановить байт код для вашей виртуальной машины будет сложнее, чем для исходного IL? Она обладает какими-то специальными, мешающими декомпиляции, особенностями? Или рассчет строится на том, что формат вашего байт-кода (в отличие от хорошо описанного IL) нигде не специфицирован?

Или я вообще всё понял неверно?

P.S. Ну и несколько филосовский (или делитантский) вопрос: основная цель механизма виртуализации — это предотвратить восстановление алгоритма, при наличии доступа к готовому исполнимому модулю, а на сколько это востребовано в мире .Net?
Возможно у меня искаженная картина, т.к. я работаю в enterprise разработке, где в этом нет особой необходимости, и за всё время мне даже просто обфусцированный код попадался не то 1, не то 2 раза.

Здравствуйте, Михаил Романов, Вы писали:

МР>Как я понимаю, преобразование (если мы говорим о .Net/IL) идет всё же не для исходного кода, а для уже скомпилированного (IL) кода. Т.е. вместо выполнения исходного IL-кода будет идти вызов некоего вашего интерпретатора (или всё же не интерпретатора, а скомпилированного/копилируемого на ходу кода?), который исполняет свой собственный байт-код, полученный из исходного IL.
МР>Так?

Михаил, когда мы говорим про IL, то мы говорим про результат работы компилятора, который из C# сделал IL. Поверьте, что сделать исходный исходник из IL не составляет никакого труда — достаточно просто загрузить вашу программу в инструмент типа dnSpy. Что такое компилируемый на лету код я так и не понял — это уже целевые команды процессора? Если да, то мы туда не лезем.

МР>И если я правильно понял схему, то объясните, пожалуйста, почему восстановить байт код для вашей виртуальной машины будет сложнее, чем для исходного IL? Она обладает какими-то МР>специальными, мешающими декомпиляции, особенностями? Или рассчет строится на том, что формат вашего байт-кода (в отличие от хорошо описанного IL) нигде не специфицирован?

Задача как обычно сводится к написанию декомпилятора, который будет преобразовывать пикод одной виртуальной машины в пикод другой. Естественно структура нашей ВМ нигде не специфицирована и ее архитектура можно сильно отличаться от начальной (например в явном виде в нашей ВМ отсутствуют условные переходы).

МР>Или я вообще всё понял неверно?

Пока не знаю

МР>P.S. Ну и несколько филосовский (или делитантский) вопрос: основная цель механизма виртуализации — это предотвратить восстановление алгоритма, при наличии доступа к готовому исполнимому модулю, а на сколько это востребовано в мире .Net?

Вы занимаетесь разработкой шароварных проектов на C#, которые можно взломать с помощью патчинга всего одно байта?

МР>Возможно у меня искаженная картина, т.к. я работаю в enterprise разработке, где в этом нет особой необходимости, и за всё время мне даже просто обфусцированный код попадался не то 1, не то 2 раза.

Обфусцированный код это как правило не защита, а фейк — если изменить название классов и методов, то целевую программу можно взломать, но немножко дольше. Про защиту ноу-хау я при этом вообще молчу. У меня есть один достаточно большой чужой проект, который был восстановлен до компилируемого состояния, хотя в нем применялось много чего. Единственная проблема — это выбрать новые названия для классов и методов

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

V>Михаил, когда мы говорим про IL, то мы говорим про результат работы компилятора, который из C# сделал IL. Поверьте, что сделать исходный исходник из IL не составляет никакого труда — достаточно просто загрузить вашу программу в инструмент типа dnSpy.
Это я понимаю.
Но мне бы хотелось понять схему работы вашего инструмента.

Т.е. правильно ли я понимаю, что она такова:
1. Исходный код (например, C#) компилируется в обычную IL сборку.
2. Ваш инструмент проходит по этой сборке и:
2.1. На основе IL кода методов генерирует байт-код для вашей виртуальной машины
2.2. Заменяет исходный методов на IL на обращения к вашей виртуальной машине.
3. В процессе выполнения программы ваша ВМ интерпретирует сохраненный в 2.1. байт-код.

Верно?

V>Что такое компилируемый на лету код я так и не понял — это уже целевые команды процессора? Если да, то мы туда не лезем.
Да, когда вы сказали, что "исходный код выполняется виртуальной машиной" я первым делом подумал, что вы просто не стали усложнять описание, а в реальности у вас идет что-то вроде JIT-компиляции.
Но вы говорите, что это не так.

V>Задача как обычно сводится к написанию декомпилятора, который будет преобразовывать пикод одной виртуальной машины в пикод другой. Естественно структура нашей ВМ нигде не специфицирована и ее архитектура можно сильно отличаться от начальной (например в явном виде в нашей ВМ отсутствуют условные переходы).
Т.е. основной упор делается на security by obscurity, т.е. на закрытость спецификации вашей ВМ?

V>Вы занимаетесь разработкой шароварных проектов на C#, которые можно взломать с помощью патчинга всего одно байта?
Нет. Моя специализация — заказной enterprise, а там shareware не используются, т.к. или вся разработка под заказ с 0, или кастомизация готового продукта, но тоже под заказчика.
Но я спрашиваю потому, что в принципе не слышал про shareware на .Net (опять же, возможно, в силу своей специфики) — вот и стало интересно на сколько это большой рынок.

Здравствуйте, Михаил Романов, Вы писали:

МР>Т.е. правильно ли я понимаю, что она такова:
МР>1. Исходный код (например, C#) компилируется в обычную IL сборку.
МР>2. Ваш инструмент проходит по этой сборке и:
МР>2.1. На основе IL кода методов генерирует байт-код для вашей виртуальной машины
МР>2.2. Заменяет исходный методов на IL на обращения к вашей виртуальной машине.
МР>3. В процессе выполнения программы ваша ВМ интерпретирует сохраненный в 2.1. байт-код.
МР>Верно?

Да, в целом верно. Единственный момент — вы сами выбираете методы (с помощью маркеров или в GUI протектора), которые нужно обфусцировать.

V>>Задача как обычно сводится к написанию декомпилятора, который будет преобразовывать пикод одной виртуальной машины в пикод другой. Естественно структура нашей ВМ нигде не специфицирована и ее архитектура можно сильно отличаться от начальной (например в явном виде в нашей ВМ отсутствуют условные переходы).
МР>Т.е. основной упор делается на security by obscurity, т.е. на закрытость спецификации вашей ВМ?

В первую очередь — да. Помимо виртуализации мы предлагаем еще кучу готовых плюшек в виде SDK.

V>>Вы занимаетесь разработкой шароварных проектов на C#, которые можно взломать с помощью патчинга всего одно байта?
МР>Нет. Моя специализация — заказной enterprise, а там shareware не используются, т.к. или вся разработка под заказ с 0, или кастомизация готового продукта, но тоже под заказчика.
МР>Но я спрашиваю потому, что в принципе не слышал про shareware на .Net (опять же, возможно, в силу своей специфики) — вот и стало интересно на сколько это большой рынок.

Скрывать от конкуретнов ноу-хау еще пока не приходилось?

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

V>Да, в целом верно. Единственный момент — вы сами выбираете методы (с помощью маркеров или в GUI протектора), которые нужно обфусцировать.
Ясно.
Спасибо за разъяснение!

V>В первую очередь — да. Помимо виртуализации мы предлагаем еще кучу готовых плюшек в виде SDK.
Как я понимаю это задачи из разряда проверки лицензионного ключа и аналогичных?

V>Скрывать от конкуретнов ноу-хау еще пока не приходилось?
Какие могут быть ноу-хау в enterprise?
Ну а если серьезно, то в заказной разработке в подовляющем большинстве случаев речь будет идти, или о внутренней автоматизации (а там от утечек защищаются иными методами), или о внешних продуктах, в которых нет каких-то закрытых технологий или алгоритмов.
Вещи, содержащие какие-то серьезные закрытые наработки на аутсорс уходят редко.

Здравствуйте, Михаил Романов, Вы писали:

V>>В первую очередь — да. Помимо виртуализации мы предлагаем еще кучу готовых плюшек в виде SDK.
МР>Как я понимаю это задачи из разряда проверки лицензионного ключа и аналогичных?

Да там много всего: задачи лицензирования, онлайн активации, убирание строковых констант из метаданных, проверка целостности файла на диске и в памяти, неявные проверки случайных кусков памяти и использование результатов таких проверок при исполнении завиртуализированного кода, упаковка файла (при просмотре файла IL декомпиляторами тела методов выглядит совершенно пустыми, т.е. имейдж нужно сдампить во время работы чтобы скормить его декомпилятору).