

Reverse Engineering Vendor Firmware [video] - tbrock
https://www.youtube.com/watch?v=j5NciKpHZzs

======
AlyssaRowan
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...

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

~~~
osivertsson
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.

~~~
nitrogen
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.

~~~
osivertsson
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.

------
osivertsson
I learned about mmiotrace which I could find very useful when reverse
engineering binary drivers.

The question at the end about why Linux allows user-space access to PCI
registers was also very interesting. Apparently it was historically required
by X, but should no longer be needed with KMS. Therefore one should in theory
be able to disable /dev/mem completely.

