RogerR

less than 1 minute read

Once upon a time, I challenged myself to hack devices of ¿my? home. I decided to start with ¿my? Awning as I expected that it would be be the easiest one… And I wasn’t wrong at all :).

The awning moves thanks to an embedded engine which is controlled by a remote control:

Cherubini remote control

Even though the specifications of the device claim that it implements the Rolling code mechanism (used to prevent Replay attacks), seems that the awning installer understood that using this protection was not necessary… That’s bad…

The result is that after spending approximately 30 minutes I could hack very easily the awning, just conducting a replay attack of the signals generated by the 3 switches of the remote control. The following image shows the signal profile of one of the switches:

Signal profile

This sadly means that a script kiddie could play with ¿my? awning just for fun… Should I complain to the technician who installed it?

Details
Equipment used:

Steps:

  • Activate the awning with the remote controller and sniff the signal.
  • Resend the same signal.

It wasn’t necessary to modify the signal or adjust the equipment, not bad for the first chapter…

Updated:

You may also enjoy

Hacking Homes For Fun: Chapter 2 - The Alarm Tag

2 minute read

Nowadays most of the home alarms use a contactless tag to activate/deactivate the alarm. Those tags bring cryptographic functionalities; however, I want to verify if they are really used. As an example, the remote control of [Chapter1](/hacking-homes-for-fun-Chapter1) had anti-replay capabilities which were not used by the system integrator. I started analyzing the type of tag of the home alarm, this can be easily done using an NFC enabled smartphone and the [NXP Tag Info](https://play.google.com/store/apps/details?id=com.nxp.taginfolite) application. The tag is an ISO15693 with cryptographic capabilities. ![TagInfo Image](/assets/images/20230106_TagInfo.png){: width="200" style="display: block; margin: 0 auto"} NXP Tag Info also indicated that no cryptographic keys were set, therefore, I suspected that the alarm device only checks the UID of the tag. The UID is a unique identifier which must NEVER be used for security means, as it can be easily replicated. After the initial analysis, seems clear that it will not be very hard to create a fake tag to deactivate the alarm. To do so I used the Proxmark3 as shown below. Basically, I used a script to use the [standalone mode](https://github.com/RfidResearchGroup/proxmark3/wiki/Standalone-mode) which has two steps: 1. Reader mode, reads a Tag which is approached. 2. Emulation mode, emulates the read Tag. ![Emulating Tag](/assets/images/20230106_122034.gif){: width="200" style="display: block; margin: 0 auto"} Once the Tag was emulated, I performed a proof of concept to verify that the Alarm Tag could be bypassed, the steps to conduct were: 1. Activate the alarm 2. Once the alarm was activated, use the emulation tag to deactivate it. The results can be seen below: ![Deactivating alarm](/assets/images/20230106_122254.gif){: width="200" style="display: block; margin: 0 auto"} As in [Chapter1](hacking-homes-for-fun-Chapter1), although the tag implements cryptographic functionalities, the system integrator chose not to use it, probably for simplicity or lack of security knowledge. Even more; after further research I was able to identify that only the 3 last bytes of the UID were checked. The other 5 bytes were ignored: ![Emulating Tag](/assets/images/20230106_UID.png){: style="display: block; margin: 0 auto"} I already advised both the alarm manufacturer and the system integrator, and they indicated that the security would be enhanced :). Tema General Tema1 Tema2 Tema3 Tema4 Tema Spec 1 Tema Spec 2 Tema Spec 3 Tema Spec 4 Tema Spec 5 Tema Spec 6 Tema Spec 7 Tema Spec 8 Tema Spec 9 Tema Spec 10 Tema Spec 11 Tema Spec 12 Tema Spec 13 Tema Spec 14 Tema Spec 15 Tema Spec 16 Tema Spec 17 Tema Spec 18 Tema Spec 19 Tema Spec 20 Tema Spec 21

Message to the Future beings

less than 1 minute read

Have you ever though to send a message for the future beings? No matter who would read it? The requirements are to generate a message that will be stored forever but than only be read in the future... ![Message in Bottle](/assets/images/20221225_message-bottle.jpg){: width="250" style="display: block; margin: 0 auto"} Let's see how you can do it. Let's build a message which can be read but not understood... wait! What? Let's see how real crypto, not the crypto bro's crypto can help us: 1. Generate a plain message. 2. Generate a random number of 16 bytes. 3. Encrypt the message with this key. 4. Delete this key and do not write it down. - Optionally you can just show some bytes to "regulate" the future time in which could be read. The result could be something like this: ![Message Future Beings](/assets/images/20221226_MessageFutureBeings.png){: width="500" style="display: block; margin: 0 auto"} It includes the encrypted message, and a flag for the decryption with a text in plain and its encryption to help the future reader :) . Finally we should store it in a permanent not mutable storage, and nothing more than the [ipfs](https://ipfs.tech/). I already [did it](https://ipfs.io/ipfs/QmPgW7xu522Dy91xPg9nH5ZVGwxgd5G55BWwRj5Qbxc28v?filename=LetterForFutureBeings.pdf).

Just released passChecker bot

less than 1 minute read

Wanna check if your passwords are secure and have not been previously disclosed?

Just released the passCheckerbot, which is a Telegram bot which searches over a +60GB disclosed password database in less than a moment providing a simple answer “This password has [NOT] been disclosed”. Moreover it allows two modes (one of them a private mode):

  1. Verify the raw password.
  2. Verify a SHA1 hashed password.

I want to use this bot :)