System testing of digital camera devices as reverse engineering

Modern digital cameras and cell phones containing digital cameras are merely complex microprocessor systems with ever-increasing amounts of functionality. This increased functionality is spread out between the software portion of the system and several processors. The CMOS image sensors typically have extensive image processing functionality built into them to help manage tasks like cropping and compression. These operations, however, are often duplicated in the hardware, which leads us to ask, why is this functionality duplicated and which IC performs these functions?

To understand the operation of a product, traditional circuit reverse engineering can be used; however, it can be an expensive undertaking. Software reverse engineering is another option; but this can be time-consuming work. So when circuit and software reverse engineering are not possible because of time and budget constraints, we turn to functional testing.

The timing picture of this particular smartphone consists of "power on" initialization; viewfinder mode; image capture;display off between shots; and return to the viewfinder mode. Click on image to enlarge.

Functional testing techniques can be used to demonstrate that a particular method of operation is being used. All examples featured in this article are related to image processing devices; however functional testing has been successfully used on other devices including TVs, Mobile Internet Devices (MIDs), computers, etc. Our objective for this article was to demonstrate how system functional testing techniques can be used to investigate the inner workings of an image processing device. The results of our experiments were had within just a few days and at a minimum expense.

The three scenarios we investigated include: testing a device using a datasheet of the camera module; testing a camera module as a black box; and the last case study requires testing different signals of the control logic of an image sensor on a board.

The first consumer device analyzed was a smartphone with a built-in 1600 x 1200 active pixels digital camera. The camera contains a serial control interface, JPEG encoder, and supports different output formats including RGB, YUV, Bayer and JPEG. Our goal was to understand the various modes of operation of the camera module and to find out where JPEG compression occurred. The image module contained an internal JPEG encoder. Therefore the compression process could either take place inside the sensor or in a separate IC.

We tested the device by capturing signals from the camera module with a logic analyzer, followed by a software-based reconstruction of commands on a control bus and determination of the image data format. Figure 1 shows the big picture, the operation of the phone during image capture.

The camera module has two preliminary programmed contexts that have different parameters. Both contexts are set up during the "power on" initialization. During operation it requires several commands from the control bus to switch between the contexts; the use of a slow speed serial control bus greatly reduces the switching time between image shots. Context_0 with 640x480 pixels resolution and RGB565 output format is used in the viewfinder mode and context_1 has user-selected resolution and a JPEG 4:2:2 output signals format.

To view the image capture mode with 1600 x 1200 pixels resolution, and the file containing values of data output signals from the logic analyzer and a fragment of the command file on the serial control bus of the camera module, click here. (Note the start of the frame with JPEG defined pattern FFD8_FFDB).