<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>reverse engineering on usedbytes:Blog</title>
    <link>https://blog.usedbytes.com/tags/reverse-engineering/</link>
    <description>Recent content in reverse engineering on usedbytes:Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <lastBuildDate>Sat, 07 Jan 2023 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.usedbytes.com/tags/reverse-engineering/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Astro Slide Early Impressions</title>
      <link>https://blog.usedbytes.com/2023/01/astro-slide-early-impressions/</link>
      <pubDate>Sat, 07 Jan 2023 00:00:00 +0000</pubDate>
      
      <guid>https://blog.usedbytes.com/2023/01/astro-slide-early-impressions/</guid>
      <description>So clearly there are some issues to work out, but this was bit-banged from an OV7670 on a Pico. PIO next. #raspberrypi #PiWars pic.twitter.com/yJFQFhU9Xk
&amp;mdash; Brian Starkey (@usedbytes) September 14, 2021  [M0o+](https://blog.usedbytes.com/tags/m0o+/)   -- Earlier this week, on the 3rd January 2023, a nearly 3-year saga entered it&amp;rsquo;s next phase: I finally received the Astro Slide 5G Transformer I backed on Indiegogo back in May 2020. The original estimated delivery date was March 2021, so it&amp;rsquo;s been A While.</description>
    </item>
    
    <item>
      <title>ScreenMachine FLM images</title>
      <link>https://blog.usedbytes.com/2022/08/screenmachine-flm-images/</link>
      <pubDate>Thu, 11 Aug 2022 00:00:00 +0000</pubDate>
      
      <guid>https://blog.usedbytes.com/2022/08/screenmachine-flm-images/</guid>
      <description>When I visited recently, my Dad gave me a challenge: He handed me a box of 3.5&amp;quot; floppy disks1, which hold lots of images of minerals from an electron microscope. The challenge: Turn the images into something viewable with a modern computer.
I don&amp;rsquo;t have any computers with a floppy drive, though I do have a bunch of floppy drives not in computers ¯\_(ツ)_/¯. I did think my 11-year-old desktop had a floppy connector on the motherboard, but alas not.</description>
    </item>
    
    <item>
      <title>Reverse Engineering keyboard firmware with Ghidra - Part 4 (Conclusion)</title>
      <link>https://blog.usedbytes.com/2020/04/reverse-engineering-keyboard-firmware-with-ghidra-part-4-conclusion/</link>
      <pubDate>Wed, 29 Apr 2020 19:53:36 +0100</pubDate>
      
      <guid>https://blog.usedbytes.com/2020/04/reverse-engineering-keyboard-firmware-with-ghidra-part-4-conclusion/</guid>
      <description>This post has been a bit delayed for noe reason in particular (except perhaps fatigue with the project). It brings the Ducky reverse engineering adventure (mainly) to a close.
At the end of Part 3, all of the pieces were in place, but I still wasn&amp;rsquo;t able to flash my own modified firmware to the keyboard because of a pesky failing CRC check.
What I did know, was that after sending the CRCCheck() command, the keyboard responded with a 16-bit value.</description>
    </item>
    
    <item>
      <title>Reverse Engineering keyboard firmware with Ghidra - Part 3</title>
      <link>https://blog.usedbytes.com/2020/03/reverse-engineering-keyboard-firmware-with-ghidra-part-3/</link>
      <pubDate>Sat, 28 Mar 2020 10:18:10 +0000</pubDate>
      
      <guid>https://blog.usedbytes.com/2020/03/reverse-engineering-keyboard-firmware-with-ghidra-part-3/</guid>
      <description>In which we succeed, and fail - and take a break to play through Half-Life: Alyx
At the end of Part 2, we&amp;rsquo;d found and extracted the &amp;ldquo;firmware blob&amp;rdquo;, which is the data that the updater sends over USB to the keyboard. The problem is that the data doesn&amp;rsquo;t look anything like Arm Cortex-M3 code.
00000000: 84be c2c7 450a 0879 6c0a d553 51ce 1efc ....E..yl..SQ... 00000010: fe5b e848 e9c1 3c77 3b74 48b7 768c cbd9 .</description>
    </item>
    
    <item>
      <title>Reverse Engineering keyboard firmware with Ghidra - Part 2</title>
      <link>https://blog.usedbytes.com/2020/03/reverse-engineering-keyboard-firmware-with-ghidra-part-2/</link>
      <pubDate>Fri, 13 Mar 2020 20:36:08 +0000</pubDate>
      
      <guid>https://blog.usedbytes.com/2020/03/reverse-engineering-keyboard-firmware-with-ghidra-part-2/</guid>
      <description>Last time, in Part 1, we found out the super-secret XOR key for the Ducky One firmware updater and used it to obtain its file header describing the firmware version and keyboard layout.
The next missing piece to find is the size of the firmware image, which will tell us which part of the .exe file contains the firmware.
To find out where to look, we need to go back to the xx_get_fw function, which takes the firmware size as a parameter:</description>
    </item>
    
    <item>
      <title>Reverse Engineering keyboard firmware with Ghidra - Part 1</title>
      <link>https://blog.usedbytes.com/2020/03/reverse-engineering-keyboard-firmware-with-ghidra-part-1/</link>
      <pubDate>Wed, 04 Mar 2020 20:43:08 +0000</pubDate>
      
      <guid>https://blog.usedbytes.com/2020/03/reverse-engineering-keyboard-firmware-with-ghidra-part-1/</guid>
      <description>In March 2019, the NSA (yes, that NSA) released a reverse engineering tool called Ghidra. This is pretty cool, as it&amp;rsquo;s relatively easy to use, pretty powerful, and free as in both speech and beer (compared to the similar and popular IDA Pro which is not).
Around a year earlier, I&amp;rsquo;d &amp;ldquo;upgraded&amp;rdquo; my non-backlit Ducky One TKL keyboard to a backlit one: The non-backlit version is identical to the backlit version, they just don&amp;rsquo;t install the LEDs.</description>
    </item>
    
  </channel>
</rss>
