Я бы хотел узнать, как Саламандра делает то, что делает?
Я включу несколько пунктов, которые меня особенно интересуют
-
Ссылка по требованию
Компоновщик запускается с помощью методов ввода (которые вы можете настроить) и рекурсивно просматривает граф вызовов, чтобы связать только необходимые биты кода MSIL. Неиспользуемый код не будет связан с окончательной сборкой. Следовательно, ваш код становится более эффективным, а размер файла уменьшается.
-
Ссылка на API-интерфейсы Framework
Компоновщик настолько мощен, что даже сборки Microsoft .NET Framework, такие как System.Windows.Forms.dll, могут быть связаны с вашими собственными сборками .NET. Поскольку он связывает по требованию, будет связана только необходимая часть. Это очень полезно для защиты вашего кода, простого развертывания приложений и устранения неполадок путем отладки в самом коде платформы.
-
Собственное сочинение
Собственный компилятор преобразует все управляемые сборки, включая системные сборки, в собственный код x86. Никакая инструкция MSIL не будет отправлена, JIT-компиляция во время выполнения. Это обеспечивает наилучшую защиту от разборки и декомпиляции, а также повышает производительность и время запуска.
-
Простое и быстрое развертывание без полной установки Microsoft .NET Framework
Средство мини-развертывания объединяет минимальный набор файлов времени выполнения CLR и зависимых сборок, которые можно просто скопировать в одну папку на целевом компьютере, и ваше приложение будет работать так, как если бы была установлена вся среда. Поскольку установка изолирована в одну папку, не будет никаких конфликтов с будущей установкой .NET. Если для зависимых сборок используется связывание, это еще больше уменьшит размер файла.
-
Код защиты
Существует одна проблема, к которой не относится ни один из текущих обфускаторов, то есть независимо от того, насколько хороша обфускация, в вашем коде есть вызовы системной библиотеки и другие внешние ссылки (см. Красный цвет ниже). Поскольку эти вызовы являются внешними ссылками, обфускаторы должны будут оставить их без изменений. Тем не менее, эти ссылки очень помогают понять декомпилированный код, потому что они хорошо документированы и являются открытыми API. Компоновщик удаляет или уменьшает такие общедоступные API-интерфейсы, связывая API-интерфейсы каркаса с вашим собственным кодом, и, таким образом, значительно затрудняет декомпиляцию вашего кода после запутывания. Ниже показан пример кода MSIL до и после использования компоновщика.
before: (никакие обфускаторы не могут переименовать следующий код, так как они являются внешними публичными API)
IL_0000: ldarg.0
IL_0001: call instance void [System.Windows.Forms]System.Windows.Forms.Form::.ctor()
IL_0006: ldarg.0
IL_0007: newobj instance void [System.Windows.Forms]System.Windows.Forms.TextBox::.ctor()
IL_000c: stfld class [System.Windows.Forms]System.Windows.Forms.TextBox A.A::A
IL_0011: ldarg.0
IL_0012: ldfld class [System.Windows.Forms]System.Windows.Forms.TextBox A.A::A
IL_0017: call valuetype [System.Drawing]System.Drawing.Color [System.Drawing]System.Drawing.Color::get_Cyan()
IL_001c: callvirt instance void [System.Windows.Forms]System.Windows.Forms.TextBoxBase::set_BackColor(valuetype [System.Drawing]System.Drawing.Color)
IL_0021: ldarg.0
после: (абсолютно без понятия Windows.Forms API используются, что является большим препятствием для хакера, чтобы понять это
барахло)
IL_0000: ldarg.0
IL_0001: call instance void a.A::.ctor()
IL_0006: ldarg.0
IL_0007: newobj instance void D.c::.ctor()
IL_000c: stfld class D.c A.A::A
IL_0011: ldarg.0
IL_0012: ldfld class f.aA.A::A
IL_0017: call valuetype a.B()
IL_001c: callvirt instance void D.c(valuetype g.e)
IL_0021: ldarg.0
Некоторые из этих вещей сбивают меня с толку, и мне было интересно, знает ли кто-нибудь еще, как все это работает?