Forum Programmation.shell erreur sed

Posté par  (site Web personnel) .
Étiquettes : aucune
1
28
mai
2012

Bonjour,

Je ne sais pas vraiment où placer ma question, je la place donc dans programmation/shell par défaut. Veuillez m’en excuser si c’était une erreur.

Voici donc le contexte : L’on m’a demandé de bidouiller un fichier PDF afin d’entraver la possibilité de pratiquer le copier/coller de texte depuis celui-ci. Oui, je sais, c’est mal, mais c’est pas pour mes productions. Et en plus, le défi technique m’a amusé.

En faisant quelques recherches, j’en suis venu à entrevoir deux types de solutions :
- La première, que je n’ai pas trop envie d’adopter, car j’en suis sûr ne marche pas avec toutes les liseuses de PDF, consisterait à utiliser une option apparemment spécifié dans le format PDF. Une sorte de DRM, comme ceux qui permettent de protéger le PDF par un mot de passe ou d’en empêcher l’impression.
- Le deuxième que j’ai retenu m’a paru plus amusant : il s’agit d’une sorte d’obfuscation, en faisant correspondre aux glyphes des caractères ne leur correspondant pas. Pour être plus clair, voici un exemple. Essayez de faire un copier/coller depuis ce PDF, vous verrez.
Donc, j’essaie de suivre ce tuto pour obtenir ce résultat. Il est assez bien fait, cependant à l’étape de l’application du script sed, il m’arrive une erreur que je n’arrive pas à corriger, et qui fait l’objet de ma question.
Le script sed que j’ai généré lors de l’étape précédente est copié ici : http://pastebin.com/Zr02qvZC

