Создает ли UWP .Net Native вместе с асинхронным программированием обфускацию?

Я читал this blog (и комментарии читателей в нем) с интересом, и он выделяет бинарную компиляцию UWP, предназначенную для повышения производительности, но в то же время играет роль в создании сложной реверсивной разработки из-за бинарной компиляции. При сложном обратном проектировании я также сталкивался с различными комментариями, ссылаясь на то, как асинхронное программирование async/await играет важную роль в обфускации (но не видел подробного анализа на тему цитирования в качестве ссылки). Я также отметил интересный любопытный аргумент , вызывающий размышленияhere, что делает эти развивающиеся технологии программирования еще более интересными.Создает ли UWP .Net Native вместе с асинхронным программированием обфускацию?

ли UWP .Net Native с асинхронного программирования сделать запутывания не имеет значения? Можем ли мы считать, что защита прав на интеллектуальную собственность (IPP) приложений UWP не хуже, чем приложение с UWP с «хорошей» обфускацией?

источник

2015-12-07 user5525674

Отражатель достаточно разбирается в асинхронном режиме, чтобы иметь возможность декомпилировать его сейчас. Я бы ожидал, что и другие декомпиляторы тоже сделают это сейчас. Само по себе async/await было только препятствием для декомпиляции до тех пор, пока декомпиляторы не будут обновлены, чтобы определить преобразования компилятора. –

Интересный вход. Таким образом, асинхронное программирование не является серьезным препятствием для декомпиляции самостоятельно, а это значит, что вы покидаете .Net Native toolchain. Но, когда вы ссылаетесь на Reflector, вы не имеете в виду **. Net Native **, верно? – user5525674

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

Я всегда чувствовал, что обфузация является неправильным ответом на проблему.

Но вы правы: декомпиляция и обратная инженерия вывод .NET скомпилированной программы намного сложнее. На самом деле это было бы еще сложнее, чем то, что обфускация на Ил делала. Но это все еще невозможно.

Можем ли мы считать, что защита интеллектуальной собственности обычных приложений UWP не хуже, чем приложение с UWP с «хорошей» обфускацией?

Да, на самом деле, это будет даже лучше.

источник

2015-12-07 09:28:00

Помимо этого, использование obfuscator специально не поддерживается с .NET Native. –

@ matt-whilden: Благодарим вас за исправление тега. Я могу понять ваше замечание выше без фразы * Помимо этого *. Можете ли вы объяснить, что вы имеете в виду с фразой квалификатора * Помимо этого *? – user5525674

Я действительно имел в виду, что Крис прав, потому что, конечно, сложнее понять родные скомпилированные двоичные файлы, которые выходят из .NET Native. Я просто хочу убедиться, что когда обфускация и .NET Native говорят о том, что это специально вызвало, что запущенные двоичные файлы явно не поддерживаются компилятором .NET Native. Они производят IL, который слишком отличается от IL, который мы обычно видим из компилятора C#/VB, и, скорее всего, приведет к проблемам компиляции. Дайте мне знать, если это поможет. –

Создает ли UWP .Net Native вместе с асинхронным программированием обфускацию?

ответ

Смежные вопросы