{"id":526,"date":"2025-12-22T20:07:30","date_gmt":"2025-12-22T19:07:30","guid":{"rendered":"https:\/\/www.hardwaresecurity.it\/?p=526"},"modified":"2025-12-23T11:30:06","modified_gmt":"2025-12-23T10:30:06","slug":"full-disclosure-hideez-key-2-fail-how-a-good-idea-turns-into-a-spf-security-product-failure","status":"publish","type":"post","link":"https:\/\/www.hardwaresecurity.it\/?p=526","title":{"rendered":"[Full-Disclosure] Hideez Key 2 FAIL: How a good idea turns into a SPF (Security Product Failure)"},"content":{"rendered":"\n

Prologue: <\/strong>After my first success in bypassing APPROTECT readout protection of the NRF52-based Slok smartlock with #PocketGlitcher<\/a> (i.e. video below), I started looking around for more interesting and concerning (from a security point of view) NRF52-based products.
<\/p>\n\n\n\n

And here it comes the #Hideez<\/a> Key 2<\/a>!<\/h4>\n\n\n\n
\"0*FhVyBzTgqyjF21M0\"<\/figure>\n\n\n\n

To give you a quick overview of this piece of hardware, check out their video intro:<\/p>\n\n\n\n

Now that you got the point of this product. You will agree with me that the concept is very interesting, let\u2019s now see if its implementation into a real product matches the expectations.<\/p>\n\n\n\n

I will divide my investigation in paragraphs to keep everything as linear as possible.<\/p>\n\n\n\n

Passive Recon & OSINT:<\/h2>\n\n\n\n

First of all (even without attempting to open the token) we can immediately notice our best-hardware-hacking-friend: the FCC ID. In this case: 2AQ5UHIDEEZKEY2<\/a><\/p>\n\n\n\n

\"0*9A9<\/figure>\n\n\n\n

This leads us to the first set of OSINT information regarding how the PCB looks like, what MCU is used and which frequency is in use by the DUT (Device Under Test).<\/p>\n\n\n\n

\"httpsmiromediumcommax5290yMh4vg6X6EVYihrjpng\"<\/figure>\n\n\n\n

The Internal Photos PDF from the FCC database is particularly useful in case the DUT\u2019s PCB would have been buried under a hard layer of epoxy. This would have helped us to plan in advance where to start scraping out the epoxy and how to approach the opening of the case and how to reach the MCU. Luckily for us, there was none of these anti-tampering measures in place.<\/p>\n\n\n\n

Overall, most of the information gathered so far is matching Hideez\u2019 manual specs.
\"0*ixASJqCGKfSdfyi3\"<\/p>\n\n\n\n

While keeping looking around the cyberspace for more information about the DUT, I quickly discovered a funny thing: there is a repo on Github that contains a lot of juicy stuff<\/strong>!<\/p>\n\n\n\n

\"0*bN<\/figure>\n\n\n\n

Among them\u2026 the schematics, the BoM (Bill of Material) and even the goddam CAD files of the PCB!<\/p>\n\n\n\n

\"0*dyohSXQZqk6T0NDk\"<\/p>\n\n\n\n

In practice, I had access to everything I needed to easily figure out where the NRF52\u2019s SWD pins are located, without even messing with Microscope, GIMP and Multimeter in continuity mode. (Thanks Hideez \u2764)
\"0*l6TDYygWsh5xBBUG\"<\/p>\n\n\n\n

\"0*oUrP0HFAVe6yqUZ0\"<\/p>\n\n\n\n

Looking closer with Altium on the CAD files, I easily figured out the SWD\u2019s pinout:\"0*n7PZgKKUXkGLY06H\"<\/p>\n\n\n\n

Note, at this point in time I was also looking for an better location where to probe the DEC1 and RESET pins coming out from the NRF52 in order to use them later on to conduct the Fault Injection Attack with my #PocketGlitcher<\/a>:<\/p>\n\n\n\n

\"0*AUlUntihPoPGIBru\"<\/p>\n\n\n\n

Even though, at the end, I won\u2019t even need them.<\/p>\n\n\n\n

Conclusion, always do your homework before putting your hands on the target: FCC database, Google, and Chinese search engines are your best friend when doing a hardware hacking research!<\/em><\/strong><\/p>\n\n\n\n

Setting Up The Device: <\/strong>Before starting the Active Recon Phase and, in order to replicate a real scenario, I decided to install the Hideez App on both laptop and iPhone. Subsequently I filled it with a bunch of dummy credentials. This will help me later in the case I will be able to obtain a firmware that eventually is encrypted (i.e. known-plaintext attack).<\/p>\n\n\n\n

\"0*TRwjWHbaK9YbBdLm\"\"0*jXHR3Rj7iDkt4jpu\"<\/p>\n\n\n\n

Active Recon:<\/h1>\n\n\n\n

Now that we have a working Hideez Key 2 with some passwords in it, when can start opening it and checking if what we found during the Recon Phase matches the reality.
\"0*kPcTvu2BaYYr<\/p>\n\n\n\n

As expected, from a closer look with my microscope, the PCB looks matching the schematics and the CAD design. Cool!<\/p>\n\n\n\n

Just to be 100% sure I won\u2019t fry the board while attempting the firmware dump, I double-checked with the multimeter that the pinout of the SWD interface was still correct. And indeed it was!<\/p>\n\n\n\n

Dumping Firmware over SWD Interface:<\/h2>\n\n\n\n

In order to prove how easy would be for a real threat actor to dump the firmware in couple of minutes (i.e. #evilmaid<\/a> attack) without leaving traces on the PCB itself, I decided to use my PCB workstation with nano probes.
\"1*dhh2Lf<\/p>\n\n\n\n

With everything properly setup and connected to my J-link debugger, it literally took (with my extreme surprise, considering is a security token used as 2FA & password manager) 60 seconds<\/strong> to dump the firmware!<\/p>\n\n\n\n

\"1*TQj4crxHJzq<\/figure>\n\n\n\n
\"1*TQj4crxHJzq<\/figure>\n\n\n\n

Firmware Analysis:<\/h2>\n\n\n\n

Passed the initial shock, I thought the data inside the dump would have been still encrypted in some way. Therefore I was mentally prepared to play with #CyberChef<\/a>\u2019s features in order to crack the sh*t out if this security token.<\/p>\n\n\n\n

Well\u2026 I was wrong.<\/p>\n\n\n\n

The credentials, both existing and also the ones that were \u201cdeleted\u201d by the user, are there! In PLAINTEXT.<\/em><\/strong><\/p>\n\n\n\n

\"0*lPQRSQlZwHiwSX5d\"<\/p>\n\n\n\n

Everything! The Cloud Password that allows to login on Hideez\u2019s website, Laptop\u2019s credentials, Website login user and password are ALL IN PLAINTEXT!<\/strong><\/p>\n\n\n\n

At this point, I will let the good-old Arny express my feelings.
\"0*we0m<\/p>\n\n\n\n

RFID Feature:<\/h2>\n\n\n\n

\"1*jbc3Byz<\/p>\n\n\n\n

One clue still left (from a hardware security POV) was about the RFID tag. From the opening of the case, it was visibly obvious that the RFID feature advertised by Hideez was not related to the NRF52, but was rather just a standalone re-writable tag. (meh\u2026)<\/p>\n\n\n\n

That\u2019s kind-of pity since the NRF52 is supposed to support NFC protocol as you can see from the Nordic\u2019s NRF52-DK prototyping\/evaluation board.
\"0*7Fkr4Kb34jzupH3V\"<\/p>\n\n\n\n

Anyway, long-story-short, I wanted to check with my Proxmark what tag is that: it appears being a classic T55xx re-writable tag.
\"0*sQz<\/p>\n\n\n\n

\"0*D4tjt3dndBgqZVFe\"<\/p>\n\n\n\n

Sadly, this tag, as all the 125KHz vulnerable ones like EM4xxx or HID Proxcard, etc\u2026 are quite easy to clone from distance with a weaponized long-range reader (see below couple of examples).
\"0*K9obBjRU2g469wO8\"<\/p>\n\n\n\n

\"0*8<\/p>\n\n\n\n

Security Remarks:<\/h2>\n\n\n\n

The lack of proper security R&D and Threat Modeling is obviously the root-cause of this product failure. In particular I would have spent more time looking for:<\/p>\n\n\n\n