На чем писать сервер чтобы усложнить декомпиляцию?
Есть сервер, реализован на Node.js к которому обращается приложения для проверки лицензии и привязки к железу, а также получения и сохранения некого списка. К этому серверу мы не предоставляем доступ заказчику. Но заказчик хочет чтобы сервер-приложения было на его хостинге и он имел к нему доступ, поэтому единственный выход, который я вижу - это переписать часть приложения-сервера, которое обслуживает приложения-клиент на Go. На Go я не писал, но это не проблема. Впорос только насколько подлежит скомпилированый код на Go реверсной инженерии или можно ли для этого использовать другое например Cython (а вот Python я неплохо знаю)?
Закажчик не должен снять ограничения на количество лицензий, а также сервер закажчика обязательно должен передавать на наш сервер данные о зарегистрированом пользователе. И это, возможно, не все, что закажчик изменить не должен. В любом случае надо, чтобы найти специалиста, который взломает сервер, было дорого, долго/сложно
Декомпиляция скомпилированного - это всегда вопрос времени/денег.
Я бы подумал над построением проверки с использованием асимметричных схем шифрования. И раз уж у вас на ваш сервер все равно уходит информация - то на нем и давать разрешения/проводить проверку.
Но лучше не загибать ценник - не будут и взламывать.
Закажчик продает приложения, которое мы создаем, за $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 .:
>>>> Тарас, вы уж извините - но ваша проблемы (вы обманываете дистрибютора или он вас) - это вопрос вашего договора с ним. Т.е. это юридический, а не технический вопрос.
Техническая подстраховка позволяет не терять деньги месяцами пока будет идти суд, а задавить проблему в зародыше - быстро-быстро, как только она возникнет.
Разумеется, это нужно корректно оформить - иначе за такую "подстаховку" можно и огрести.
