2009-07-16 7 views
9

Ho un'applicazione proprietaria che vorrei distribuire a poche persone per il test, tranne che non vogliamo rivelare loro la fonte. L'applicazione è scritta in C++ per Linux. Si collega ai pacchetti prontamente disponibili sui repository Fedora/Ubuntu.Distribuire un'applicazione al pubblico in modo che possano compilare, senza rivelare la fonte

C'è un modo per elaborare l'origine su qualcosa di intermedio ... quindi distribuirlo e fare in modo che gli utenti eseguano una compilazione finale che in realtà compili e colleghi il codice intermedio alla loro piattaforma nativa.

Sto cercando di vedere se c'è qualche alternativa alla distribuzione di binari precompilati. Grazie.

+0

avevo una domanda molto simile http://stackoverflow.com/questions/1025494/obfuscating-c-c-code – hhafez

+0

Qual è la motivazione? C'è qualche ragione particolare per cui non può essere permesso di vedere la fonte? E qual è la ragione per non voler distribuire i binari precompilati? – jalf

risposta

4

È possibile elaborare il codice sorgente esistente per "manipolarlo"; fondamentalmente questo consiste nello spogliare tutti i commenti, e nel cambiare i nomi delle variabili in modo che siano minimi e rimuovere tutta la formattazione del codice sorgente. Il problema è che possono facilmente cambiare i nomi delle variabili e aggiungere formattazione e commenti; mentre non avranno lo stesso livello di informazioni nel codice sorgente risultante come te, avranno un codice sorgente completamente funzionale (perché è quello che hai distribuito a loro). Questo è l'unico modo per fare questo genere di cose.

+1

Questo è chiamato "sorgente protetta" ed era piuttosto comune per es. Software UNIX. – tialaramex

+0

Non puoi anche togliere le informazioni di debug da esso, o è questo che ti stai riferendo? – jkeys

+0

No, non è possibile eseguire il pre-strip delle informazioni di debug quando si distribuisce il codice sorgente (anche il codice sorgente alterato). Le informazioni di debug non vengono create fino a quando il binario non viene compilato. –

0

Se è C, è possibile utilizzare il compilatore clang, quindi eseguire il dump della rappresentazione intermedia LLVM. Se è C++, potrebbe essere necessario attendere un po 'finché il supporto C++ di clang non matura.

+0

La rappresentazione intermedia di LLVM è già stata compilata e quindi eventuali modifiche al build-time (ad esempio, dimensioni diverse di una struttura su un sistema di una persona da un'altra) non si rifletteranno nei binari risultanti. Quindi questo di solito funziona solo nei casi in cui i binari di distribuzione sarebbero stati altrettanto efficaci. – tialaramex

+0

Supponendo che l'unico obiettivo sia renderlo portabile su altre piattaforme, è abbastanza buono, giusto? – bdonlan

+1

Facciamo un esempio semplice. Linux e BSD hanno alcune strutture di sistema di dimensioni diverse. Quando si compila dalla rappresentazione intermedia di C a LLVM, il file di intestazione che dichiara queste strutture sulla piattaforma in cui si compilano (ad esempio, OpenBSD) deciderà quanto grande il compilatore pensa che la struttura sia. Quando si tenta di utilizzare la rappresentazione intermedia di LLVM per creare un binario in esecuzione su Linux, la dimensione della struttura sarà errata e il programma si bloccherà. Quindi, no, non mi sembra abbastanza buono. – tialaramex

5

Non è una risposta tecnica, ma ti fidi di loro abbastanza da chiedere una NDA firmata?

+1

Gli sviluppatori di giochi lo fanno con i beta online, ma questo è più alto rischio/premio più alto. – jkeys

5

Basta compilarlo per l'assemblatore. Può essere fatto usando l'opzione -S.

helloworld.cpp:

#include <iostream> 

using namespace std; 

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

E poi fare:

[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 

Usando questo metodo è possibile distribuire solo i .s-files che conterrà molto difficile da leggere assembler.

+1

Questo non risolve il problema della "piattaforma nativa", poiché è dipendente dalla macchina (ed eventualmente distro-dipendente, a seconda di quali intestazioni sono incluse). –

+2

Punto giusto. Credo comunque che potrebbe essere un'opzione in alcuni casi, quindi lascerò il post piuttosto che cancellarlo. –

+1

Anche se dipende dalla piattaforma, non ci sono così tante piattaforme là fuori - è molto probabile che tu possa farlo separatamente per tutte le piattaforme di interesse. – sharptooth

1

In breve, no. Per definizione, se possono compilarlo, hanno la tua fonte. Il meglio che puoi fare è aumentare il dolore di loro cercando di capirlo.

Sono d'accordo con John. Se hai un piccolo numero di clienti e ti fidi di loro, una NDA sarebbe un percorso migliore.

Un'altra cosa a cui ho appena pensato ... per quanto riguarda l'esecuzione del preprocessore e del compilatore, ma non l'assemblatore e il linker? Avresti bisogno di una copia per ogni linguaggio di assemblaggio specifico per l'architettura, ma presumo che sarebbe abbastanza doloroso da dissuadere l'editing mentre è abbastanza facile da compilare.

1

È possibile suddividere l'applicazione in due parti: la prima parte conterrà librerie precompilate con la funzionalità indipendente dal sistema operativo e la seconda conterrà alcune parti di fonti che gli utenti compilerebbero. In tal modo NVIDIA distribuisce i propri driver.

0

La soluzione migliore che riesco a fare è limitare il numero di piattaforme supportate e creare le proprie compilazioni o compilare un formato binario difficile da estrarre informazioni, ma l'utente puoi compilarlo nel loro formato nativo.

Personalmente vorrei andare con l'opzione 1.

Problemi correlati