How did you find that empty message forwards the state?

[muthmano-dev]

Hi luker,

Great writeup!! I didn't know there was this elegant way.

I found the switch breaks and the rest of the stuff but the way I approached to solve the task was I found that sending two empty DATA messages (or an empty message after OPEN when it's expecting manifest.sig I believe) caused panic and restarts the modules without deleting the folder. So what I did was to try to cause panic mid update that leads to the directory with the name 'major-version.subversion.PID+RAND' being created and not deleted. It has a 'Bad key' which I generated that works in my favor for the next update. I try to brute force the RAND value as the netsvc uses srand() and rand() combination to generate that and find the directory name and proceed to update using that as the from version. This took several hours and was nasty. Your way was much cleaner.

You have mentioned:
"

passing blank values seemed to continue moving the state forward even though signature verification fails.

"
How did you figure out that states forward in the debugger? or was it a trial and error method?

[rhunt4675]

Oh wow I just asked almost exactly the same question to @luker983 : #3

There is a slight optimization that reduces the brute force search time from 'hours' down to ~2-3 minutes per drone with this approach. We know that the RAND value is somewhere in [0, 0x10000) and netsvc allows us to have 0x100 concurrent sessions open at any time. Therefore, we can upload 0x99 'bad keys' before starting the brute force, and then start searching for a matching rand value. On average, we should expect to only need to search 0x10000 / (0x99 + 1) = 0x100 values before finding a match, which is much better than needing to search the entire space. But the 'passing blanks' approach is definitely cleaner.

[muthmano-dev]

Oh wow, I didn't think of using the concurrent session ability. I totally forgot it existed. That would have definitely reduced my brute force time approach. I was going down the wrong rabbit hole before figuring out this method 14 hours before the deadline.

[luker983]

See #3. Nice job finding this exploit! I'll see if I can find out what the intended solution was from the organizers.