# Overcome MD5-RSA Signature verification

I asked this question already at the Information Security SO site, but my research on how to overcome this problem ended always on the crypto site. That's why I will try to find some help here :)

I am currently working on a software challenge where you have to unlock several functions of a piece of software. The software is written in Java. One of them is the update mechanism of the firmware. What it does is to download a file from a webserver and make a few checks, before the update is performed. I need to find a way to overcome these checks in such a way, that I am able to update the firmware using my own created firmware update.

Here is how the update mechanism works:

1. The software downloads a file from the webserver. It is a zip file which should have the following structure:

|Zip file content| SecurityTag: | Tag|

• Zip file content: This is where I have to add a file, called version.txt which needs to contain a number x > 1.0. (The software reads that part as ZipInputStream.)
• SecurityTag: This is a string, which has to be within this file! I cannot modify that one.
• Tag: The Tag which is used during the check.
2. It takes the Zip file content, checks if the version.txt file is included and extracts the number from it.

3. It hashes the Zip file content using hash = MD5(Zip file content)

4. Takes the tag and decrypts it using RSA: t = (tag)^e mod N. I know e=65537 and N.

5. It verifies if hash == t and len(t) == len(hash).

Somehow, I have to pass this check but I am not sure how.

I had a look if I could make use of RSA's homomorphic property but I don't see how to do it efficiently :( I don't have any signature or any other information, besides the file structure and that it has to contain the SecurityTag: string and the public parameters e = 65537 and N.

Is there any attack scenario which I am missing here? Can anyone point me in the right direction?

• In general, t = (tag)^e mod N is an integer wider than the MD5 hash (which is 128-bit). Are all bytes of t involved in the check hash == t? If not, exactly which bytes are checked? – fgrieu Apr 12 '19 at 13:12
• All bytes are involved. That means that len(t) == len(hash). – Donut Apr 12 '19 at 13:17
• That is weird. What is the size of N? – SEJPM Apr 12 '19 at 14:16
• If N can't be factored, I fail to think of any on-topic solution for the current statement. I can imagine implementation goofs in the test "hash == t and len(t) == len(hash)", or that parsing the file (including decompressing the ZipInputStream, changing bytestream | Tag| to number tag..) allows a buffer overflow and some exploit, or cause an exception bypassing the check, or that tag is mishandled as a non-integer type, but none of this is crypto-related. – fgrieu Apr 12 '19 at 14:54
• Please do not cross-post the same question to multiple sites. If it's not appropriate for one site, then ask a moderator to migrate it for you. – Ella Rose Apr 12 '19 at 15:05