Денис Загаевский: Это какую защиту купить? Обфускатор? Не очень они впечатляют.
___При обфускации кода - стремятся тупо переименовать методы и классы, это эффективно, только если кода много. А если мало, то больше нравится делать иначе: давать реальные имена, но ложные, и даже создавать методы с именами типа "cannot_decompile", что приведет в ступор, по крайней мере, начинающих, склонных пользоваться только рефлектором.
___Запутывать control-flow - чтобы получится реальный "can not decompile" - многие обфускаторы вовсе не слышали, также как и заворачивать все в рефлексию. А ведь перспективы тут есть, если развить мышление. Что и хочу сделать, изучая сложные алгоритмы - такие, как шифрование.
___На активную защиту (выявлять дебаггер, отладочные прокси и драйвера, проверять чек-суммы функций - не пропатчены ли, репортить на сервер, идентифицировать железо) - тоже большинство кладет. Выявить дебаггер весьма проблематично для .NET - их несколько, и кроме стандартного, они не предоставляют удобной возможности выявить.
___Если кода мало, то надо сделать так, чтобы было много. Напихать всего побольше, зависимости запихать в EXE с помощью IlMerge. И вот эту кашу - уже обфусцировать и закапывать активную защиту. Обфускаторы тоже мало этим заняты.
___Наконец, технология вроде NecroBit, которая защищает от совсем уж начинающих и неусердных с рефлектором. Вот ее предоставляет пара обфускаторов - но покупать ради одного этого? "$1 за удар, $99 за знание, куда ударить"? Проще исследовать и повторить.
Денис Загаевский: Нам сложно правильно провести грань между известным и неизвестным. Для нас-то рано или поздно все становится известным, если оно хоть немного стоит денег. Поэтому когда сами создаем защиту для того, что полностью защитить нельзя в принципе (код от декомпиляции, IP серверов и реализацию протокола в клиентском приложении) - всегда кажется, что сделали мало или вообще не то.
Денис Загаевский: Не везде, и часто завязанные на системном API, что сложно маскируется и легко выявляется отладкой.
Сами алгоритмы тоже лучше модифицировать, а то скоро в декомпиляторах в списке строк будет прямо кнопка "try decrypt", и в меню список типичных алгоритмов... Одним кликом указываешь строку, другим - предлагаемый ключ - готово...
Ну а разобраться, просто прочитав теорию - я не могу, только метод исследования и вечная неуверенность в том, что лично не видел (не насчет безопасности, а именно непонимание), и остальные в команде такие же - сумрачная тевтонско-китайская команда с верхушкой в России)
Есть готовые онлайн компиляторы...
Ваш вариант со скриптом опасен, и есть большой риск, что за это придерутся. Надо позаботиться о песочнице. Хотя бы в виде виртуалки и взаимодействовать с ней.
sim3x: Почему? Просто потому что "так не делают"?
Или вы считаете, что какая-то специфика моего приложения не сочетается с Meizu и Xiaomi, поэтому им не пользуются такие разработчики, хотя их пруд-пруди вокруг?
Если бы речь шла о Vertu, то да, не сочеталась бы :)
Ну хорошо, можно убрать слово "абсолютно", но все равно видно, что популярностью эти устройства не пользуются у разработчиков.
Karmashkin: Ну, я по похожей причине приобрел самсунг, а не что-то другое, так как знал, что у них с SD-картой "по-новому", а также и другие могут быть различия у самсунгов, и вообще на нем Android 6.0, именно в нем важные отличия. Но это все и не особо-то багами назовешь, а чтобы именно из-за бага тратить 5-15 тысяч рублей, не говоря о больше...
sim3x: Я же пишу, по моей статистике. У меня приложение для разработчиков. Собирает статистику и шлет ко мне.
Согласно ее, самый популярный - это самсунг, класса где-то от J2 до A3. А он и есть самый популярный.
Изредка появляются и редкие вплоть до асусов, алкателей и нексуса. Нередко HTC, Huawei, Lenovo, Moto G - все так и должно быть.
А этих - 0.
Да, в штуках, по всему миру - Азия, Южная Америка, изредка США, СНГ и один раз Европа.
Подождем, пока наберется еще...
Но смотрите - по моим данным самый популярный самсунг средне-низкого класса (от средних J до начальных A), а он и есть самый популярный. Значит, выборка годное. Остальное в ней - Huawei, Lenovo, HTC, да даже Alcatel один или два раза был, и Nexus, причем то был реальный Nexus, не эмулятор. А этих - ни разу.
nioterzor: 1. Нет, не могут. Попробуйте на 1 сервере запустить 2 Apache с одним и тем же конфигом.
2. Написано "пользователя", значит, клиента. А если у вас пользователь - это админ сервака, то это у вас все с ног на голову, а не у меня.
Crystal_Insight: Если зашифрован - конечно, меняет. Никто не сможет сказать, что там было, не произведя реверс-инжиниринг самого вируса (в котором ключ шифра).
Я не знаю, что у вас там скачивается по USB, ну допустим увидите EXEшник какой-то, или SYS, и что?
CityCat4: Не знаю насчет подхода, но сам продукт качественный, решения уникальные. Оптимизация на высоте - и быстродействия, и быстроты разработки.
Одна только интеграция: Download-Install-Next-Finish - 5 кликов - и ваша Visual Studio преобразится. Будут у меня и такие библиотеки (с Utilами/Helperами), которые нужны именно в каждом проекте и именно сразу, как только создаешь "Приложение WinForms", я бы сказал - нужны не меньше, чем System.dll, а не лазать по nugetам в поисках пакета - и я такую возможность постараюсь предоставить от 2008 Express до 2017 Ultimate, и для Xamarin тоже, в том числе под OS X.
А еще был случай с нашим TCP-клиент-сервером. Испытываем свою систему, много клиентов и сервер. Вдруг в логе сервера замечаем - один клиент как-то слишком часто отрубается, буквально парой пакетов перекинется - и соединение рвется, клиент идет подключаться повторно, и так по-кругу. Я забеспокоился. Решил зайти на него через тимвьювер - а не заходит. Ничего не понятно - то ли баг в клиенте нагрузил процессор и теперь Team подключиться не может... То ли что... Потом связался с человеком, который сидел у того компа (это было в другом городе) - и оказалось то, о чем я не мог даже подумать. Оказалось, на той точке вообще был отключен интернет. Провайдером. За неуплату.
И эта история - не выдумка. Мне незачем вам врать.
А если все это правда, то все это уже достойно огромной похвалы. В финансовом эквиваленте.
Другое дело, что люди недостойны такого. В слишком хорошее просто не верят. "Ну, что может быть особенного в библиотеке для TCP?" И я должен им доказать... Или просто работать хуже. Тогда и проблемы не будет...
___При обфускации кода - стремятся тупо переименовать методы и классы, это эффективно, только если кода много. А если мало, то больше нравится делать иначе: давать реальные имена, но ложные, и даже создавать методы с именами типа "cannot_decompile", что приведет в ступор, по крайней мере, начинающих, склонных пользоваться только рефлектором.
___Запутывать control-flow - чтобы получится реальный "can not decompile" - многие обфускаторы вовсе не слышали, также как и заворачивать все в рефлексию. А ведь перспективы тут есть, если развить мышление. Что и хочу сделать, изучая сложные алгоритмы - такие, как шифрование.
___На активную защиту (выявлять дебаггер, отладочные прокси и драйвера, проверять чек-суммы функций - не пропатчены ли, репортить на сервер, идентифицировать железо) - тоже большинство кладет. Выявить дебаггер весьма проблематично для .NET - их несколько, и кроме стандартного, они не предоставляют удобной возможности выявить.
___Если кода мало, то надо сделать так, чтобы было много. Напихать всего побольше, зависимости запихать в EXE с помощью IlMerge. И вот эту кашу - уже обфусцировать и закапывать активную защиту. Обфускаторы тоже мало этим заняты.
___Наконец, технология вроде NecroBit, которая защищает от совсем уж начинающих и неусердных с рефлектором. Вот ее предоставляет пара обфускаторов - но покупать ради одного этого? "$1 за удар, $99 за знание, куда ударить"? Проще исследовать и повторить.