security research repository of nathan andrew fain / cyphunk

Targeting the Panasonic HVX200 HD camera

photo by Clint McManaman
photo by Clint McManaman

Update 2010.03: Deti has found a way modify the image enough to start a “service” menu. See his thread, he explains this and much more (german thread)

This is a semi-professional HD video camera that sells for -5000. Regardless if you have this camera or not the methods discussed herein should encourage you to pull apart any device you have. Even with such a pricetag the hardware and software of the device are rather comprehensible, in some cases laughably so. In such cases I’m not laughing at Panasonic but rather at myself for thinking that this would be more complicated. That is the objective of this tutorial, to help the reader realize that, if nothing else, the initial stage of diving in is easy and fun.

The camera is popular with independent producers but has its areas that could be improved. The camera runs a Montavista Linux operating system on top a SuperH SH4 subtype SH7751 CPU. Storing of HD video is done using “Panasonic P2” cards. These appear to be PCMCIA cards with flash chips and a RAID controller which greatly increase data writing speeds. There are many improvements that a homebrew system could bring to this camera. As an example of some low hanging fruit: Adding support for offloading video from the P2 card in the camera to an external disk using either a usb or firewire controller. While there are other modifications that come to mind this would let someone use a single P2 card to record endless amounts of video instead of paying for a mountain of expensive P2 cards. Another would be dissection of the P2 card and replacing the flash chips of a cheap 4GB card to increase the size to 64GB?


  1. Obtaining Firmware
  2. Firmware Dissection
  3. Hardware Overview
  4. Target List Assessment
  5. Obtaining Debug Console
  6. Developing Software For Camera
  7. Modifying Firmware
  • Modification wishlist

1. Obtaining Firmware

There are a few routes to obtain the firmware, in order of difficulty:

[A] obtain a manufacturers firmware update and hope that it contains a system image,
[B] use the debug mechanism and ports (Serial, Network and TFTP, JTAG?) to download the running system image from internal FLASH,
[C] desolder the FLASH or ROM memory chips found inside the target and dump the contents with a compatible memory programmer

In the case of the Panasonic HVX200 the firmware updates contain an entire image of the system and can be obtained from the Panasonic website (ref2). Important: the version I am working with is  v4.06-00-0.00 (aka version “vsi4598g”) which can be downloaded directly from panasonic or found in the project working directory.

1.1. Decompressing Firmware Updates

Update: A shorter method for decompressing firmware is… just untar and unzip the update file with “tar -zxvf <updatefile>”. I will retain the old direction because it’s useful knowledge for other projects/targets you might run into.

The firmware update is compressed. I use a program called STUNS which searches the file attempting to decompress any block of data using various compression routines. The developers website has since gone offline but I’ve placed a copy with the source code and compiled version for windows in the project working directory. Execute the program on the compressed firmware. Upon completion you will find directories created for each type of compression and inside are thousands of files for each block it attempted to decompress.  The largest block is the winner.  In the case of the HVX the firmware is compressed with the deflate compression routine. I’ve placed a copy of the uncompressed version in the project working directory.  Even in this state you can already open the file in a Hex editor or run it through `strings` to find a wealth of information.

2. Firmware Dissection

2.1. Basic Examination of Strings

SH IPL+g version 0.9, Copyright (C) 2000 Free Software Foundation, Inc.

Looking at the strings of the decompressed firmware it should stand out that this is a Linux system and that the image contains several filesystems. Before pulling the file systems out lets just look at the strings to see what we can determine.

That is the bootloader version information. “It is an Initial Program Loader(IPL) of many SH-based systems booting Linux kernel. It functions as gdb-stub to provide the way to communicate with GNU gdb debugger. Also, it acts as a BIOS of the system.” (ref1, ref2)

# CONFIG_CPU_SUBTYPE_SH7300 is not set 
# CONFIG_CPU_SUBTYPE_SH7707 is not set 
# CONFIG_CPU_SUBTYPE_SH7708 is not set 
# CONFIG_CPU_SUBTYPE_SH7709 is not set 
# CONFIG_CPU_SUBTYPE_SH7750 is not set 
# CONFIG_CPU_SH3 is not set 
# CONFIG_P2PF_K200 is not set 
# CONFIG_P2PF_K250 is not set 

That is part of  the configuration file for compiling a Linux kernel. It shows us that the CPU is a SuperH SH4 subtype SH7751. This family of CPUs are also used with Sega gamesystems and some PayTV Set Top Boxes.

