Запустите скрипт R и скройте фактический код от пользователя

Впереди

... будет практически невозможно развернуть R <something> на другом компьютере таким образом, чтобы любопытные пользователи не смогли получить доступ к исходному коду.

Из беседы в списке рассылки в 2011 году в ответ на вопрос Я бы не хотел, чтобы кто-нибудь мог прочитать код,

R — это проект с открытым исходным кодом, поэтому предоставление способов сделать это не входит в наши цели.

• Дункан Мердок https://stat.ethz.ch/pipermail/r-help/2011-July/282755.html

(Профессор Мердок много лет входил в R Core Team и R Foundation.)

Фон

Несколько (много?) языков программирования предоставляют возможность компилировать сценарий или программу в исполняемый файл, .exe на который вы ссылаетесь. Например, в Python есть такие инструменты, как py2exe и PyInstaller. Инструменты варьируются от простой компактизации сценария до застежки-молнии, возможно, запутывания сценария; ... к фактическому созданию exe со сценарием, либо сильно встроенным, либо подобным. (В этой части можно было бы использовать еще несколько цитат/исследований.)

Обычно этого достаточно для многих людей, если не пускать честных. Я говорю это так, потому что все, что вам нужно сделать, это найти в Google такие фразы, как decompile py2exe, и вы найдете инструменты, инструкции, руководства и т. д., цель которых может честно помочь кому-то восстановить потерянный код. Независимо от намерений, они только замедлят любопытных пользователей.

К сожалению, нет инструментов, которые легко делают это для R.

Существуют инструменты, предназначенные для облегчения использования инструментов, основанных на R, для пользователей, не являющихся пользователями R. Например, RInno и DesktopDeployR — это два инструмента, предназначенные для создания установщиков Windows (не mac/linux), поддерживающих инструменты R или R/shiny. Но цель таких инструментов — облегчить ИТ-задачи, связанные с тем, чтобы заставить пользователя/клиента установить и поддерживать R на своем компьютере, а не защищать код, который он запускает.

Ограничить R.exe?

Были вопросы (где-то еще?), которые спрашивали, могут ли они изменить сам интерпретатор R, чтобы он не делал все, для чего предназначен. Например, можно переопределить base::print таким образом, чтобы содержимое функций нельзя было сбросить, а debug не отображал код, который он собирается выполнить, и, возможно, несколько других защитных шагов.

Есть несколько проблем с этим подходом:

1. Всегда есть другой способ получить содержимое функции. Даже если вы запретите print.default и debugger делать это, есть другие способы добраться до функций (например, body(.)). Как вы думаете, сколько из этих кроличьих нор вы сможете точно пройти, получить их все... без никакого вредного воздействия на обычный R-код?

2. Даже если вы чувствуете, что можете добраться до них всех, шифруете ли вы исходные .R файлы, содержащие ваш собственный контент? Хорошо, шифрование — это хорошо, за исключением того, что вам нужно как-то расшифровать содержимое. Многие инструменты с зашифрованным содержимым делают это, чтобы помешать реинжинирингу, поэтому они также встраивают (разумеется, запутанно) ключ дешифрования в само приложение. Просто дайте ему время, кто-нибудь найдет и извлечет его.

   Вы можете подумать, что можете загрузить ключ при запуске (не хранится в приложении), чтобы код расшифровывался в режиме реального времени. Извините, сетевые снифферы получат ключ. Даже если вы получите его через https://, такие инструменты, как https://mitmproxy.org/, отобразят это шаг гораздо менее эффективен.

3. Допустим, вы перекомпилировали R, чтобы замаскировать print и т. д., у вас есть способ распространения зашифрованного исходного кода и возможность расшифровать его таким образом, чтобы ключ не был легко раскрыт (для полной расшифровки файлов исходного кода). Несмотря на то, что для доступа к исходному коду через все вышеперечисленное требуется специальный пользователь, ни один из вышеперечисленных шагов не требуется: они могут на законных основаниях принудить вас опубликовать ваши изменения в самом интерпретаторе R (что вы установлен для предотвращения печати содержимого функции). Это не раскрывает ваш исходный код, но раскрывает многие из ваших методов, которых может быть достаточно. (Или просто риск судебных издержек.)

   R — это GPL, а это значит, что все, что на нее ссылается, также испорчено GPL. Это означает, что все, что скомпилировано с Rcpp, например, также будет ограничено/освобождено (по вашему выбору) GPL. . Это включает мысли об использовании RInside: это также GPL (›= 2).

   Чтобы сделать это, не касаясь GPL, вам нужно написать свой интерпретатор (скорее всего, с нуля) без кода из проекта R.

Альтернативы

В конечном счете, если вы хотите предоставить клиентам утилиты/приложения/функции на основе R, единственный верный способ позволить им использовать ваш код, не видя его, — это... контролировать компьютеры, на которых будет работать R (и исходный код). код останется). Я добавлю больше ссылок, подтверждающих это утверждение, по мере их нахождения, но небольшое начало:

• https://stat.ethz.ch/pipermail/r-help/2011-July/282717.html
• https://www.researchgate.net/post/How_to_make_invisible_the_R_code

Опции включают в себя все, что позволяет полностью контролировать код R и интерпретатор R. Простые примеры:

• Приложения Shiny, размещенные на собственном сервере (или наshinyapps.io, если вы доверяете их безопасности); серверы включают Shiny Server (как бесплатную, так и коммерческую версии), RStudio Connect (только коммерческая версия) и ShinyProxy. (Список не является эксклюзивным.)

• Rplumber — это сервер API, а не блестящий сервер. Намерение состоит в том, чтобы для отдельных вызовов конечной точки HTTP(s), возможно, аутентифицированных, поддерживающих все, что поддерживает HTTP (post, get и т. д.). Это может быть выполнено различными способами, см. его страницу хостинга для вариантов.

• Rserve. Я меньше знаю об этом, но из того, что я испытал, мне не так повезло с интеграцией с корпоративными системами (где, например, важна аутентификация и точный контроль над авторизацией). Это позволяет почти необработанный доступ к R, поэтому это может быть не то, что вам нужно (особенно, когда цель состоит в том, чтобы предоставить клиентам, которые сами могут не быть сильными пользователями R).

• Следует обсуждать OpenCPU, но не как жизнеспособный кандидат для защиты вашего кода. Он очень похож на rplumber тем, что предоставляет конечные точки HTTP, но поддерживает конечные точки для каждой экспортируемой функции в каждом пакете, установленном в его библиотеке R. Сюда входит пакет base, так что получить исходный код любой функции, которую вы могли получить на консоли R, совсем не сложно. Я считаю, что это конструктивная особенность, даже если она полностью противоречит вашим намерениям защитить свой код.

• Все, что может вызвать R или Rscript. Это может быть PHP или mod_python или подобное. Любой язык обслуживания веб-страниц, который может exec("/usr/bin/Rscript",...), может взять свой вывод и передать его вызывающему агенту. (Например, внешний интерфейс PHP также может вызывать конечную точку opencpu, которая разрешает соединения только с хоста, обслуживающего PHP.)