Hacker News Reader

Comment by AlyssaRowan | Hacker News Reader

This is a great talk.

There's a reason many reverse-engineers drink so much. It's because we have to look at someone else's code and figure out what they were thinking - and sometimes, the thing foremost in our mind throughout that process is: what the hell were they thinking?!

The things I've seen...

- Interrupts which relied on no-one using the debug registers (deliberately).

- I've seen copy protection faults which quit to desktop releasing a bootsector virus linked in when triggered. (Yes, 'virus protection' really existed, but I only saw it once.)

- Highly expensive dongle hardware whose entire purpose was being a 16-bit LFSR, which was perfectly matched in software with an equivalent routine, and the output compared with beq and nothing else done with it. (Let me just change that to a bra...)

- 'Encryption' using RC4 with no key. Ahahaha no.

When people think no-one's going to read it...

View on HN

Likewise, I've witnessed a reversible variant of SHA-1. They must have somehow messed up the break condition because it essentially only did one round.

Oh my, yes. 128-bit RSA signatures, anyone? AES-256... in ECB mode, with a static key that's the MD5 of a super-secret string in the binary with each byte sign-extended to 16-bit? ^0xA5? ROT13? I have seen them all, and I have despaired.

So many vendor "engineering" backdoors, too. Gah.

Eh, I do similar work, but find his whining tone intolerable.

I found it pretty amusing. You should know well that reversing really really ugly "here be dragons" code is full of even slightly more frustration than writing it. It's reasonable to communicate that frustration. Hopefully we can avoid it in future, a little bit.

I assume that the comment at the end - that this vendor tool was probably a hurried, barely-documented port of a DOS tool (which would have been safer 'because DOS doesn't do anything') - is probably right on the mark.

Yeah I agree the tone gets tiresome. Just explain it with a higher signal-to-noise ratio and avoid pausing all the time to whine.

Developing software in a corporate environment under the constraints of capatalism often means average management and average coders both with a tight deadline.

Trying to take shortcuts in such an environment is only human nature, and getting non-optimal designs and implementations then should be no surprise.

We should be understanding of mediocrity, but we should never accept it as given. As an industry we need to do better -- push back on unrealistic expectations, demand the necessary resources, understand business needs and when they are unjustified.

Well said, and in my experience the best way to achieve all this is to let devs have direct contact with end users. Getting the knowledge first hand on what problem they are really trying to solve with your help, and how small tweaks here and there can make them more efficient etc. really gives most devs a sense of urgency. What is required is done, but no more since devs want to put the new version quickly into the hand of the users in the hope that they'll like it.

The complete opposite is fixed requirements specifications and many layers between devs and users. This will get expensive and easily quite mediocre when devs know they are not really building the product the end user needs since motivation so easily falters in such an environment.

Reply on news.ycombinator.com