Linux version 2.4.20_mvl31-ms7751rse01-sh_sh4_le (root@rx7)
(gcc version 3.3.1 (MontaVista 3.3.1- 2006-04-30))
#13 Thu Mar 22 19:28:14 JST 2007

That show that the camera is running a 2.4.20 linux kernel compiled with gcc version 3.3.1.  We also see the version of MontaVista linux being used.  These details are important because if we ever want to compile our own software for this system we will need to setup, at a minimum, an environment that includes the Linux 2.4.20 headers, the version of glibc being used in this MontaVista version and a gcc 3.3.1 crosscompiler for SH4 platforms (or crosstoll.)

description=NetChip 2280 USB Peripheral Controller

That string is part of the net2280.o kernel module and indicates the USB driver.  This already gives some promise to obtaining our objective of supporting an external USB disk. Though we would still need to find USB host drivers somewhere. It is important to determine which drivers are already available because if we have to add and compile additional drivers we will likely need more than just the Linux headers, glibc and compatible gcc version. We would perhaps need the entire MontaVista development kit so that we could both compile the driver and add support to the kernel for the driver, meaning perhaps we even have to recompile the entire kernel.  Yuk.

7791c147ef8f33e7c9844d20992e4fd8  netboot-1st.binary
9004619ae34aad3bbbc7cca53e3b7444  netboot1.binary
21910d91dcbae05a0688acce08ef86df  netboot2.binary
e0be87ce4e9c70deddb828a17f931488  vmlinux.bin
cedfadc76e06cca69602424d3a277a39  rootfs.image
b21555e3f845831d455d9f679277ac57  home.image
e9a74405904af1544bdfe5cb1363858b  vmlinux-vup.bin
f5fcfa007950817cca499da3ae13bf53  ramdisk.gz
df7e7b23160729e90add6b437db2b278  tx.bin
f1d3ff8443297732862df21dc4e57262  txvups.bin
a54f0041a9e15b050f25c463f1db7449  txvupe.bin

Those strings appears at the very end of the uncompressed firmware image and indicates the various parts of the image.  We also find tons of scripts in in the file but it would be nice to map these to their filenames.

2.2. Mounting Firmware Filesystem

There are a few images/filesystems contained internally in the uncompressed firmware. I made a lucky guess that these were CramFS images. If this was not the case, to determine what type of filesystem for the internal image we would use a program that attempts to match “magic” strings (mime/type, magic/type databases) to bytes in the raw firmware images, by searching over the file looking for matches.  At the moment I do not remember the name for such a program but contact me if you need this for other projects.

Confirmation of a CramFS image came in the form of these strings found in the firmware image:


The 4 bytes (in reverse endianness) at 00632600 also indicate a CramFS filesystem as proven by the Linux cramfs_fs.h header file:

