Verschlüsselungsprogramm letztes Zeichen fehlt



  • Hallo, ich habe ein Problem mit diesem Programm:

    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    
    int main(int argc, char *argv[])
    {
        char src_filename[61];
        char dst_filename[61];
        char key_filename[61];
        int block[8];
        int *block_ptr = block;
        int key[8];
        FILE *src_fp, *dst_fp, *key_fp;
        int ch;
        int i=0;
    
        if (argc < 4)
        {
            puts("syntax: src_filename dst_filename key_filename");
            return 0;
        }
        strncpy(src_filename, argv[1], 60);
        strncpy(dst_filename, argv[2], 60);
        strncpy(key_filename, argv[3], 60);
    
        src_fp = fopen(src_filename, "rb");
        dst_fp = fopen(dst_filename, "wb");
        key_fp = fopen(key_filename, "rb");
        if (src_fp == NULL || dst_fp == NULL || key_fp == NULL)
        {
            puts("error, file could not be opened!");
            exit(1);
        }
    
        while ((ch = fgetc(key_fp) != EOF) && i < 8)
        {
            key[i] = ch;
            i++;
        }
        if (i < 8)
        {
            puts("error, the key must have a length of 8 chars!");
            exit(1);
        }
        fclose(key_fp);
    
        while ((ch = fread(block_ptr, sizeof (int), 8, src_fp)) != 0)
        {
            for (i=0;i<ch;i++)
                block_ptr[i] ^= key[i];
            fwrite(block_ptr, sizeof(int), ch, dst_fp);
        }
        fclose(src_fp);
        fclose(dst_fp);
        puts("process completed!");
        return 0;
    }
    

    Es ließt jeweils 8 int's aus einer Datei, verknüpft sie mit den 8 int's vom Schlüssel und schreibt sie in eine neue Datei. Allerdings fehlt nach dem Codieren+Decodieren immer das letzte Zeichen.
    Und wenn ich es mit einer Pdf-Datei mache wird zwar der Index korrekt angezeigt aber kein Text. (kp ob es mit dem letzten Zeichen zusammenhängt.)
    Es ist bestimmt was total simples aber ich steh gerade auf dem Schlauch, weiß jemand woran es liegt? Schonmal danke im Voraus



  • Fehlt da nicht der "Decodierteil"?

    Schwer sonst eine Aussage zu machen.

    PS: warum kopierst Du die Kommandozeilenargumente?


  • Mod

    Deine Dateien werden wohl kein Vielfaches von sizeof(int) als Zeichenzahl haben. Wenn du dann versuchst, das in sizeof(int)-Blöcken zu lesen (Zeile 48), dann wird das beim letzten, unvollständigen Block fehlschlagen.

    Wahrscheinlich ist dieses Lesen in sizeof(int)-Stückchen sowieso nicht das, was du willst. Wenn du mal deine verschlüsselten Daten anguckst, wirst du feststellen, dass nur jedes vierte Zeichen (oder was immer sizeof(int) bei dir ist) verschlüsselt wird. Mit chars kann man auch ganz wunderbar rechnen.



  • Furble Wurble schrieb:

    Fehlt da nicht der "Decodierteil"?

    Ahh. XOR und so...
    Ich Depp.

    *schäm*



  • @Furble Wurble
    Ich kopiere sie um Pufferüberläufe zu verhindern

    @SeppJ
    Jetzt wo du es sagst fällt es mir auch auf, nur was mache ich dann mit dem Rückgabewert von fgetc?
    Was ist wenn der Klartext verknüpft mit dem Schlüssel nicht mehr in ein char passt?


  • Mod

    Bitmapper schrieb:

    @SeppJ
    Jetzt wo du es sagst fällt es mir auch auf, nur was mache ich dann mit dem Rückgabewert von fgetc?

    In einen char kopieren. Wichtig: Erst nachdem du auf EOF geprüft hast, denn EOF passt eventuell nicht in einen char. Sprich: Mach key und block zu unsigned char und lass ch als int.

    Was ist wenn der Klartext verknüpft mit dem Schlüssel nicht mehr in ein char passt?

    Das kann nicht passieren, denk mal drüber nach.

    Ich kopiere sie um Pufferüberläufe zu verhindern

    😕 Was soll denn da wie für ein Überlauf verhindert werden? Das einzige was da passieren kann, ist, dass die Namen eben nicht in deine Arrays passen und das Programm dann wegen der unnötigen Kopien fehlschlägt. 60 Zeichen ist nun nicht gerade großzügig für Dateinamen.

    PS: block_ptr ist übrigens auch komplett überflüssig.



  • Ok, danke so funktioniert es jetzt 🙂
    @SeppJ Ich dachte, dass es mit fopen probleme gibt wenn die Pfadangaben zu lange sind

    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    
    int main(int argc, char *argv[])
    {
        char block[8];
        char key[8];
        FILE *src_fp, *dst_fp, *key_fp;
        int ch;
        int i=0;
    
        if (argc < 4)
        {
            puts("syntax: src_filename dst_filename key_filename");
            return 0;
        }
    
        src_fp = fopen(argv[1], "rb");
        dst_fp = fopen(argv[2], "wb");
        key_fp = fopen(argv[3], "rb");
        if (src_fp == NULL || dst_fp == NULL || key_fp == NULL)
        {
            puts("error, file could not be opened!");
            exit(1);
        }
    
        while ((ch = fgetc(key_fp) != EOF) && i < 8)
        {
            key[i] = ch;
            i++;
        }
        if (i < 8)
        {
            puts("error, the key must have a length of 8 chars!");
            exit(1);
        }
        fclose(key_fp);
    
        while ((ch = fread(block, sizeof (char), 8, src_fp)) != 0)
        {
            for (i=0;i<ch;i++)
                block[i] ^= key[i];
            fwrite(block, sizeof(char), ch, dst_fp);
        }
        fclose(src_fp);
        fclose(dst_fp);
        puts("process completed!");
        return 0;
    }
    


  • Bitmapper schrieb:

    Ich dachte, dass es mit fopen probleme gibt wenn die Pfadangaben zu lange sind

    Wenn dein Betriebssystem nicht mit so langen Pfadangaben umgehen kann, kann es diese Datei auch nicht geben.

    Zudem solltest du dir die Referenz zu strncpy mal genau durchlesen. Gerade der Teil, wenn die Quelle länger als das n ist.
    Dann wird der Stringterminator ('\0') nicht mitkopiert. Du hast dann keinen gültigen C-String mehr.

    Also viel mehr Schaden als Nutzen.

    strncat verhält sich da wieder anders.


  • Mod

    DirkB schrieb:

    Bitmapper schrieb:

    Ich dachte, dass es mit fopen probleme gibt wenn die Pfadangaben zu lange sind

    Wenn dein Betriebssystem nicht mit so langen Pfadangaben umgehen kann, kann es diese Datei auch nicht geben.

    Ich glaube, er meint eine bösartige Benutzereingabe. Vermutlich geht eine C-Standardbibliothek damit aber weitaus geschickter um, als der Threadersteller. Du hast ja selber beschrieben, warum das strncpy hier mehr schadet als nützt.


Anmelden zum Antworten