Story time from my 1st reverse engineering project at work

I joined the organization straight out of undergrad as a red teamer, but they knew I loved assembly. (I was TA for computer arch & created new projs for the class.) So they asked me if I'd like to try RE... 1/7

I was thrown into the deep end. My project? Determine if I could attack an embedded device through its serial input. So I got to work & quickly found a function that I thought was worthy of reversing cause I thought it may be responsible for the parsing of the input. 2/7

For 4 *full* days, I spent reversing this function, commenting almost every line of disassembly. The firmware was in Renesas SH4 architecture so I was also looking up almost every instruction. And after those many, many, many hours, I realized that the function was... 3/7

PRINTF. I spent almost a full week reversing printf. PRINTF!

But here's the thing, I was right. printf was an important part of the string parsing in the device. & I had now learned what printf looks like in asm, learning the pattern, so I never had to reverse printf again. 4/7

And that's how you learn to reverse engineer: working through line by line, looking at instruction set architectures (ISA), until it becomes clear what the code does, and then you know that pattern. So next time you see the same pattern, you won't have to go line by line. 5/7

I've trained a lot of folks in binary RE & the only times people haven't been successful is when it turns out they don't like it. That sounds cheesy, but it's the truth. If you enjoy the process of looking at assembly for hours & hours to solve the puzzle, you will get it. 6/7

All this to say, 6 years ago, when starting to do RE it took me a week to determine a function was printf. Today, it takes me maybe 30 sec, even if I've never seen the architecture before. How do you get better at reversing? Just do it. And anyone can do that if they want to. 7/7