Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re: checksum of subroutine

by jeffa (Bishop)
on Aug 10, 2012 at 18:34 UTC ( #986803=note: print w/replies, xml ) Need Help??

in reply to checksum of subroutine

Why would a finer grained inspection of the subroutines be any more suspect than any other part of the code? I would think, once the current state of the file has been blessed, that an overall checksum of the file would be more than sufficient to show that ANY changes have been made when NONE were expected. Once you have a corrupted file identified then you can use something like diff to see what changed.

Otherwise, there happens to be this dynamic language called Perl is that very good at parsing text. ;) Anything from a simple regex to Parse::RecDescent can be used to extract the bits of text that make up a Perl subroutine.


(the triplet paradiddle with high-hat)

Replies are listed 'Best First'.
Re^2: checksum of subroutine
by mnooning (Beadle) on Aug 10, 2012 at 18:53 UTC

    On second thought, your suggestion contains the answer. Simply use RecDescent to do the parsing just prior to shipping the software, etc.


Re^2: checksum of subroutine
by mnooning (Beadle) on Aug 10, 2012 at 18:47 UTC

    A hacker can replace needed bits in a file, then add other bits so that the overall file checksum stays valid. Doing that gets quantum if you have to hack the subroutines and file checksums.

    As for RecDescent, if I could get at the text of a sub I could parse the sub and checksum it myself. The trick is to get at the text of the subroutine. That is where the question lies. Parse::RecDescent needs something like "$text", where $text is the text of the subroutine. You cannot hand it just a coderef. :-)

      Use Digest::SHA to calculate a digest over the whole file. Although it is not impossible to make two totally different files with the same digest, it is extremely unlikely that both files will have the same length and both will be working programs. It is not as simple as changing a few instructions and adding a few meaningless bytes at the end to "make up" the checksum.


      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

      My blog: Imperial Deltronics

      Rather than literal checksums (e.g., sum of all bytes) or even CRCs, maybe investigate some modern 'digital signature' technology. Perhaps start with the Cryptographic hash function discussion.

      "A hacker can replace needed bits in a file, then add other bits so that the overall file checksum stays valid."

      True, but it's very, very hard. And would be made exponentially harder -- effectively impossible -- by taking two checksums of the file using different algorithms. For example taking both a SHA-512 and Whirlpool hash of the file, then concatenating them.

      perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

        Very novel idea. I will definitely be looking into this for the overall package.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://986803]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (5)
As of 2018-03-20 06:49 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (248 votes). Check out past polls.