Комментарии (10)

1. 

   msin

   23.03.2019 08:46

   #19929150

   Судя по всему использовался очень слабый обфускатор…
   Базовая обфускация заключается не только в переименование классов, методов и полей, но и шифровании всех строк. Я уже не говорю про виртуализацию кода и данных.
   В общем, это называется обфускация для честных людей.
   Если вас интересует работа современных полноценных обфускаторов, посмотрите на Eazfuscator.NET

   
   

   1. 

      gdt

      23.03.2019 09:42

      #19929246

      Ваш Eazfuscator.Net точно так же распаковывается одним щелчком пальцев. Если хотите что-то, что не снимается за 5 минут — посмотрите в сторону ConfuserEx (https://github.com/XenocodeRCE/neo-ConfuserEx). Его применение требует определённых усилий, зато в наших тестах он оказался самым устойчивым к распаковке.

      
      

      1. 

         msin

         23.03.2019 10:31

         #19929428

         Ваш Eazfuscator.Net точно так же распаковывается одним щелчком пальцев

         
         Позволю себе усомниться в этом утверждении…
         Скачал de4dot-net35.zip, он без проблем «очистил файл»:
         

         Detected Eazfuscator.NET 5.2-5.8 (EazDemo.exe)
         Cleaning EazDemo.exe
         Renaming all obfuscated symbols
         Saving EazDemo-cleaned.exe

         
         Вроде бы полный успех… только программа перестала работать:
         

         EazDemo-cleaned.exe
         Необработанное исключение: System.NullReferenceException: Ссылка на объект не указывает на экземпляр объекта.
            в Class97.method_249(Int32 int_0, Class24 class24_0)
            в Class97.method_48(Int32 int_0)
            в Class97.method_99(Class61 class61_2)
            в Class97.method_174()
            в Class97.method_72()
         --- Конец трассировка стека из предыдущего расположения, где возникло исключение ---
            в Class97.method_254(Object object_3)
            в Class97.method_279()
            в Class97.method_292(Object object_3, UInt32 uint_0)
            в Class97.method_72()
            в Class97.method_136()
            в Class97.method_97()
         --- Конец трассировка стека из предыдущего расположения, где возникло исключение ---
            в Class97.method_254(Object object_3)
            в Class97.method_279()
            в Class97.method_292(Object object_3, UInt32 uint_0)
            в Class97.method_97()
            в Class97.method_207(Object[] object_3, Type[] type_9, Type[] type_10, Object[] object_4)
            в Class45.Main(String[] args)

         
         Возможно, я что-то не так делаю (у меня нет опыта деобфускации).
         Попробуйте сами, это классическая crack_me консолька.
         Пока что я остаюсь при своём убеждении, что реверсить виртуализированный код — задача не для всех и уж точно она не выполняется автоматически по щелчку пальцев.

         
         

         1. 

            gdt

            23.03.2019 10:44

            #19929464

            Заметьте, я ничего не говорил про запуск. Далеко не всегда для анализа нужно запускать исполнимый файл, тем более вы специально выбрали crackme. Возьмите лучше рабочий софт, с рефлексией, WCF, COM interop, упакуйте его так, чтобы он продолжал работать, тогда и поговорим ;)

            
            

            1. 

               msin

               23.03.2019 11:32

               #19929590

               Вы, видимо, шутите… деобфускатор восстанавливает исходный код, но при этом не может сделать валидную исполняемую сборку?
               Запустил dotPeek, смотрю на восстановленный код:
               

               internal sealed class Class35
               {
                 internal void method_0()
                 {
                   Class26.smethod_0().method_256(Class26.smethod_2(), "\"U#&7\"TZ.9", new object[1]
                   {
                     (object) this
                   });
                 }
               }
               

               
               Очень содержательно… знаете, что значит "\«U#&7\»TZ.9"?
               Это название ресурса, где находится исполняемый код для виртуальной машины со случайной системой команд (каждая обфускация создаёт новую VM с уникальной системой команд).
               Более того, этот кусок кода выглядит точно так же до деобфускации с единственной разницей, что классам и методам присвоены печатные идентификаторы.
               В общем, признайте, вы погорячились насчет щелчка пальцев.
               И рефлексия, WCF, COM interop и т.д. здесь не причем. Виртуализация кода работает везде одинаково и если нет возможности увидеть 4 строки простейшего кода, то смысла ковырять что-то сложнее нет никакого.
               Понятно, что все имеет свою цену и нельзя виртуализировать весь код целиком, он будет с неприемлемой производительностью. Но найти 3-5 самых важных методов для виртуализации труда не составит.

               
               

               1. 

                  gdt

                  23.03.2019 12:03

                  #19929712

                  Окей, в данном конкретном случае я и правда погорячился насчёт «щелчка пальцев», виртуализация и правда очень хорошо защищает код от реверсинга (можно вспомнить хотя бы VMProtect). Но мне такое не встречалось в боевом софте (я про .Net), буду очень признателен, если дадите ссылку на что-то подобное, чтобы поковырять своими руками. А чтобы сломать рефлексию зачастую достаточно банального переименования типов, не то что виртуальной машины :)

                  
                  

                  1. 

                     msin

                     23.03.2019 12:53

                     #19929914

                     Нет, к сожалению я не знаю, кто использует виртуализацию в коммерческих продуктах.
                     На самом деле виртуализация защищает от статического анализа и не является абсолютной защитой… потому что аппаратно код выполняется достаточно прозрачно и нельзя отобрать доступ к оперативной памяти и процессору у реверсера.
                     Для полноценной защиты нужно хотя бы частично выполнять код на защищенной аппаратной платформе, например, в ключе Guardant Code.
                     Это тоже не абсолютная защита, но послойное сканирование ячеек памяти ключа это крайне дорогая операция (слышал, что ценник начинается от $100к).
                     Кстати, Guardant так же предлагает виртуализацию кода (.NET и нативного).
                     На самом деле можно пойти еще дальше и скомбинировать виртуализацию и защищенное выполнение — написать простенькую VM, записать её в ключ и заменить куски кода в исходной программе на вызовы интерпретатора в ключе. Куски байткода в исходной программе можно зашифровать и подписать ECDS подписью (это совершенно здоровая паранойя :-)

1. 

   gdt

   23.03.2019 09:18

   #19929206

   На самом деле большинство популярных обфускаторов для .Net (особенно dotnet reactor, который я вижу в каждой первой софтине) снимает не напрягаясь замечательная утилита под названием de4dot. Она консольная, но если использовать для декомпиляции Telerik JustDecompile — можно в пару кликов установить плагин de4dot и делать всё полностью через ui.

1. 

   kekekeks

   23.03.2019 09:50

   #19929264

   Хотите нормально убрать IL-код — собирайте с CoreRT. Только для этого UI-тулкит должен быть соответствующим (сейчас только AvaloniaUI умеет).

1. 

   IgorPie

   23.03.2019 20:55

   #19932036

   Это не реверс-инжиниринг, а достаточно банальный кряк, представленный методом "как срисовать сову"