Unnamed Reverse Engineering Podcast

© 2025. All rights reserved.

011 - Making Too Many Assumptions

An interview with Mike Ryan, Bluetooth Expert

03 Jun 2018

This week Mike Ryan ( @mpeg4codec ) joins us to talk about how he went from hacking games for stronger characters (we don’t reveal which ones; you’ll have to listen) to revealing big weaknesses in Bluetooth products.

Mike gives us the rundown on how he ended up working on UbertOOth ,  using wireshark , and how many UbertEEth you should use.  We discuss some of the biggest mistakes developers make in their Bluetooth and BLE products. He shares some examples of this through his prior work including credit cards and skateboards. We also learn about CVEs including the one Mike has for the Skateboard .

If after this, you are worried that your next IoT product needs a security review or at least getting started with Ubertooth, you can go to the Ubertooth , CrackLE and wireshark sites. If you want some serious hands on, you can contact Mike here .

A few more tools came up to add to your list:

NOTE: Sorry about the rough audio, we had some technical difficulties that we resolved about 15 min in.

Have comments or suggestions for us? Find us on twitter @unnamed_show ,  or email us at show@unnamedre.com .

Music by TeknoAxe ( http://www.youtube.com/user/teknoaxe )

010 - T0015! Part 0x3 - Debug Interfaces

Reverse Engineering Tools - Debugging Hardware

15 May 2018

This week we talk about the nebulous world of debugging interfaces, some of their history, and how they can be used in reverse engineering. We cover the basics of what are JTAG and SWD ( both ARM Debug Access Port (DAP) and ARM® Debug Interface Architecture Specification ) and can they both be used to debug a MIPS processor (the answer is NO!).

We list a few other standards but also some key vendors and projects to get you debugging and controlling your next system:

Since a few of these are from the OSHW/OSSW world, we briefly discuss the impact of this work on driving down costs and opening up the field to more people.

As always, we might have missed your favorite tool or you had questions and comments about our list, find us on twitter @unnamed_show ,  or email us at show@unnamedre.com and tell us.

Music by TeknoAxe ( http://www.youtube.com/user/teknoaxe )

009 - T0015! Part 0x2: All Ur sigs R belong to uS.

Reverse Engineering Tools - Signal Measurement

15 Apr 2018

In this episode, we talked about measuring things (Well mostly digital and some analog things)!

Perhaps we missed your favorite tool or you had questions and comments about our list, find us on twitter @unnamed_show ,  or email us at show@unnamedre.com and tell us.

Music by TeknoAxe ( http://www.youtube.com/user/teknoaxe )

008 - T0015! Part 0x1

Reverse Engineering Tools - Intro

09 Mar 2018

This week are we talking about tools to get you through different situations. Both of share our list of items to tackle a few common situations. By no means is this extensive but it doesn’t focus exclusively on software .

Perhaps we missed your favorite tool or you had questions and comments about our list, find us on twitter @unnamed_show ,  or email us at show@unnamedre.com and tell us.

Music by TeknoAxe ( http://www.youtube.com/user/teknoaxe )

007 - Candy Coated

An Interview with M. Carlton from Senrio

03 Jan 2018

M. Carlton joined us to talk about being part of leading professional reverse engineering team at Senr.io . We discussed her Embedded Systems talk about IoT and in particular Devil’s Ivy (Check out the important ROP video to better understand the key concept ). In this particular case, they found that the M300 camera model using GSOAP ( SOAP ) parse for buffer overflow.

Not only did this issue allow spread quickly as a DOS among the M300 cameras but over 200 other Axis cameras (Hurray for code-reuse) due to using the third party code library.

M. uses several tools in her work:

  • IDA Pro
  • Binwalk
  • Nmap
  • Debuggers like gdb
  • Multimeters and oscilloscopes
  • VMWare

She had some excellent suggestions for improving the odds of NOT getting hacked:

  1. Put a password on any consoles and let it be changeable.
  2. Anticipate issues by performing security reviews.
  3. Be wary of any third party libraries you use. If there are updates to these libraries, prepare to update quickly.
  4. Make sure your systems are field patchable/updateable, securely.
  5. Limit surface area. Limit the ability for others to analyze your system by removing/disabling consoles, UARTs, features, and JTAG interfaces.
  6. Put more gates/obstacles on how easily any found exploits can be used in the system.
  7. Unearth any default credentials used in your system and resolve.

In the worse case, plan in advance for a security breach to expedite deployment.

Have comments or suggestion names for us? Find us on twitter @unnamed_show ,  or email us at show@unnamedre.com .

Music by TeknoAxe ( http://www.youtube.com/user/teknoaxe )