Здравствуйте, ReSanity, Вы писали:

RS>Здравствуйте, bazis1, Вы писали:

RS>Отличается очень сильно. Ваш "алгоритм RSA" так и останется алгоритмом RSA на стороне сервера, не более
RS>Наша же система позволяет Вендорам за считанные минуты самим решить какие кусочки кода (желательно,
RS>ассоциированные с продуктовой политикой) они хотят сделать недоступными для взлома и анализа.
это порождает массу вопросов к вам. какова производительность вашего облака? сколько вы мне выделяете памяти и дискового пространства? сколько потоков я могу создать на стороне облака? а сеть у вас есть?

или же вырезаются не любые куски кода, а только те, которые не дергают api функции, не выделяют памяти, и не сильно грузят ЦП. но как тогда вырезать бизнес-логику?


RS>Да, задержки имеют место быть, все очень сильно зависит от выбранных кусков кода
RS>(чем меньше "прыжков" исполнения между клиентом и сервером, тем меньше задержка).
RS>Достаточно быстро можно подобрать подходящие регионы кода, которые не будут
RS>вносить задержки (1) и будут весьма стойкими к атаке на "черный ящик" (2)
требованию (1) удовлетворяют только функции, отрабатывающие на стадии инитализации приложения, или же редко используемая часть функционала (вывод на печать). однако, вывод на печать вы отбрасываем сразу, т.к. передача таких объемов по сети вызовет гнев юзеров, да и сомнительно, чтобы вырезанный код работал в облаке, если он активно использует апи-функции, ран-тайм компилятора и глобальные переменные.

функции иницилизации, очевидно, не отвечают требованию (2). функция печати ему отвечает. но если разработчики решили реализовать ее в виде сервиса, но они это сделают _ПРЯМЫМИ_ руками, а не через Ж. это будет RESTful, работающий через http(s), причем серверная часть пишется с использованием серверных технологий и серверных библиотек. и она работает. в отличии от.


RS>Насчет необходимости "постоянно быть на связи" — такая необходимость есть только в моменты исполнения кода
RS>на стороне сервера, в остальные моменты времени канал связи не будет являться необходимостью. Интересно,
RS>почему у Вас не возникает подобных вопросов по отношению к SaaS?
вопрос на засыпку: сколько у вас кастомеров и вы вообще представляете какой DDoS вам они устроят по мылу и телефону? он-лайн активация это еще туда-сюда. особенно, если на активацию дается месяц времени. а вот от возможности валидации лицензии при каждом запуске очень многие разработчики отказываются, поскольку даже если у 1 из 100 кастомеров отвалится интернет в самое неподходящее время, то бурлению говен не будет пределов и гугл во первых строках поиска по названию программы покажет не сайт разработчика, а бурное обуждение богомерзкой программы.

с одной из такой программ я имел "счастье" столкнуться. прога для мобильного, называется where и по замыслу разработчиков она отвечает на любой вопрос с учетом моей локации. распростаняется по подписке. денег хочет каждый месяц. и при каждом запуске проверяет валидность лицензии. ну на сотовом интернет как бы постоянно есть. но по каким-то причинам проверка валидности тормозит настолько, что реально проще ногами дойти и посмотреть. ладно бы проверка все время тормозила. так ведь нет! тут как (не)повезет. в результате пользовался программой какое-то время, пинал девов чтобы фиксили баги, но в конечном счете сделал чардж за весь год сервиса, накатал пару-тройку живописных ревью (а писать я умею, особенно когда прет) и они вышли в топ, т.к. многие юзеры посчитали ревью полезными.

B>>Короче, ИМХО, вы изобрели теоретический велосипед с теоретически оптимальным числом колес Пи, вот только дороги ему увидеть не суждено...
RS>Поверьте, Вы далеко не первый, кто нам это говорит. Однако есть как-минимум четыре далеко не глупых человека, которые с Вами не согласятся
какие-то продажи у вас будут, вероятно. но не взлетит. с таким-то отношением к безопастности... я молчу, что вырезать бинарный код само по себе занятие глупое и рискованное. к тому же это предъявляет к коду список требований, который вы нигде не упоминаете. а зря. я уже спросил: на какие ресурцы цп и оперативы может расчитывать вырезанный код? будет ли в его распоряжении диск и сеть? если да, то насколько надежно изолирован один код от другого? как быть с АПИ функциями? как быть с ран-таймом?

кстати, а вы в курсе вообще, что многие "навесные" защитные комплексы в реальности защищали функцию, возвращающую true/false и потому очень легко отламывались? вы, конечно, скажите, что "проблемы индейцев..." и далее по тексту. типа разработчики сами виноваты, что выбирают такие функции для защиты. но в действительности это не проблемы индейцев. это _ваши_ проблемы. потому что разработчик платит вам денежку и ждет, что ваша программа сама все сделает. а тут, оказывается, надо вникать в суть вещей и непостижимость мира. а у вас ни примеров, ни демонстраций, ни внятного описания, словом Н И Ч Е Г О. пусто.

при этом офф-лайновые протекторы, шифрующие код, имеют сильно больше преимуществ. потому что у них нет задержек, они выполняют код на хосте, и самое главное они не ограничены в размере обрабатываемых данных. скажем, я написал свой архиватор. и решил защитить функции упаковки и распаковки. ваша защита справится с этим? ну, допустим, вы позволите выделять мне в облаке память и напрягать цп. но... как быть с передачей данных? юзер повеситься если решит упаковать что-то большее. не проще ли изначально писать свой веб-сервис для упаковки в таком случае?