L’erreur que j’obtiens est la suivante :
> sed: fichier remap.sed ligne 2: commande `s' inachevée
Or il me semble que les commandes contenues dans le fichier sont correctes. Mais bon, je suis un peu un noob en sed, je ne l’ai utilisé que rarement, donc il se peut bien que ce soit une erreur de débutant. Donc merci d’avance pour votre indulgence.

Voilà ! J’espère que quelqu’un y verra plus clair que moi dans cette affaire.
Notez que ce forum pourrait être aussi une occasion pour discuter des différentes techniques pour obfusquer un texte… Si vous avez des suggestions…

  • # imagemagick

    Posté par  (site Web personnel) . Évalué à 2.

    convert fichier.pdf image.jpg
    convert image.jpg fichier.pdf
    
    

    wind0w$ suxX, GNU/Linux roxX!

    • [^] # Re: imagemagick

      Posté par  (site Web personnel) . Évalué à 1.

      J’y ai pensé, mais c’est moche. Même avec les meilleurs options de convert, on n’aura pas de rendu vectoriel comme ce que peut permettre l’inclusion de polices dans le PDF ;)
      Donc c’est pixelisé, et en plus ça prend une blinde de place en plus (x10 voir plus)

      Donc solution sale à n’utiliser qu’en dernier recours !

      La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.

    • [^] # Re: imagemagick

      Posté par  (site Web personnel) . Évalué à 1.

      Je suis François sur ces critiques, mais au lieu d'une image JPEG on peut opter pour un fichier DJVU.

      • [^] # Re: imagemagick

        Posté par  (site Web personnel) . Évalué à 1.

        Quand je teste la conversion en djvu avec convert, le résultat est tout pixelisé…

        La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.

        • [^] # Re: imagemagick

          Posté par  (site Web personnel) . Évalué à 2. Dernière modification le 29/05/12 à 22:20.

          Quand je teste la conversion en djvu avec convert, le résultat est tout pixelisé…

          Cela vient probablement de la `-density' du canvas sur lequel convert fait le dessin. Prendre une -density de 300, 600 ou 1200 pour avoir un meilleur résultat.

          Chez moi j'utilise

          convert -density 1200 fichier.pdf -monochrome bitonal-%05d.tiff
          for bitonal in bitonal*.tiff; do
              cjb2 "$bitonal" "${bitonal%.tiff}.djvu"
          done
          djvm -c /tmp/output.pdf *djvu
          
          
  • # Il manque des informations

    Posté par  . Évalué à 3.

    Quelle commande utilises-tu ?
    As-tu testé avec un fichier "remap" contenant quelques lignes ?

    Super astuce.
    Par contre elle ne fonctionne qu'avec les polices complètes. Qu'elles soient sur l'ordinateur du lecteur ou embaquées dans le pdf.

    • [^] # Re: Il manque des informations

      Posté par  (site Web personnel) . Évalué à 1.

      J’en étais à la commande "sed -f remap.sed scramble.enc >crypt.enc" du tuto.

      Suite à la remarque de syntaxerror, cette commande ne retourne plus d’erreur, mais je n’arrive toujours pas à mes fins : Lors de l’ultime ré-assemblage de la police (t1asm -b klbr.raw klbr.pfb), il me sort « t1asm: couldn't find charstring start command »…
      Quelque-chose a du mal se passer, mais j’ai du mal à voir où…
      Pourtant, un diff entre klbr.raw et lbr.raw me montre bien que les modifs ont eu l’air de se faire comme on voulait…

      La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.

  • # commande `s' inachevée

    Posté par  . Évalué à 5.

    si je ne m'abuse il faut terminer la commande de substitution: s/x/y/
    ensuite j'ai une erreur sur la fin du groupe de commande, résolue en terminant par ";"

    sed -e 's,@$,@/,;s/^\}$/\};/' < remap.sed

    • [^] # Re: commande `s' inachevée

      Posté par  (site Web personnel) . Évalué à 2.

      Ton pseudo est très adapté à la réponse :)

    • [^] # Re: commande `s' inachevée

      Posté par  . Évalué à 0.

      Si je ne me trompe lorsqu'on utilise un caractère autre que / comme séparateur il faut protéger d'un \ le premier caractère séparateur.

      sed -e 's\,@$,@/,;s/^\}$/\};/' < remap.sed
      
      
      • [^] # Re: commande `s' inachevée

        Posté par  (site Web personnel) . Évalué à 1.

        Euh… Ta commande me retourne une erreur :
        sed: -e expression n°1, caractère 19: `}' inattendu

        La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.

      • [^] # Re: commande `s' inachevée

        Posté par  . Évalué à 1.

        il semble que sed prenne le premier caractère comme séparateur quel qu'il soit

        http://www.grymoire.com/Unix/Sed.html#uh-2

        Bien sûr il faut parfois protéger les caractères de l'interprétation par le shell par exemple quand l'expression est entre doubles quotes (guillemets?), mais ce sont tous les caractères et non le premier seulement. Ici pas de problème entre apostrophes simples.

    • [^] # Re: commande `s' inachevée

      Posté par  (site Web personnel) . Évalué à 1.

      Effectivement après application de ton expression, l’erreur disparait.
      Mais je tombe sur une autre erreur plus tard (Cf. https://linuxfr.org/nodes/94289/comments/1354258)

      La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.

  • # U+200F

    Posté par  (site Web personnel) . Évalué à 3.

    Sinon, j’ai eu une autre idée qui m’est venu à l’esprit, c’est d’utiliser une propriété d’un caractère unicode qui permet de lire une chaîne de caractère à l’envers.
    On peut l’obtenir en CSS comme ça :
    span.baddirection { unicode-bidi:bidi-override; direction: rtl; }

    Concrètement, pour voir ce que ça fait, essayez de copier-coller l’adresse mail de ce cher Seb Sauvage depuis sa page de contact http://sebsauvage.net/apropos.html

    Après je ne sais pas si c’est possible de faire ça, même avec XeTeX qui est censé supporter complètement l’Unicde…

    C’est pas de la grosse obfuscation, mais ce serait bien propre à emmerder les n00bs…

    La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.