* Superblock information at the beginning of the FS.
struct cramfs_super {
u32 magic; /* 0x28cd3d45 - random number */
u32 size; /* length in bytes */
u32 flags; /* feature flags */
u32 future; /* reserved for future use */
u8 signature[16]; /* "Compressed ROMFS" */
struct cramfs_info fsid; /* unique filesystem info */
u8 name[16]; /* user-defined name */
struct cramfs_inode root; /* root inode data */

There are two such superblocks found in the image file.  We can use either the tool `cramfsck -x <dir> <imagefile>` or `uncramfs` (ref2) to extract the files.  I recommend cramfsck but uncramfs also works and compiles better on OSX, which is my current workstation. To use either, in your hex editor of choice select all of the bytes from where “45 3D CD 28” is found until the end of the file. Place this data into a new file.  I’ve create two such files that can be found in the project working directory called first_cramfs_img_toEOF and second_cramfs_img_toEOF. After extracting using cramfsck or uncramfs you should have two directory structures as seen here:
HVX200 CramFS directory structure

From this we can guess that the first is the rootfs.image and the second the home.image referenced at the end of the uncompressed firmware.

2.3. Panasonic Specific Drivers and Software in Firmware – Targets

Now that we have the filesystem I’d like to both start compiling a list of targets (software to be reverse engineered) and to better understand the internal hardware and functional components. This requires some familiarity with linux systems so that you can deduce what is common to basic linux systems and what is specifically added by Panasonic. Lets start walking through it.

2.3.1. first_cramfs_image_toEOF.mount (rootfs.image) /dev/

The device handles that are new to me here are /dev/rt, /dev/vcs and /dev/vcsa. /dev/rt is still a mystery for me but the vcs and vcsa devices are Virtual Console Capture devices (according to a common linux device list). From the Linux Cookbook (ref2):

If the target console is the first virtual console (which you would see by typing [ALT]-[F1]), the device to cat is `/dev/vcs1′. To take a screen shot of the fourth virtual console, and save it to a file called `screenshot’, type:

$ cat /dev/vcs4 > screenshot [RET]

In order to re-display the screenshot just paste it back into a free virtual console, type:

$ cat screenshot > /dev/vcs4 [RET]

Hence, we might be able to use this for debugging, provided we find some way of grabbing the screencapture file. Then again, maybe just setting up a serial terminal is going to be easier. /etc/init.d/

This directory commonly contains the startup scripts for a linux system that are used to start services that will run in the background while the system is up, load drivers and enable devices. When examining these files I will only include excerpts from the scripts.


# Panasonic P2 original pcmcia script 2004/07/30
. /lib/modules/`uname -r`/pcmcia-config/pcmcia
    case "$action" in
	/sbin/modprobe pcmcia_core
	/sbin/modprobe i82365 irq_mode=0
	/sbin/modprobe ds
	/sbin/modprobe cb_enabler
 /sbin/modprobe spd_mod > /dev/null 2>&1 	/sbin/cardmgr -q -c /lib/modules/`uname -r`/pcmcia-config
	touch /var/lock/subsys/pcmcia

All of the modules loaded with this script are common except for spd_mod. i82365 indicates that we are using a Intel i82365sl PCMCIA host controller (there are many clones, ref1). Let’s examine briefly the strings in ./first_cramfs_img_toEOF.mount/lib/modules/2.4.20_mvl31-ms7751rse01-sh_sh4_le/pcmcia/spd_mod.o.


<3>[spd]4:%s:%d:R5C812 on Unkown 
<3>[spd]4:%s:%d:R5C812 on WRITE 
<3>[spd]4:%s:%d:R5C812 on READ
<3>[spd]4:%s:%d:register_chrdev() failed(%d)
<3>[spd]4:%s:%d:invalid minor number(%d)
<3>[spd]4:%s:%d:unknown ioctl command(%d)
<3>[spd]4:%s:%d:copy_to_user() failed(%d)
<3>[spd]4:%s:%d:spd_identify_device() failed(%d)
<3>[spd]4:%s:%d:copy_form_user() failed(%d)
<3>[spd]4:%s:%d:spd_read_sector() failed(%d)
<3>[spd]4:%s:%d:udev_make_sg() failed(%d)
<3>[spd]4:%s:%d:spd_write_sector() failed(%d)
<3>[spd]4:%s:%d:spd_log_sense() failed(%d)
<3>[spd]4:%s:%d:spd_log_write() failed(%d)
<3>[spd]4:%s:%d:spd_block_erase() failed(%d)
<3>[spd]4:%s:%d:spd_sector_erase() failed(%d)
<1>[spd]2:%s:%d:ALERT:P2card firmware size 61h only but size=%02xh <3>[spd]4:%s:%d:spd_firm_update() failed(%d)
<3>[spd]4:%s:%d:scatterlist overflow(%d)
<3>[spd]4:%s:%d:spd_read_capacity() failed(%d)

It is obvious from the various symbols found that this driver is used for writing to some form of memory card. We also find two important strings, “ALERT:P2card” which indicates that this driver is specific to the P2 card and “R5C812“. R5C812 indicates that we have a PCMCIA controller from Rocah, in particular the model which supports two PCMCIA/PCcard slots, such is the case on the HVX200. Examination of the product sheet confirms that this device is also used to control the SD card slot of the camera. We can put this driver into a list of potentially high value targets. With a file size of 98KB and the wonderful gift of a symbol table left in this might not be so dificult to analyze.


### execute application for MontaVista Linux Pro. 3.1
##   by Panasonic
# preload drivers       #
# set environment value #
. /etc/p2pfenv
ulimit -c 0
# application start #
cd /var
/home/apli/sg &

A look at the /etc/p2pfenv script shows that it preloads a driver for the SD card but also gives another possible target in its comments where a module that enables a character driver of the camera is commented out (scullp.o – see “Simple Character Utility for Loading Localities”). This is the mode the camera is put into when plugged up to a PC for offloading video (see ‘home/apli/‘). Herein we might find code for both reading the P2 card filesystem and setting up as a USB client.


# preload drivers #
insmod /lib/modules/2.4.20_mvl31-ms7751rse01-sh_sh4_le/kernel/drivers/sdcard/sdcard.o \
> /dev/null 2>&1
#use only PC mode
#insmod /home/usb/scullp.o > /dev/null 2>&1

In scullp.o we have strings which indicate the developers login name and the project name in addition to plenty of symbols that confirm that this can access and control the P2 card (not shown here) so lets add scullp.o to our list of Panasonic specific targets:

/home/tanaka/work/K230/myapplication/p2pf/src/driver/usb/buffer also executes .//second_cramfs_img_toEOF.mount/apli/sg. When examining this file we get a load of other targets:

ZION VGA Initialize(NTSC) Success!!
Create UM
Create SM
createSV::arg error eSgStatuse=%d
execl[EXT] error(%s)
execl[VUP] error(%s)

… to be continued


Published by

33 responses to “Targeting the Panasonic HVX200 HD camera”

