2009-07-16 3 views
9

У меня есть собственное приложение, которое я хотел бы передать нескольким людям для тестирования, за исключением того, что мы не хотим раскрывать им источник. Приложение написано на C++ для Linux. Он связывается с легкодоступными пакетами в репозиториях Fedora/Ubuntu.Распространяйте приложение для общественности, чтобы они могли компилировать, не раскрывая источник

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

Я пытаюсь посмотреть, есть ли альтернатива распространению предварительно скомпилированных двоичных файлов. Благодарю.

+0

У меня был очень похожий вопрос http://stackoverflow.com/questions/1025494/obfuscating-c-c-code – hhafez

+0

Что мотивация? Есть ли какая-то конкретная причина, почему им не разрешено видеть источник? И в чем причина нежелания распространять прекомпилированные двоичные файлы? – jalf

ответ

4

Вы можете обработать существующий исходный код, чтобы «разбить» его; в основном это состоит в том, чтобы удалить все комментарии и изменить имена переменных, чтобы они были минимальными и удалили все форматирование исходного кода. Проблема в том, что они могут относительно легко изменить имена переменных назад и добавить форматирование и комментарии; в то время как у них не будет одинакового уровня информации в исходном исходном коде, как у вас, они будут иметь полностью функциональный исходный код (потому что это то, что вы им распространяли). Речь идет о единственном способе делать подобные вещи.

+1

Это называется «окутанным источником», и это было довольно распространено, например. UNIX. – tialaramex

+0

Не могли бы вы также удалить из нее отладочную информацию или это то, о чем вы говорите? – jkeys

+0

Нет, вы не можете предварительно отлаживать информацию об отладке при распространении исходного кода (даже искаженный исходный код). Информация об отладке не создается, пока не будет скомпилирована двоичная информация. –

0

Если это C, вы можете использовать компилятор clang, а затем сбросить промежуточное представление LLVM. Если это C++, вам может потребоваться некоторое время, пока созревание Cang Cang не созреет.

+0

Промежуточное представление LLVM уже скомпилировано, и, таким образом, любые изменения времени сборки (например, разные размеры структуры в системе с одним человеком из другого) не будут отражены в полученных двоичных файлах. Таким образом, это обычно работает только в тех случаях, когда распространение двоичных файлов было бы столь же эффективным. – tialaramex

+0

Предполагая, что единственная цель - сделать его переносной на другие платформы, это достаточно хорошо, не так ли? – bdonlan

+1

Давайте рассмотрим простой пример. Linux и BSD имеют некоторые системные структуры разных размеров. Когда вы компилируете из промежуточного представления C в LLVM, заголовочный файл, который объявляет эти структуры на платформе, на которой вы компилируете (скажем, OpenBSD), будет определять, насколько большой компилятор считает структуру. Когда вы пытаетесь использовать промежуточное представление LLVM для создания исполняемого двоичного файла в Linux, размер структуры будет неправильным, и ваша программа выйдет из строя. Итак, нет, для меня это не кажется достаточно хорошим. – tialaramex

5

Это не технический ответ, но вы доверяете им достаточно, чтобы просто попросить подписанный NDA?

+1

Разработчики игр делают это с онлайн-бета-версиями, но это более высокий риск/более высокая награда. – jkeys

5

Просто скомпилируйте его на ассемблере. Может быть сделано с использованием опции -S.

helloworld.cpp:

#include <iostream> 

using namespace std; 

int main(void) 
{ 
    cout << "Hello World" << endl; 
    return 0; 
} 

А потом сделать:

[email protected] /home/emil/dev/assemblertest $ g++ -S -o helloworld.s helloworld.cpp 
[email protected] /home/emil/dev/assemblertest $ g++ -o helloworld helloworld.s 
[email protected] /home/emil/dev/assemblertest $ ./helloworld 
Hello World 

Используя этот метод, вы можете распространять только .S-файлы, которые содержат очень трудно читать ассемблер.

+1

Это не решит проблему «родной платформы», поскольку она зависит от машины (и, возможно, зависит от дистрибутива, в зависимости от того, какие заголовки включены). –

+2

Справедливая точка. Я по-прежнему считаю, что в некоторых случаях это может быть вариант, поэтому я оставлю пост, а не удалю его. –

+1

Несмотря на то, что платформа зависит от платформы, там не так много платформ - вы, скорее всего, можете сделать это отдельно для всех платформ, представляющих интерес. – sharptooth

1

Одним словом, нет. По определению, если они могут скомпилировать его, у них есть свой источник. Лучшее, что вы можете сделать, это увеличить боль от них, пытаясь понять это.

Я согласен с Джоном. Если у вас есть небольшое количество клиентов и им доверяют, NDA будет лучшим маршрутом.

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

1

Вы можете разделить приложение на две части: первая часть будет содержать предварительно скомпилированные библиотеки с независимой от ОС функциональностью, а вторая - небольшими частями источников, которые будут компилироваться пользователями. Таким образом, NVIDIA распространяет свои драйверы.

0

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

Лично я бы с вариантом 1.

 Смежные вопросы

  • Нет связанных вопросов^_^