On one of the usual sources of weird electronics I came across quiet unusual SFP+ module and could not resist buying it to see how it works. For now I was unable to make it work, but at least I made few photos of its internals. It turned out its main part is obscure chip made by Semtech and described as GN1157, which serves as laser diode driver. Obviously obtaining datasheet is impossible even in China. However, thanks to being able to see the board, I was able to reverse engineer some part of its pinout. Continue reading “Pinout of laser driver for CPRI SFP+ module – GN1157”
Tag: Reverse Engineering
Sniffing USB traffic with DSLogic logic analyzer into pcap file
Lately I came back to reverse engineering project that I started few years ago. Direct reason for such a long break was being stuck at attempts in using usbmon to capture USB traffic. The traffic that I wanted to sniff was between router and modem that connects to it via USB. As is usual with this kind of devices there is no SDK available and compiling custom kernel module for such system, while has huge educational value, is most likely going to end up with failure. So definitely I needed another way around this problem. Fortunately I have DSLogic logic analyzer, that could easily record such a slow protocol as USB. Then a bit of exporting and you get pcap file for wireshark. This might sound like a simple task, but I am going to show that it is not necessarily is. Continue reading “Sniffing USB traffic with DSLogic logic analyzer into pcap file”
Peugeot 407 rain sensor pinout
I had a project in mind featuring rain sensor, present in Peugeot 407 car, among others, probably. However, reality is that it is on my todo list for years now and I don’t think I will do it ever. But, I already bought the sensor in the past and it was lying in my drawer. So why not to disassemble it and figure out the pinout.
Identification
To be precise in what I am talking about, here are some magic values, I know about this thing:
- Manufacturer: Bosch
- Part number: 1 397 212
- Another number: 96 524 903 80
- Peugeot part number: 6405 CW
Playing with GF-07 GPS device
GF-07 is dirt-cheap GPS locator. You put SIM card in it, send SMS and you know where it is. That’s it. But not for me. I like to know what I am using, especially if it is that cheap and such obscure device as this one. It comes together with manual that is written in so bad English that I barely understand anything. Immediately after opening SIM slot, one can see few test pads. Fortunately all of them are described in silkscreen. Let’s see what can be done with it as a one-evening hack.
LKV373A: radare2 plugin for easier reverse engineering of OpenRISC 1000 (or1k)
This article is part of series about reverse-engineering LKV373A HDMI extender. Other parts are available at:
- Part 1: Firmware image format
- Part 2: Identifying processor architecture
- Part 3: Reverse engineering instruction set architecture
- Part 4: Crafting ELF
- Part 5: Porting objdump
- Part 6: State of the reverse engineering
- Part 7: radare2 plugin for easier reverse engineering of OpenRISC 1000 (or1k)
For quite a long time I did not do anything about LKV373A. During that time the guy nicknamed jhol did fantastic job on my wiki, reversing almost complete instruction set for the encoder’s processor. Beside that nothing new was appearing. This has changed few days ago, when jhol published videos about the device. After that, someone found SDK that seems to match more or less the one used to produce LKV373A firmware. At the time of writing it was not available anymore. Although it provided a lot of useful information and what is important here, it gave a possibility to identify processor architecture. It turned out to be OpenRISC 1000 (or1k). Because it is known, I compiled binutils for that architecture. Unfortunately objdump, which is part of binutils is not the best tool for reverse engineering. Lack of hacks I made for my variant of binutils, which allowed me to follow data references, was making things even worse.
The conclusion was that I need some real reverse engineering tool for or1k architecture. Unfortunately, neither IDA Pro, nor Ghidra, nor radare2 does not have support for it, which is not so surprising, if I heard about it for the first time, when somebody identified LKV373A to have such core. Only few days later, I encountered good tutorial, explaining how to add support for new architecture. I didn’t need anything else.
I am not going to explain how to write disassembly plugin (called asm
) for radare2. There are enough resources available. If one wants to try, my repository is quite nice place to start (notice template
branch there).
Out of source build and installation
In radare2, it is possible to build plugins out of source. To do that in case of or1k plugins, repository has to be cloned first with usual git clone:
git clone https://github.com/v3l0c1r4pt0r/radare2-or1k.git
Then, inside of radare2-or1k, simply type make
.
You should get two .so
files in directory asm
and anal
. You can load them with r2 switch -l
or from inside interface using:
L ./asm/asm_or1k.so L ./anal/anal_or1k.so
Be sure to load both plugins, as lack of anal plugin leads to noisy warning shown with every analyzed opcode.
Final result should look more or less like below. This is the beginning of jedi.rom
file:
0x00000000 00000000 l.j 0x0 0x00000004 15000002 invalid 0x00000008 9c200011 l.addi r1, r0, 0x11 0x0000000c b4610000 l.mfspr r3, r1, 0x0 0x00000010 9c80ffef l.addi r4, r0, 0xffef 0x00000014 e0432003 invalid 0x00000018 c0011000 l.mtspr r1, r2, 0x0 0x0000001c 18206030 invalid 0x00000020 a8210088 l.ori r1, r1, 0x88 0x00000024 9c400001 l.addi r2, r0, 0x1 0x00000028 d4011000 l.sw r1, r2, 0x0 0x0000002c 15000168 invalid 0x00000030 15000168 invalid 0x00000034 15000168 invalid 0x00000038 15000168 invalid 0x0000003c 00000031 l.j 0x100 0x00000040 15000000 invalid
That’s it. Good luck with reverse engineering!
New VCI+A-BT (DS150E) ST-Link pinout
This device could easily be found at the Chinese sellers. They advertise them as DS150E. Under the hood there is nice STM32 and STM8 pair. One is present on main PCB (in my case TCS MAIN V6.0), the other on relay board (TCS+RELAY V3.0). Both chips have their ST-Link headers broken out. If one want to read/write the firmware installed in internal flash, it should be as easy as connecting few of these pins. Continue reading “New VCI+A-BT (DS150E) ST-Link pinout”
PPPP API: what I know
While analyzing security of iMiniCam app, I learned some part of UDP protocol used to communicate with the camera. Here is quick bunch of facts.
UDP layer
Port 32100 (Proto_Hello, to external server) and port 32108 (others, to camera).
Type-length layer
Following structure represents first header that is always found in datagram.
struct header { uint8_t magic; enum proto_type type; uint16_t length; }
In this structure magic
is always set to 0xf1
, type
is one of the below values, packed on single byte and length
count data that follows this packet, so if it is equal to zero, only those four bytes are transmitted. Continue reading “PPPP API: what I know”
Security analysis of spy camera sold by Chinese suppliers: iMiniCam app
Lately, I bought some random, noname spy camera from usual Chinese sources. Just after unboxing, one detail seemed a bit suspicious to me: together with the camera there comes a link to Android app, that is meant to control the camera. What is worse, the link leads to some Chinese app shop, obviously with only one language available (notice the version – 1.0.33, as it is not the only one in the wild):
http://m.app.so.com/detail/index?pname=com.hbwy.fan.iminicams&id=3646142
As I’ve already seen apps that i.e. calls home, despite having no need to open a single socket and then sending data like IMEI, IMSI, MAC addresses and so on, red lamp turned on and I said to myself: stop. Let’s reverse engineer the thing first!
OSINT
Before I begun my reverse engineering, I attempted to ask uncle Google (and his friends 🙂 ) to gain some knowledge. Usual virustotal gives me this:
Continue reading “Security analysis of spy camera sold by Chinese suppliers: iMiniCam app”
How to convert Android resource ID back into its name
Few weeks ago I made an attempt to reverse engineer some obscure Android APK. It was available only through some Chinese shop, obviously described in only one language there. Unfortunately, it turned out that every tool designed for reverse engineering APK files outputted source with mysterious resource IDs, as plain integers, which is not the most convenient way to read them. Therefore I started looking for any way to find some meaningful name from these ids. At the end of my development effort I found out, there is one file that usually might be used for that purpose – res/values/public.xml
, as produced by apktool (if I remember correctly). However, according to its name it contains only public resources, so some of them are missing there (in my case at least some drawable type resources were missing). Therefore, I am publishing my program to do things even more reliably.
arscutils
This program requires my library created together, but which is separate project – libarsc. It is available, as usually through Github and also as a package to be downloaded from PyPI. Just type:
pip install libarsc
with proper privileges. Continue reading “How to convert Android resource ID back into its name”
LKV373A: state of the reverse engineering
This article is part of series about reverse-engineering LKV373A HDMI extender. Other parts are available at:
- Part 1: Firmware image format
- Part 2: Identifying processor architecture
- Part 3: Reverse engineering instruction set architecture
- Part 4: Crafting ELF
- Part 5: Porting objdump
- Part 6: State of the reverse engineering
- Part 7: radare2 plugin for easier reverse engineering of OpenRISC 1000 (or1k)
Last time, I showed how to do objdump, able to disassemble instructions for not yet supported processor – LKV373A encoder. This time, as promised in part 5, I am just publishing, what I was able to do.
Reverse engineering repo
Repository is located, as usually, on Github, here. The most important file there is printout of encoder firmware, generated with my fork of objdump. Also, there are few scripts, I used to make process more automatic. Especially useful for someone, who might want to reproduce the process or continue my work might be the ELF generator script. It is written in Python and uses my ELF-creation library from part 4. As there is no way to install the library where it should be – /usr/lib/pythonX.X/site-packages
, I used MAKEELFPATH
environment variable to find makeelf.
Less important scripts, but still sometimes useful, are the ones to generate graph of function cross-references. They are able of generating .dot file, which can be converted to PNG (which is bad way of making it useful – it is 32768 pixels wide) or opened somewhere. And I used Gephi to read the final graph.
binutils development
Also binutils fork was improved a little bit. It is now possible to see symbols on every jump and call instruction. Moreover I did a kind of hack to be able to see references to data, as they mostly consisted of two instructions – first setting upper half of register, then adding lower half. So in that case, objdump is now displaying content of register, which most of the time don’t work, as objdump parses code linearly, without caring about jumps. But, if this opcode pair is used to really reference some address, it is quite reliable, so it is possible to see the address, as well as symbol name, in same way as with calls. Also, there is much more information about opcode types, so completely unknown instructions had been eliminated. Some of them were not used a single time and were renamed to resXX – for reserved.
Does it make sense?
Now, as I know really a lot about the firmware, it is time to try to answer the question in the heading. Well, the goal of reversing the encoder was to find compression and checksum algorithm for SMEDIA/ITE firmware blob. And, as far as I know now, it is really likely that at least compression algorithm is in fact somewhere here. I can say that, because I’ve seen routine for processing the data that seem to be compressed in SMEDIA/SMAZ container. Moreover, SMEDIA itself is also processed here, in original form, as one of the firmware’s responsibilities is firmware upgrade, so it is being copied to some internal ROM. So, if both – compressed and decompressed versions of firmware is here, then decompression also should be somewhere.
Now, this reverse engineering work might take really, really long time to get some results, but on the other hand, I might find, what I am looking for today. So, now the topic will probably seem to be dead for some undefined time.