  1. I’m very interested to know how you’re going with this project. I am very keen to have P2 support in Linux.

  2. I cant figure out why you used STUNS.
    The Firmware file is a gzipped TAR.
    Do you think it might be possible to allow harddisk recording to an USB or Firewire Device?

    1. W3aZL: yes, STUNS wasnt needed here. untaring creates the complete file structure. I was writing another update but got busy with, life. I’d still mention STUNS because for other projects it is helpful.

  3. Panasonic has released the source code for one of their P2 Mobile recorders:

    I’m currently looking though it and am interested in porting the P2 drivers and utilities to a modern kernel.

    1. I’d be happy to help and join you.

    2. Update of the link for the GPL code they have released, with HVX200 still no where to be found

    3. I sent a request for the GPL sources and Panasonic sent a CD. I’ve uploaded this here

  4. You Rock!!!
    I shall be watching this thread with interest because My HVX200 is the only thing still tying me to windows. Not only that but my camera won’t output thought the firewire so I have to use P2 cards. I wish I had the skills to help with more than morel support but as it is all I can do is say good luck.

  5. i took the camera apart:
    hopefully i will have time to write up the findings in the next few weeks.

  6. i’m following this thread with big interest.

    1. py, it’s still on my plate. looking at the internals was a bit discouraging simply because the complexity is massive. so it is back to software analysis. it is slow going but hopefully within the next 3 weeks (seriously this time) I will get back to it.

  7. Great details on filesystem carving. The reference links are handy too!

    Keep up the good work,


    1. KvXt4T TYVM you’ve solved all my poberlms

  8. How goes this project?
    You guys must be software engineers or something. Easy? I dunno about that. This looks like a lot of work for someone with minimal programming skills.

    I think though, that you will get huge respect for creating a way to record huge amounts of data with a single P2 card. Hope to see that soon… keep it up!

  9. cyphunk did you ever put your camera back together in working order? more pics of that process would be nice to see. Looks like you had some fun taking it apart!

  10. Jonny5, send me an email cyphunk at and I can send you detailed pictures of everything.

  11. oh and, yes i put it back together and everything works fine. Also, concerning updates, I think things will move faster now that more people are working on it. See the update note at top

  12. Hi cyphunk! Where are you now on your reserch??? Do you think it will be possible to add more framerate to the cam? Something like 60-70-100fps maybe to 720mode???

  13. Please ease me to frame bank

  14. Interesting work, are you still going? My interest is in the P2 cards. Have you dissected one?
    It is thought there are SD cards and a RAID controller.

    1. Rich,
      I have not dissected one but yes based on what I have seen (in this article) it is some form of SD RAID, ontop of SDP-2 drivers, ontop of the Ricoh R5C812 controller which uses the Intel i82365 driver. I haven’t looked at it in some time but I would love to. If you have a card to open or images of internals let me know. Still keen to analyze the drivers relating to this.

  15. By the way,

    Any linux shell script placed in the following directory on the SD card will be executed when the device starts: PRIVATE/MEIGROUP/PAVCN/SBG/P2SD/MNTNC

    There are various interesting scripts and commands that help when debugging. Example script:

    # Turn LED On and Off 10 times:
    vupled 1000 500 10
    # write ‘ps aux’ + /var/log/messages to log.txt on sd card:
    /usr/local/bin/getshinfo log.txt
    # List /proc:
    mntsd #mount sd card
    find /proc > /mnt/sdcarda/proclist.txt
    umount /mnt/sdcarda

