На чем писать сервер чтобы усложнить декомпиляцию?
Есть сервер, реализован на Node.js к которому обращается приложения для проверки лицензии и привязки к железу, а также получения и сохранения некого списка. К этому серверу мы не предоставляем доступ заказчику. Но заказчик хочет чтобы сервер-приложения было на его хостинге и он имел к нему доступ, поэтому единственный выход, который я вижу - это переписать часть приложения-сервера, которое обслуживает приложения-клиент на Go. На Go я не писал, но это не проблема. Впорос только насколько подлежит скомпилированый код на Go реверсной инженерии или можно ли для этого использовать другое например Cython (а вот Python я неплохо знаю)?
Закажчик не должен снять ограничения на количество лицензий, а также сервер закажчика обязательно должен передавать на наш сервер данные о зарегистрированом пользователе. И это, возможно, не все, что закажчик изменить не должен. В любом случае надо, чтобы найти специалиста, который взломает сервер, было дорого, долго/сложно
Переписывать все - не круто.
Достаточно небольшой кусок с ключевыми алгоритмами.
Не обязательно весь сервер целиком.
Декомпиляция возможна всегда, но вопрос - на каком уровне будет декомпилированный код. Если ты получишь почти что ассемблер - смысла в декомпиляции мало.
Любой компилируемый в native подходит - Go, C/C++, Pascal, Haskell на порядки лучше, чем Python, Java, NodeJS.
Не забудь застрипать дебужные символы.
После чего декомпиляция из этого способна возродить назад такой ужас, в котором мало кто захочет разбираться задешево.
Но в конечном итоге все упирается насколько занитересован человек.
Если продукт очень массовый или очень дорогой - больше интереса взламывать.
А что, заказчик идиот?
Если он хочет заполучить сервер как некий гарант, то разве он не хочет еще и исходники?
Имхо, поддержка разработчика (устранение багов, которые и год спустя могут быть выявлены) существенный плюс, чтобы оставаться с вами.
Декомпиляция скомпилированного - это всегда вопрос времени/денег.
Я бы подумал над построением проверки с использованием асимметричных схем шифрования. И раз уж у вас на ваш сервер все равно уходит информация - то на нем и давать разрешения/проводить проверку.
Но лучше не загибать ценник - не будут и взламывать.
Закажчик продает приложения, которое мы создаем, за $5 в месяц, мы получем 40% от этого, т.е. $2. Вероятно будет продано 10 000 - 20 000 лицензий + мы будем продавать их по других каналах и других ценах. Впринципе закажчику не выгодно ничего взламывать, потому что приложения будет развиватся и обновлятся, но мы всеравно не может дать все наши исходники сервера, там есть много кода, который не должен попасть в чужие руки. Т.е. переписывать нужно в любом случае, даже если на тот же Node.js
А если заказчик - по сути ваш дистрибьютор - то вообще то нет смысла что-то скрывать, достаточно на договорном уровне решить вопросы собственности на интеллектуальную собственность.
Ну вы же строите схему верификации лицензий с-но есть данные которые нужно передавать, но так что бы их нельзя было фальсифицировать. Ни при передаче туда ни при получении ответа обратно. Такие схемы как-раз и удобно строить на основе асимметричных шифров.
Sly_tom_cat .: если говорить о лицензии, то я просто проверяю "user".license >= CURRENT_TIMESTAMP (PostgreSQL). Что здесь шифровать - непонятно) Может вы неправильно поняли слово лицензия. Отдельно есть проверка "прив язки к железу", в результате которой формируется некий JSON. Но она может быть сброшена на NULL, по запросу пользователя
Чтобы пользоватся приложениям нужно ввести логин и пароль. Во время запуска проверяться не истекла ли лицензия на сервере. Соотвествено в офлайне оно не может работать, да и в офлайне оно по функционалу своему и бесполезно.
собственно да, можна некий запрос шифровать окрытим ключом. Но зачем, если дистрибютор хочет быть полностью независим, то есть хочет чтобы мы не могли его наебать, аннулировав лицензии или как-то так. Поэтому единственный вариант который я вижу - избавить его искушения что-то спиздить у нас
Sly_tom_cat .:
>>>>> А если заказчик - по сути ваш дистрибьютор - то вообще то нет смысла что-то скрывать, достаточно на договорном уровне решить вопросы собственности на интеллектуальную собственность.
Ну-ну.
Заказчик почему то хочет тоже подстраховаться.
Тарас, вы уж извините - но ваша проблемы (вы обманываете дистрибютора или он вас) - это вопрос вашего договора с ним. Т.е. это юридический, а не технический вопрос.
Sly_tom_cat .:
>>>> Тарас, вы уж извините - но ваша проблемы (вы обманываете дистрибютора или он вас) - это вопрос вашего договора с ним. Т.е. это юридический, а не технический вопрос.
Техническая подстраховка позволяет не терять деньги месяцами пока будет идти суд, а задавить проблему в зародыше - быстро-быстро, как только она возникнет.
Разумеется, это нужно корректно оформить - иначе за такую "подстаховку" можно и огрести.
мне кажется, что нет такого компилята который нельзя было бы расколдовать в исходый вид. можно выдавать лицензию под имя пользователя, на основе имени пользователя генерировать файл-лицензию (простыня шифрованых букв). Клинет сверяет данные на основе файла-лицензии и или запускается либо нет. А иметь пользователей с одинаковым именем в сети по-моему винда не разрешает.
Alexej Simakov: заказчик будет продавать в интернете, но вы мне подали идею как улучшить "прив язку к железу" - учитывать имя компьютера и пользователя
спасибо за coreos rkt, не слышал об этом, но контейнер - не вариант, хотя бы потому что ни моя ни админ квалификация программиста на стороне закачика недостаточна, чтобы это настраивать и поддерживать
В случае банальной проверки лицензии будут одинаковы по устойчивости
Или нужно писать код, который будет противодействовать отладчикам, потом продиводействовать отладке, потом усложнять отладку, потом уловки для отвода внимания
Заинтересованному лицу, нужно будет только выяснить какой блок кода отвечает за "лицензию" и обрезать его или сделать тоже самое, но после прохождения квеста
Привязка к железу - емулируется
ИМО, 40% за установку норм доля для разработчиков
Лучшим вариантом привязки клиентов к себе - возьмите на себя всю поддержку (или не всю ,а фичи + второй лвл поддержки), кроме финансовой
