Bruteforce passwords engineering menu radios
What is an engineering menu and why is it needed? Let me quote from the wiki :
Undocumented features (English undocumented features), NDV - capabilities of technical devices and / or software that are not reflected in the documentation. Most often, undocumented features are deliberately laid by developers in order to test, further expand the functionality. Undocumented features are usually discovered during the reverse engineering process , but can also be discovered by accident.Further in the article, a description of my attempt to select codes for the engineering menu of the radio station.
Introduction
I once bought a Chinese-made KYD-IP620 radio station, but under the domestic "brand". I will not advertise the brand, Google will tell. He twisted it in his hands, played and abandoned. But recently I came across it again and decided to pay more attention to this miracle of technology. The mean settings menu forced me to search for software to work with this station. It seemed to me that the software will give more settings than is available through the menu.
Having visited the manufacturer’s website, I found my model of a radio station, but I did not find the software. I wrote a letter to tech support, answered quickly and sent the software. Installed, launched and the first thing that caught my eye was the greater number of supported ranges. They pushed me to search for the opportunity to record the frequency I wanted (within a reasonable range of the current range). But then a bummer was waiting for me.
The official software before recording checked the entered frequency for falling into the selected range and prohibited recording outside the range. Okay, I started the sniffer, figured out the write-read protocol, and
Dismantled the station. On the board, among other things, 24C64 was found. This is an i2c EEPROM chip. It was soldered, removed the dump, soldered back. There was nothing in the dump except my settings and my recorded frequencies. I hooked the i2c sniffer to memory, drove writing / reading with official software, my utility, nothing. Everything that ran on the i2c bus was in the EEPROM, nothing extra was read or written. All data in the EEPROM is just the one that I wrote. Later, I finalized the write / read protocol and was able to read / write to all memory addresses.
What is it all about?
Anticipating the question “Why do I need all this, what am I writing about?” I will try to describe my thought. Google gave several diagrams of the previous and next models of the radio station. I did not find the schematic diagram of my experimental subject, which I describe in the article, but it coincides with them by 70% (I found out while I called the necessary legs). According to the scheme, the differences are not significant. This suggests the conclusion that to reduce the cost of production for the customer, the manufacturer, especially China (with its mass production) will not again design globally schemes, write software for MK radio stations, etc. Why, when is there already a ready-made one that needs to be slightly corrected - and given back. IMHO is easiest to adjust programmatically, and without the use of a programmer. This will make it possible to make a large pile of blanks, which will then be brought to customer requirements with the least effort. After this thought, I started looking for an entrance to the engineering menu, and found it. There was nothing complicated: it was necessary to hold down the 2 buttons and turn on the radio station.
Here it is!
Before entering the menu, the inscription "SET" is written.
For further access to the functions, a 6-digit password is required. Hand busting is tedious and disappears. In case of an incorrect password, the inscription “SET” is displayed again. Google gave one password, which leads to a factory reset. When you enter it, the inscription changes to "ERASE". And then it was useful to me later when debugging. There was an idea to organize a search for MK. Let him slowly turn his passwords, and I will do my own thing.
Let's get started
To enter the password on the radio station there is: a button keyboard and encoder.
Display of the entered data: LCD screen. I did not want to screw the camera to this whole thing and analyze the pictures or video from it. We have a screen, we will use it. Having studied a little more in-depth the station's interior, I found out that the HT1621B driver is responsible for the LCD display. Googling the datasheet for the driver and its pinout, found out the pins I needed. These are CS, WR and DATA. Briefly CS - the beginning of the transfer, WR- "synchronization", DATA-data. Let's try to take off with this. We call and solder to the conclusions of the MK station, leading to the legs of the LCD screen driver.
We connect the logical analyzer and look at the transmitted data to the driver for the inscription “SET” and for the inscription “ERASE”. It is clear that the data is different, we will need it. Next we solder to the "organs" of input. We need 2 buttons from the keyboard (MENU and F), and an encoder. I don’t have Arduins, I’ll do what is at hand. At hand was Pinboard with AtMega16, from Comrade DiHalt .
Technical task
We write an encoder emulator and an emulator for pressing the “MENU” and “F” buttons (they are needed to enter and confirm a password). We analyze the data that is displayed on the LCD screen. We will read the LCD driver data through AtMega16 interrupts. For different driver data from the “standard” (“SET”), we will output the current password via UART. We can not go into the data format for the driver. We need to distinguish when the inscription “SET” is not displayed after pressing the “MENU” button and when it is lit. It is logical that the data will be different. Therefore, I will compare the string of bytes received after the last digit of the password entered and the “MENU” button is pressed. Having caught several packages of the LCD driver for the inscription “SET”, I was convinced that they are the same, took this package as a reference. Comparing with it, I discard those that coincide, and transfer the others to UART, for further analysis. I checked this algorithm with a password, which leads to a factory reset, it met my expectations. In general, the password entry algorithm looks like this: the inscription “SET” is on, an invitation to the engineering menu. Press the “MENU” button and enter the 1st character of the password. Then again press the “MENU” button to enter the next character. So repeat to the last character. When the last character is entered, press the "MENU" button again. And here the inscription “SET” or something else will light up. If “SET” is lit, we stomp to the beginning by iterating the password, if not, send the password via UART for analysis. Screen programs for brute force management. Press the “MENU” button and enter the 1st character of the password. Then again press the “MENU” button to enter the next character. So repeat to the last character. When the last character is entered, press the "MENU" button again. And here the inscription “SET” or something else will light up. If “SET” is lit, we stomp to the beginning by iterating the password, if not, send the password via UART for analysis. Screen programs for brute force management. Press the “MENU” button and enter the 1st character of the password. Then again press the “MENU” button to enter the next character. So repeat to the last character. When the last character is entered, press the "MENU" button again. And here the inscription “SET” or something else will light up. If “SET” is lit, we stomp to the beginning by iterating the password, if not, send the password via UART for analysis. Screen programs for brute force management.
Reality
The reality is that I was counting on a high search speed, but life made adjustments. In a radio station, MK processes the encoder and keystrokes as it should, with "anti-bounce" of contacts, with delays in user response. Therefore, delays are introduced in the bruteforce code. Yes, it is all built on delays. Sketched a tool for managing brute force. In the case of reading driver data other than the "standard", the password is transmitted to the utility via UART on the computer at which it occurred.
Total
The search started, and is ticking. At the moment, I have not twisted anything yet. But I do not give up. I will patiently wait for the end. It is clear that with this approach there can be “false” responses. But against the general background of the future number of passwords scanned, this is a drop in the ocean. These “false” passwords can be quickly rechecked later through the utility. At the end of the search I will definitely inform you how all this brute force ended and what happened in the end.
Utility sources, AtMega16 firmware are available on the github .