https://www.cutawaysecurity.com/tags/reverse-engineering/Recent content in Reverse Engineering on Cutaway SecurityHugo -- gohugo.ioenFri, 06 Mar 2020 00:00:00 +0000https://www.cutawaysecurity.com/blog/learning-ghidra-basics-analyzing-firmware/Fri, 06 Mar 2020 00:00:00 +0000https://www.cutawaysecurity.com/blog/learning-ghidra-basics-analyzing-firmware/<h2 class="relative group">Introduction <div id="introduction" class="anchor"></div> <span class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"> <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#introduction" aria-label="Anchor">#</a> </span> </h2> <p>It has been a while since I have analyzed any program or firmware. The majority of my previous experiences were mostly analyzing Capture The Flag (CTF) binaries with the help and instruction from my good friend <a href="https://www.grimm-co.com/about/matt-carpenter" target="_blank" rel="noreferrer">Matt Carpenter</a> of <a href="https://www.grimm-co.com" target="_blank" rel="noreferrer">Grimm Security</a>. While extremely helpful, I always knew I was looking for a vulnerability that should be easy to find since I mainly stuck with the easy to medium difficulty challenges. Analyzing actual firmware for a vulnerability is much different. While most programs &ldquo;should” have vulnerabilities, there is no guarantee of a flag at the end, like in CTF binaries, that can be verified by submitting a string of bytes for points.</p>