    # Other commands:
    # Dump area of Flash rom:
    # dumpFlashRom [area-type] [output] ([block no])
    # Dump area from Zion MBUS:
    # dumpMbus startAddress(hex) [stopAddress(hex)]
    # ex) dumpMbus 1000
    # dumpMbus 1000 1100
    # Dump SRAM:
    # dumpSram startAddress(hex) [stopAddress(hex)]

    1. I forgot to point out and the dumpSram and other dump* commands are in /usr/local/bin. Other commands to play with in /usr/local/bin:

      vupfb f [p16 bitmap imagefilename] : Display bitmapfile.
      vupfb p [progress value(%)] : Update progress bar.
      vupfb m [message] : Update message string.
      vupfb bp [value1(%)] [value2(%)] [time1(us)] [time2(us)] [count] : Brink progress bar.
      vupfb bm [message1] [message2] [time1(us)] [time2(us)] [count] : Brink message string.
      vupfb i [PAL/NTSC] : Initialize VGA

      Already you could run a infinite loop script within a nohup session (backgrounds it) which routinely copies files off the p2 card and onto SD or via any other interface you find so that you never have to take out your P2 card to offload.

    2. For future reference, how and why I suggest the device will execute the script above. Working in reverse, find where ‘PRIVATE/MEIGROUP/PAVCN/SBG/P2SD/MNTNC’ is called in firmware:

      1. extracted firmware
      tar -zxvf K2302028.img
      cd _K2302028.img
      cramfsck -x _rootfs.image rootfs.image
      cramfsck -x _home.image home.image

      2. find string
      result found in _K2302028.img/_home.image/apli/
      inspection of script shows it mounts sd card, cd’s to the PRIVATE/MEIGROUP/PAVCN/SBG/P2SD/MNTNC path on sd card, then does a `find . -name “*.sh” | tail -1` and then executes the last .sh script found.

      3. confirm is called
      rg -a
      result found in _K2302028.img/_home.image/apli/sg a binary application.
      rg -a ‘apli/sg’
      apli/sg is itself called by _K2302028.img/_rootfs.image/etc/init.d/

      Hopefully this is enough should someone want to understand the original comment. Upon review of apli/sg though it does appear that execution of is conditional and requires further disassembly or dynamic testing to determine conditions that run that script.

  16. Where can i find STUNS? There is no files in the project folder.

    1. Sorry, I had the wrong link for the working directory. It should point to — fixed, thanks. Also you can find it at

  17. Are there any updates on what’s become of this project?

    You folks should also consider checking out the project that a man named Juan was putting together a few years ago, extracting a RAW image from the camera’s CCD imager to get more dynamic range and better noise control.

    the DVX version was called Andromeda and the HVX version was Hydra.

    If this possibility can be done within camera with software…then you all can be onto something real big here.

    Unfortunately, Juan was quietly bought out by some private unmentioned company and was told not to talk about the system he created to extract the RAW data and the software used to decode the signal into an image.

    check it out!!

    1. Saw the HydraTM modification press release but it never came to fruition. But this is the general idea with exploring this camera to take more advantage of the hardware and provide more flexibility. But no one has really continued past what you see here. Perhaps some day.

  18. […] HD 3CCD camera is linux based. I stalled some years ago but recently found schematics and better documentation. With certainty we can find/rebuild a […]

  19. I’ve started looking at the hardware again. At the moment im analyzing the two connectors found underneath the battery. There is one flat 30 contact ribbon cable (FFC) connector (part# 52976-3072) and a two row 30 pin WR3 connector (part # wr-30p-hf-hd-a1e). Ordered parts to build connectors:

    52976-3072* to cable FFC 021020-0323?* to 52976-3072

    WR-30P-HF-HD-A1E* to WR-30S-VFH05-N1*

    * links to seller (digikey, mouser)

    In the process ive looked for tools or breakout boards that could help. All I could find are some FFC breakouts. One 60 pin but might work anyway. There are also some FFC connectors to cables that might help.

    1. Actually the 60pin FFC breakout mentioned (1mm) will not work on the HVX (0.5mm). But there are others

  20. I wonder if there is a way to fund this project to keep it alive? Look at the success of the Magic Lantern software for canon DSLRs. People are always looking for ways to breath new life into their equipment. An uncompressed image is the ultimate goal for me though.

  21. anything new since 2014?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s