[Qt] In meinen exe-dateien sind offene quellcodes?



  • Lutz schrieb:

    das ganze ding nochmal mit upx gepackt und man kann da nix mehr verändern

    Man muss nur entpacken. Dann kann man wieder verändern wie man lustig ist.



  • Und bringen solche Packer denn keine Nachteile oder so?

    längere Startzeiten

    Aber wo ist das Problem, dass der Text der Labels da steht? Ist doch egal ob da jemand was ändert. Ansonsten kannst du dir auch mit xor oder so was helfen, dass hält dann unerfahrene Leute davon ab die Labels zu ändern.

    Das die Qt Klassen in dem Binäry stehen, kann damit zusammenhängen ob du

    a) die Library in der Debug Version statisch linkst oder
    b) du dynamisch linkst



  • kingruedi schrieb:

    a) die Library in der Debug Version statisch linkst oder
    b) du dynamisch linkst

    Also ich habe eigentlich auf "Win32 Release" gestellt, oder was meinst du? Wie/Wo kann man das denn umstellen in Visual Studio 2003 .NET ?



  • kingruedi schrieb:

    Und bringen solche Packer denn keine Nachteile oder so?

    längere Startzeiten

    Was ist wohl schneller?
    a) Eine Große Datei langsam von der Festplatte zu laden un dann auszuführen
    oder
    b) Eine deutlich kleinere Datei langsam von der Fetsplatte zu laden und dann blitzschnell von einem ständig unterforderten 3GHz Intel Pentium 4 mit Hyper Threading Technologie im DDR400 CL2 Arbeitsspeicher zu entpacken und dann auszuführen?

    für die AMD fetischisten:
    streiche: Intel Pentium 4 mit Hyper Threading Technologie
    setze: AMD Athlon 64 XP



  • D@niel $chumann schrieb:

    kingruedi schrieb:

    Und bringen solche Packer denn keine Nachteile oder so?

    längere Startzeiten

    Was ist wohl schneller?
    a) Eine Große Datei langsam von der Festplatte zu laden un dann auszuführen
    oder
    b) Eine deutlich kleinere Datei langsam von der Fetsplatte zu laden und dann blitzschnell von einem ständig unterforderten 3GHz Intel Pentium 4 mit Hyper Threading Technologie im DDR400 CL2 Arbeitsspeicher zu entpacken und dann auszuführen?

    für die AMD fetischisten:
    streiche: Intel Pentium 4 mit Hyper Threading Technologie
    setze: AMD Athlon 64 XP

    Entschuldigung, aber ich verstehe nicht ganz worauf du hinaus möchtest?



  • D@niel $chumann schrieb:

    Was ist wohl schneller?
    a) Eine Große Datei langsam von der Festplatte zu laden un dann auszuführen
    oder
    b) Eine deutlich kleinere Datei langsam von der Fetsplatte zu laden und dann blitzschnell von einem ständig unterforderten 3GHz Intel Pentium 4 mit Hyper Threading Technologie im DDR400 CL2 Arbeitsspeicher zu entpacken und dann auszuführen?

    simples lesen ist deutlich schneller.

    a) muss man bei UPX erst UPX laden, was sich initialisiert und dann mit dem entpacken anfängt
    b) ist lesen von Festplatte nicht so langsam

    Meine Messung

    Povray-3.5: 1.1MB, uncompressed
    Povray-3.5-compressed: 490Kb, upx -5
    
    Povray-3.5 laufzeit (mit sh-time gemessen): ~15s
    Povray-3.5-compressed luafzeit (mit sh-time gemessen): ~53s
    

    3.5 mal so langsam!



  • kingruedi schrieb:

    3.5 mal so langsam!

    Das liegt doch nur daran, dass du immer noch keinen 3GHz Intel Pentium 4 mit Hyper Threading Technologie und DDR400 CL2 Arbeitsspeicher nutzt. 😃 Dein Rechner ist einfach veraltet! 😉



  • Ein anständiges Betriebssystem (und sogar auch Wndows) lädt nur die teile der EXE in den Speicher, die wirklich benötigt werden. Ob das EXE-Packer auch so arbeiten?
    Außerdem haben gepackte EXEn ein größeres Working set - schließlich muß neben dem ungepackten noch der gepackte Code in den Speicher. Kein Problem für kleine Programme, aber wenn der Speichermanager sowieso schon swappen muß (oder nah dran ist), ist das sozusagen der Todesstoß.

    Kommt also sehr auf die Anwendung an.



  • Zido schrieb:

    kingruedi schrieb:

    a) die Library in der Debug Version statisch linkst oder
    b) du dynamisch linkst

    Also ich habe eigentlich auf "Win32 Release" gestellt, oder was meinst du? Wie/Wo kann man das denn umstellen in Visual Studio 2003 .NET ?

    Das hilft mir immer noch nicht bei meinem Problem weiter???



  • sorry, ist leider OT
    @kingruedi
    Mit was hast du die Zeit gemessen? Ist das was linuxstiges?
    Also ich hab jetzt mal nero.exe gepackt von 9.240KB zu 2.789KB wenn ich jetzt noch eine schnellere CPU hätte... Immerhin zeigt mir der TaskManager mehr als 2MB weniger Speichernutzung an.
    Naja ein modernes System hat natürlich auch eine schnelle Festplatte, hast schon recht (Am längsten dauert wohl ehh die Zugriffszeit). Aber wenn man noch eine alte und besagten super-Prozessor hat, könnte es unter Umständen (wenn die Festplatte z.B. stark fragmentiert ist) schon was bringen.



  • Mit was hast du die Zeit gemessen? Ist das was linuxstiges?

    jo, dass einfache time-Kommando

    Aber wenn man noch eine alte und besagten super-Prozessor hat, könnte es unter Umständen (wenn die Festplatte z.B. stark fragmentiert ist) schon was bringen.

    das lohnt nicht wirklich.

    UPX ist sinnvoll, wenn man sich eine kleine Disketten oder CD Distribution bastelt.

    Festplatten sind mittlerweile so groß, dass die paar MB nicht auffallen und sich der Aufwand nicht lohnt.



  • Zido schrieb:

    Zido schrieb:

    kingruedi schrieb:

    a) die Library in der Debug Version statisch linkst oder
    b) du dynamisch linkst

    Also ich habe eigentlich auf "Win32 Release" gestellt, oder was meinst du? Wie/Wo kann man das denn umstellen in Visual Studio 2003 .NET ?

    Das hilft mir immer noch nicht bei meinem Problem weiter???

    Hallo???



  • Was willst du da verhinden. QT wurde so kompiliert. Es gibt da die Headerdateien, die LIB und die DLL. Wenn da was drinsteht kannst du es nicht ändern. Wenn in deinem Programm was drin steht (Debuginfos) und du hast mit Release kompiliert solltest du dir deine Projekteinstellungen ansehen. Das man Release erstellt heißt nicht das auch Release erstellt wird. Release und Debug sind nur Vorgaben die sich aber ändern lassen. IMHO kann man das genauso umgekehrt einstellen.



  • sind denn wirklich debug-infos drin? (,die man so einfach gar nicht erkennen kann!) oder siehste nur deine stringliterale und die klassennamen und die importierten funktionsnamen?
    die stringliterale sieht man natürlich, denn der compiler kann die nicht sinnvoll in was anderes kompilieren.
    die importierten funktionsnamen siehste, weil intern dein programm auch nur anhand der funktionsnamen sich die funktionszeiger aus ner *.dll holt.
    die namen der klassen siehste, wenn rtti benutzt wird. die legt er auch als strings ab.
    nichts davon ist aber schlimm und würde auch nur ansatzweise erlauben, daß der kunde deinen code entschlüsselt.
    die klassennamen alleine sind doch kein hinreichender tip, wie dein programm funktioniert.
    stringliterale mit upx schützen geht nicht gegen jemanden, der es versucht und mehr als 15 minuten zeit hat. willste die schützen, dann mach das bei vereinzelten strings durch verschlüsseln und signieren.
    also statt

    char copyRightMessage[]="(c) by Hans Mustermann";
    ...
    cout<<copyRightMessage<<endl;
    

    jetzt lieber

    int hash(char const* str){
       unsigned int h=4711;
       while(*str){
          h=h*31+*str;
          ++str;
       }
       return h;
    }
    char copyRightMessage[]="(c) by Hans Mustermann";
    int const copyRightMessageHash=635472;
    ...
    if(hash(copyRightMessage)!=copyRightMessageHash) delete wasWichtiges;
    cout<<copyRightMessage<<endl;
    

Anmelden zum Antworten