Forum général.cherche-logiciel Retrouver un algorithme de checksum ?

Posté par  .
Étiquettes : aucune
0
15
mar.
2007
Bonjour,

Je suis très embêté, j'ai un logiciel (très propriétaire) qui pilote une machine outil, et qui a la bonne idée d'ajouter un checksum sur 16 bits à tous les fichiers de configuration pour empêcher leur modification.
Or j'ai besoin de pouvoir modifier ces fichiers.

J'ai testé quelques algorithmes à la main, mais sans succès.

Le logiciel tournait à l'origine sur un unix SCO, puis maintenant sous windows, où il utilise une dll nommée crc.dll

Je penche donc pour un algorithme de type CRC assez standard. Quelqu'un aurait-il entendu parler d'un programme permettant d'attaquer en force brute ce type de verrouillage ?

Sinon, je peux aussi le faire en perl avec digest::CRC, mais mes connaissances sont assez limités, genre des moulinettes d'admin système, et dans ce cas quelques exemples seraient les bienvenus !

  • # CRC, division, toussa.

    Posté par  . Évalué à 3.

    Je suis très embêté, j'ai un logiciel (très propriétaire) qui pilote une machine outil, et qui a la bonne idée d'ajouter un checksum sur 16 bits à tous les fichiers de configuration pour empêcher leur modification. Or j'ai besoin de pouvoir modifier ces fichiers.


    C'est-à-dire que j'aurais tendance à dire que s'il y a un CRC à la fin de tes fichiers pour empêcher leur modif', c'est pour une bonne raison ! Ce qu'il faut, c'est retrouver l'outil servant à faire les modifications, pas un moyen de contourner les protections.

    Ca a l'air évident, dit comme çà, mais c'est effrayant le nombre de fois que j'ai été obligé de le rappeler, même professionnellement.



    Si tu es ABSOLUMENT CERTAIN de devoir modifier ces fichiers toi-même, et que tu peux le démontrer scientifiquement :-), sache que la plupart du temps, les CRC en informatique, sur des valeurs binaires, donc, se résument en fait à une grosse division simplifiée (avec des XOR, sans la retenue) des données, vues comme un seul gros nombre, par une valeur fixe, formellement le polynome générateur, si je ne me trompe pas (je suis un peu rouillé, pardon si je dis trop de conneries).

    L'idée est donc de retrouver cette valeur. Comme elle est de toute évidence passée à la fonction de CRC, autant pour le calcul initial que pour son contrôle, le plus simple reste à mon avis un bon coup de déboggueur ou un truss/strace sous Unix pour récupérer les arguments transmis.

    • [^] # Re: CRC, division, toussa.

      Posté par  . Évalué à 2.

      C'est-à-dire que j'aurais tendance à dire que s'il y a un CRC à la fin de tes fichiers pour empêcher leur modif', c'est pour une bonne raison ! Ce qu'il faut, c'est retrouver l'outil servant à faire les modifications, pas un moyen de contourner les protections.

      Ca a l'air évident, dit comme çà, mais c'est effrayant le nombre de fois que j'ai été obligé de le rappeler, même professionnellement.

      Bien sûr qu'il y a une bonne raison : vendre des consommables 10 fois plus cher que la matière première standard, et des mises à jour du soft à 20 K¤ !

      En pratique, il s'agit d'une machine ancienne ( 10 ans) utilisée pour de l'enseignement et de la recherche, qui n'est plus sous contrat de maintenance, et le constructeur refuse de nous proposer la version n-1 du soft, qui reste compatible avec le matériel. Nous n'avons donc plus d'autre choix que de bidouiller...

      Pour les CRC, je pense également qu'il suffit de trouver le polynome, peut-être aussi la valeur d'initialisation, qui sont sur 16 bits, cela fait donc un nombre raisonnable de possiblilités en force brute.

      Mes compétences en deboggage sous windows étant nulles, je vais effectivement essayer d'intercepter les appels à la DLL sous wine, pour voir ce qu'il se passe.

      • [^] # Re: CRC, division, toussa.

        Posté par  . Évalué à 2.

        Tu peux déjà regarder les fonctions exportées par la crc.dll. (
        http://www.dependencywalker.com/ ). Si il n'y en a qu'une et qu'elle est nommée "calculerCRC", tu pourra sans doute l'appeler toi meme et calculer la nouvelle crc.

        • [^] # Re: CRC, division, toussa.

          Posté par  . Évalué à 1.

          oK, merci, j'ai cela :


          CCRC::CCRC(class CCRC const &)
          CCRC::CCRC(void)
          CCRC::~CCRC(void)
          class CCRC & CCRC::operator=(class CCRC const &)
          const CCRC::`vftable'
          unsigned long CCRC::CalculateSupportsCRC(int)
          int CCRC::CompareCRC(unsigned long,class CString)
          unsigned long CCRC::calcCRC(char *,int)
          int CCRC::writeCrcValue(class CString)

          je devrais donc pouvoir m'en servir pour créer un .h, je vais donc essayer de trouver quelqu'un qui puisse compiler sous windows, et faire des essais

          • [^] # Re: CRC, division, toussa.

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

            Tu n'as pas un désassembleur ?

            Ca pourrait aider à trouver les infos de base sur le calcul CRC...

            Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

            • [^] # Re: CRC, division, toussa.

              Posté par  . Évalué à 1.

              Houla, mes compétences en assembleur ont dû s'arrêter au Z80...

              • [^] # Re: CRC, division, toussa.

                Posté par  . Évalué à 2.

                Les processeurs récents ne sont pas beaucoup plus compliqués, et c'est ça qui est bien, d'ailleurs. Bon, évidemment, il y a le mode protégé, les registres machine, etc. mais dans le principe, c'est quand même toujours la même chose.

          • [^] # Re: CRC, division, toussa.

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

            Euh... Je dis peut être une bêtise, mais serait-ce possible de recréer cette dll, à la manière "yescard" d'une carte à puce ? Ou plutôt de modifier la dll existante à cet effet ? En gros une dll qui quand tu lui demandes si deux CRC correspondent (appel à CompareCRC), qu'elle réponde 'TRUE', en rajoutant l'équivalent assembleur de 'return 1' juste après l'appel de la fonction. Si ça ne passe pas, tu pourrais aussi modifier calcCRC et CalculateSupportsCRC pour qu'ils retournent tout le temps 0... M'enfin j'ai jamais essayé le reverse engineering...

            • [^] # Re: CRC, division, toussa.

              Posté par  . Évalué à 2.

              Oui, mais ce ne serait pas forcément plus simple, contrairement aux apparences. En plus, cela lèverait les garde-fous dans les cas où les fichiers seraient réellement corrompus, et ce n'est pas souhaitable sur une machine-outil.

              Nan, le mieux c'est encore un coup de strace/truss ou un bon débogueur pour suivre les appels à calcCRC() et vérifier la valeur de l'int passé en second paramètre. Si c'est toujours le même, alors c'est gagné.

              Ensuite, il faut écrire un petit logiciel qui exploite la même lib et qui regénère le bon fichier. Enfin, il faut essayer avec les données des fichiers existants et voir si l'on obtient le même CRC.

Suivre le flux des commentaires

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