2009-07-16 4 views
9

Ich habe eine proprietäre Anwendung, die ich an ein paar Leute zum Testen austeilen möchte, außer wir wollen nicht die Quelle zu ihnen offenbaren. Die Anwendung ist in C++ für Linux geschrieben. Es verbindet sich mit leicht verfügbaren Paketen in den Fedora/Ubuntu-Repos.Verteilen Sie eine Anwendung an die Öffentlichkeit, so dass sie kompilieren können, ohne die Quelle zu offenbaren

Gibt es eine Möglichkeit, die Quelle zu etwas intermediate zu verarbeiten ... dann verteilen Sie es und lassen Sie die Benutzer eine abschließende Kompilierung durchführen, die den Zwischencode tatsächlich kompiliert und mit ihrer nativen Plattform verbindet.

Ich versuche zu sehen, ob es eine Alternative zum Verteilen von vorkompilierten Binärdateien gibt. Vielen Dank.

+0

Ich habe eine sehr ähnliche Frage hatte http://stackoverflow.com/questions/1025494/obfuscating-c-c-code – hhafez

+0

Was ist die Motivation? Gibt es einen besonderen Grund, warum sie die Quelle nicht sehen dürfen? Und warum nicht vorkompilierte Binaries verteilen wollen? – jalf

Antwort

4

Sie können den vorhandenen Quellcode verarbeiten, um ihn zu "verfälschen"; Im Grunde besteht das darin, alle Kommentare zu entfernen und die Variablennamen so zu ändern, dass sie minimal sind und alle Formatierungen des Quellcodes aussparen. Das Problem ist, dass sie die Variablennamen relativ einfach wieder ändern und Formatierungen und Kommentare hinzufügen können. Während sie im Quellcode nicht das gleiche Informationsniveau haben wie Sie, haben sie einen vollständig funktionsfähigen Quellcode (weil Sie das an Sie verteilt haben). Dies ist der einzige Weg, um so etwas zu tun.

+1

Dies wird als "umhüllte Quelle" bezeichnet und war z. UNIX-Software. – tialaramex

+0

Können Sie die Debugging-Informationen nicht entfernen, oder beziehen Sie sich darauf? – jkeys

+0

Nein, Sie können die Debugging-Informationen nicht vorab entfernen, wenn Sie den Quellcode (sogar den Quellcode) verteilen. Die Debugging-Informationen werden erst erstellt, wenn die Binärdatei kompiliert wurde. –

0

Wenn es C ist, können Sie den clang Compiler verwenden und dann die LLVM-Zwischendarstellung ausgeben. Wenn es C++ ist, müssen Sie möglicherweise eine Weile warten, bis die C++ - Unterstützung von Clang reifer wird.

+0

Die LLVM-Zwischendarstellung wurde bereits kompiliert, und daher werden Änderungen an der Buildzeit (z. B. unterschiedliche Größe einer Struktur auf einem Personensystem von einem anderen) nicht in den resultierenden Binärdateien wiedergegeben. Dies funktioniert normalerweise nur in Fällen, in denen die Verteilung von Binärdateien genauso effektiv gewesen wäre. – tialaramex

+0

Angenommen, das einzige Ziel ist, es auf andere Plattformen portierbar zu machen, ist das gut genug, oder? – bdonlan

+1

Nehmen wir ein einfaches Beispiel. Linux und BSD haben einige Systemstrukturen, die unterschiedliche Größen haben. Wenn Sie von C zu LLVMs intermediärer Repräsentation kompilieren, wird die Header-Datei, die diese Strukturen auf der Plattform deklariert, auf der Sie kompilieren (zB OpenBSD) entscheiden, wie groß der Compiler die Struktur ist. Wenn Sie versuchen, diese LLVM-Zwischendarstellung zu verwenden, um unter Linux eine laufende Binärdatei zu erstellen, ist die Strukturgröße falsch und Ihr Programm stürzt ab. Also, nein, scheint mir nicht gut genug zu sein. – tialaramex

5

Es ist keine technische Antwort, aber trauen Sie ihnen genug, um nur für eine unterschriebene NDA zu fragen?

+1

Spieleentwickler machen das mit Online-Betas, aber das ist ein höheres Risiko/höhere Belohnung. – jkeys

5

Kompilieren Sie es einfach zu Assembler. Kann mit der Option -S durchgeführt werden.

Helloworld.cpp:

#include <iostream> 

using namespace std; 

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

Und dann tun:

[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 

Mit dieser Methode können Sie nur die .s-Dateien verteilen können, die sehr schwer enthält Assembler zu lesen.

+1

Dies löst das Problem "native Plattform" nicht, da es maschinenabhängig ist (und möglicherweise von der Distribution abhängig ist, je nachdem, welche Header enthalten sind). –

+2

Messepunkt. Ich glaube immer noch, dass es in einigen Fällen eine Option sein könnte, also werde ich die Post verlassen, anstatt sie zu löschen. –

+1

Obwohl es plattformabhängig ist, gibt es nicht so viele Plattformen - Sie können dies höchstwahrscheinlich für alle interessanten Plattformen separat durchführen. – sharptooth

1

Kurz gesagt, nein. Per Definition, wenn sie es kompilieren können, haben sie Ihre Quelle. Das Beste, was du tun kannst, ist, den Schmerz zu erhöhen, wenn du versuchst, es zu verstehen.

Ich stimme John zu. Wenn Sie eine kleine Anzahl von Clients haben und ihnen vertrauen, wäre eine NDA eine bessere Route.

Eine andere Sache, über die ich gerade nachgedacht habe ... wie wäre es, nur den Präprozessor und den Compiler auszuführen, aber nicht den Assembler und den Linker? Sie würden eine Kopie für die Assemblersprache jeder spezifischen Architektur benötigen, aber ich nehme an, dass dies schmerzhaft genug wäre, um das Editieren abzuwenden, während es einfach genug ist, es zu kompilieren.

1

Sie könnten Ihre Anwendung in zwei Teile unterteilen: der erste Teil enthält vorkompilierte Bibliotheken mit der vom Betriebssystem unabhängigen Funktionalität, und der zweite enthält einige Teile der Quellen, die Benutzer kompilieren würden. Auf diese Weise vertreibt NVIDIA ihre Treiber.

0

Die beste Lösung, die ich finden kann, ist entweder die Anzahl der unterstützten Plattformen zu begrenzen und Ihre eigenen Kompilationen zu machen, oder kompilieren zu einem binären Format, von dem Informationen schwer zu extrahieren ist, aber der Benutzer kann dies in ihrem ursprünglichen Format kompilieren.

Persönlich würde ich mit der Option gehen 1.

Verwandte Themen