I think the idea is that (given the ability to generate SHA-1 collisions) the same technique used to generate MD5 collisions in Postscript files could also be used to generate SHA-1 collisions in firmware files:
http://www.educatedguesswork.org/movabletype/archives/2005/0...
Basically, you generate two colliding blobs of random data, and then append identical code to each of them. The resulting concatenations also collide. The code is designed to behave differently depending on which blob precedes it.
That alone isn't very useful. It would be obvious to anyone who reviewed the code that something is going on, and the whole point of the attack is to fool code reviewers. But if you're clever you could obfuscate this in a number of ways. For example, if you can generate a large number of collisions, you could find a pair of blobs such that a given substring, when interpreted as data or code, produces correct behavior for one version and insecure behavior for the other.
Basically, you generate two colliding blobs of random data, and then append identical code to each of them. The resulting concatenations also collide. The code is designed to behave differently depending on which blob precedes it.
That alone isn't very useful. It would be obvious to anyone who reviewed the code that something is going on, and the whole point of the attack is to fool code reviewers. But if you're clever you could obfuscate this in a number of ways. For example, if you can generate a large number of collisions, you could find a pair of blobs such that a given substring, when interpreted as data or code, produces correct behavior for one version and insecure behavior for the other.