История о том как я "защитил" ехе .net приложения.

Тема в разделе "WASM.BEGINNERS", создана пользователем MasterSLIVA, 16 авг 2018.

  1. MasterSLIVA

    MasterSLIVA Member

    Публикаций:
    0
    Регистрация:
    10 авг 2018
    Сообщения:
    48
    Эта тема, конечно не вписывается в контекст этого форума. Здесь в основном взлом, и реверс, но я осмелюсь создать тему посвещенную защите.

    Вобщем, дело было так. Написал крякми, в котором нужно было пропатчить строку гет запроса.
    Код выполнялся в CodeDom компиляторе. Строка кода была зашиврована в Base64
    1. Обфусцировал строки Appfuscator`ом. http://appfuscator.com/
    2. Перегнал ехе в байтовый код и создал стаб на .net, запускающий в памяти этот код. Перед запуском массив байт расшифровывется, т.к. я его еще зашифровал CR4 алгоритмом.
    3. Создал нативное приложение С++, которое размещает CLR среду и запускает байт код этого .net стаба. Т.е. я создал нативный стаб, который запускает .net стаб.
    4. Получившийся файл накрыл еще крякнутым Private Exe Protector`ом. https://private-exe-protector.com (он накрывает только натив)
    Короче в итоге получилось крякми 0\10 потому что мегадампер вытащил голый .net код.

    Неужели с защитой .net все так печально?
    Я знаю что есть вариант виртуализировать код в натив, но от каждого такого протектора уже написан анпакер. Не хочется всю логику программ переносить на выделенный сервер.
    Может быть есть какие нибудь методики, которые позволят хоть и не защитить мой .net ехе, но хотя бы изрядно потрепать нервы крякеру?
     
    Последнее редактирование: 16 авг 2018
    _edge нравится это.
  2. LastNoob

    LastNoob Member

    Публикаций:
    0
    Регистрация:
    28 янв 2018
    Сообщения:
    80
    Может быть я и ошибаюсь, но до сих пор нет такой защиты, когда код выполняется на стороне клиента и при этом клиент не может его изменить в свою пользу.
    И вывод таков: рано или поздно защита становится потенциально уязвимой для большей группы крекеров, хоть и какое-то время сможет оттянуть время после официального выпуска.
    [​IMG]
    Недавно читал статью в журнале "хакер", правда искал по запросам VMprotect, но ситуация походит на вашу.
    В примере на 26 ой стр. как раз рассматривается уязвимость на стыке модулей классического СИ и .net, считаю, что отсюда можно найти полезное.
    Ссылка на выпуск: https://yadi.sk/i/A_Im1Rc_3aGpWq
     
    MasterSLIVA нравится это.
  3. _edge

    _edge Well-Known Member

    Публикаций:
    1
    Регистрация:
    29 окт 2004
    Сообщения:
    631
    Адрес:
    Russia
    MasterSLIVA, крайне интересно написали, тянет на статью (в смысле, article). Я бы даже предложил бы вам завести отдельную ветку по .NET внутренностям. Не умею в NET ни разу, но не покидает интерес к тому, как там все устроено.

    Есть тема со смешиванием байткода и нативного, то есть в Net программе вызывать натив (через loadlibrary подгружать системную dll, и уже с ней работать) - это может создать сложности кракерам\автоматизированному ПО, расчитанному сугубо на Net.
    Верно было отмечено, все усложнения защит лишь оттягивают время до полного ее слома.
    Все определяется ценой защищаемого продукта и затратами на его ломание.
    Рулит либо несимметричный ключ на сервере, либо аппаратный ключ.

    Это звучит смешно, но для кракеров представляет сложность ломать программы, писанные на VB6, т.к. нормально оно не декомпилируется ничем, внутренности vb6 exe по большей части недокументированы.

    Есть редкая книга по NET, https://yadi.sk/i/hsoBT73O32BY2A

    Можно, кстати, попробовать написать свой простой VM-интерпретатор для своего VM-байткода.
     
    Последнее редактирование: 16 авг 2018
    MasterSLIVA нравится это.
  4. f13nd

    f13nd Well-Known Member

    Публикаций:
    0
    Регистрация:
    22 июн 2009
    Сообщения:
    1.954
    Существуют методики, с которыми крякер со спокойствием удава скажет "да ну его нафиг" и не станет ничего делать. Они называются senselock и guardant
     
    MasterSLIVA нравится это.
  5. Prober

    Prober Member

    Публикаций:
    0
    Регистрация:
    4 дек 2008
    Сообщения:
    32
    Звучит и в самом деле смешно.
     
    MasterSLIVA нравится это.
  6. _edge

    _edge Well-Known Member

    Публикаций:
    1
    Регистрация:
    29 окт 2004
    Сообщения:
    631
    Адрес:
    Russia
    Таки школомалварь пишут на VB6, чтобы еще помучить этих аверов, не?

    Нужно больше топиков по .NET, ТС, вы молодец, снимаю шляпу )
     
    MasterSLIVA нравится это.
  7. texaciri

    texaciri Member

    Публикаций:
    0
    Регистрация:
    27 янв 2018
    Сообщения:
    58
    Вроде, обычно после .NET Reactor, получается такая каша, что реверсить нереально. Хотя вроде пишут что гуляет мод de4dot с поддержкой .NET Reactor 5.0, но это надо искать проверять.
     
  8. MasterSLIVA

    MasterSLIVA Member

    Публикаций:
    0
    Регистрация:
    10 авг 2018
    Сообщения:
    48
    net reactor снимается de4dot`ом до читабельного состояния.
     
  9. texaciri

    texaciri Member

    Публикаций:
    0
    Регистрация:
    27 янв 2018
    Сообщения:
    58
    а, ну ок). Если лицензия полностью на стороне клиента это потениально уязвимое ПО). А что там с .NET Core? оно же теперь вроде умеет в найтив компилиться. Правда пока что все равно весит огого.
     
  10. MasterSLIVA

    MasterSLIVA Member

    Публикаций:
    0
    Регистрация:
    10 авг 2018
    Сообщения:
    48
    Ой я даже пока не углублялся в него. Знаю только MVC5. Жаль что только в VS17 оно. Ну и это бекэнд для хостинга. Даже не знаю как его можно заюзать как клиентское приложение
     
  11. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.241
    я периодически пытаюсь следить за концептом Indistinguishable Obfuscation и всем, что с этим концептом выходит в академии...
    но вроде только для Multi Linear Maps есть хоть какая-то горе-реализация сейчас...
     
  12. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.241
  13. unc1e

    unc1e Active Member

    Публикаций:
    2
    Регистрация:
    28 июл 2017
    Сообщения:
    287
    а вот и ребята с бхф к нам заехали
     
  14. MasterSLIVA

    MasterSLIVA Member

    Публикаций:
    0
    Регистрация:
    10 авг 2018
    Сообщения:
    48
    Ага) Хотя мог и под другим ником зарегаться)
     
  15. unc1e

    unc1e Active Member

    Публикаций:
    2
    Регистрация:
    28 июл 2017
    Сообщения:
    287
    LastNoob, при обнове софта все эти прокси-хуекси длл слетают, необходимо реверсить алгоритм верификации серийника внутри вм, обращать его. Но на это скилл есть не у всех. В случае с последним вмпротом - десяток умельцев на это способен.
     
  16. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.775
    MasterSLIVA,

    > 2. Перегнал ехе в байтовый код и создал стаб на .net, запускающий в памяти этот код.

    Это не правильный крякми и вы не понимаете суть их. Крякми не должен содержать вм кода. Он должен быть нэйтивным и содержать интересные фичи", что бы был интерес его реверсить. Обращение же вм кода это чисто комерц задача и долгая рутина, это не крякми.
     
  17. texaciri

    texaciri Member

    Публикаций:
    0
    Регистрация:
    27 янв 2018
    Сообщения:
    58
    Ну как это. Крякми это пример той или иной реализаии защиты. А пример может быть любой, так что и виртуалка внутри тоже вполне себе. Помню был на хабре разбор хорошего крякми, там была внутри вм, которая на входе и на выходе принимало на брейнфаке. Вполне себе интересно жи. Правда найти ту статью не могу :dntknw:

    UPD: ну вот другая, вполне интересно же. https://habr.com/post/164437/
     
  18. _edge

    _edge Well-Known Member

    Публикаций:
    1
    Регистрация:
    29 окт 2004
    Сообщения:
    631
    Адрес:
    Russia
    texaciri и MasterSLIVA нравится это.
  19. Indy_

    Indy_ Well-Known Member

    Публикаций:
    4
    Регистрация:
    29 апр 2011
    Сообщения:
    4.775
    texaciri,

    Если вы накроете блокнот вмпротом то это будет не крякми. По причине, которую я выше написал.