Recherche avancée

Sur d’autres sites (5141)

• Brute Force Dimensional Analysis

  15 juillet 2010, par Multimedia Mike — Game Hacking, Python

  I was poking at the data files of a really bad (is there any other kind ?) interactive movie video game known simply by one letter : D. The Sega Saturn version of the game is comprised primarily of Sega FILM/CPK files, about which I wrote the book. The second most prolific file type bears the extension ’.dg2’. Cursory examination of sample files revealed an apparently headerless format. Many of the video files are 288x144 in resolution. Multiplying that width by that height and then doubling it (as in, 2 bytes/pixel) yields 82944, which happens to be the size of a number of these DG2 files. Now, if only I had a tool that could take a suspected raw RGB file and convert it to a more standard image format.

  Here’s the FFmpeg conversion recipe I used :

   ffmpeg -f rawvideo -pix_fmt rgb555 -s 288x144 -i raw_file -y output.png
  

  So that covers the files that are suspected to be 288x144 in dimension. But what about other file sizes ? My brute force approach was to try all possible dimensions that would yield a particular file size. The Python code for performing this operation is listed at the end of this post.

  It’s interesting to view the progression as the script compresses to different sizes :

  
  
  

  That ’D’ is supposed to be red. So right away, we see that rgb555(le) is not the correct input format. Annoyingly, FFmpeg cannot handle rgb555be as a raw input format. But this little project worked well enough as a proof of concept.

  If you want to toy around with these files (and I know you do), I have uploaded a selection at : http://multimedia.cx/dg2/.

  Here is my quick Python script for converting one of these files to every acceptable resolution.

  work-out-resolution.py :
  

  PLAIN TEXT

  PYTHON :

  1. # !/usr/bin/python
  2.  
  3. import commands
  4. import math
  5. import os
  6. import sys
  7.  
  8. FFMPEG = "/path/to/ffmpeg"
  9.  
  10. def convert_file(width, height, filename) :
  11.  outfile = "%s-%dx%d.png" % (filename, width, height)
  12.  command = "%s -f rawvideo -pix_fmt rgb555 -s %dx%d -i %s -y %s" % (FFMPEG, width, height, filename, outfile)
  13.  commands.getstatusoutput(command)
  14.  
  15. if len(sys.argv) <2 :
  16.  print "USAGE : work-out-resolution.py <file>"
  17.  sys.exit(1)
  18.  
  19. filename = sys.argv[1]
  20. if not os.path.exists(filename) :
  21.  print filename + " does not exist"
  22.  sys.exit(1)
  23.  
  24. filesize = os.path.getsize(filename) / 2
  25.  
  26. limit = int(math.sqrt(filesize)) + 1
  27. for i in xrange(1, limit) :
  28.  if filesize % i == 0 and filesize & 1 == 0 :
  29.   convert_file(i, filesize / i, filename)
  30.   convert_file(filesize / i, i, filename)

• Official RealVideo Specifications

  29 juillet 2010, par Multimedia Mike — General

  A little birdie tipped me off to a publicly-accessible URL on the Helix community site (does anyone actually use Helix ?) that contains a bunch of specifications for RealVideo 8 and 9. I have been sifting through the documents to see exactly what they contain as the different files seem to be higher revisions of the same documents. Here is the title, date, and version of each PDF document :

  • RNDecoderPerformanceARM.pdf : Decoder Performance on StrongARM and XScale ; May 12, 2003 ; Version 1.1
  • rv89_decoder_summary.pdf : RealVideo 8/9 Combo Decoder Summary ; October 23, 2002 ; Version 1.0
  • rv9_dec_external_spec_v14.pdf : RealVideo 9 External Specification ; November 7, 2003 ; Version 1.4
  • rv8_dec_external_spec_v20.pdf : RealVideo 8 External Specification ; September 19, 2002 ; Version 2.0
  • RV8DecoderExternalSpecificationv201.pdf : RealVideo 8 External Specification ; October 20, 2006 ; Version 2.01
  • RV8DecoderExternalSpecificationv202.pdf : RealVideo 8 External Specification ; April 23, 2007 ; Version 2.02
  • RV8DecoderExternalSpecificationv203.pdf : RealVideo 8 External Specification ; July 20, 2007 ; Version 2.03
  • RV8DecoderExternalSpecificationv21.pdf : RealVideo 8 External Specification ; September 11, 2007 ; Version 2.1
  • RV9DecoderExternalSpecificationv15.pdf ; RealVideo 9 External Specification ; January 26, 2002 ; Version 1.5
  • RV9DecoderExternalSpecificationv16.pdf ; RealVideo 9 External Specification ; August 17, 2005 ; Version 1.6
  • RV9DecoderExternalSpecificationv18.pdf ; RealVideo 9 External Specification ; September 11, 2007 ; Version 1.8

  Additionally, there is an Excel spreadsheet entitled realvideo-faq.xls that appears to contain some general tech support advice for using Real’s official code. There are also 3 ZIP archives which contain profiling information about the official source code (post processing and entropy decoding top the charts which is no big surprise).

  I guess the latest version of each document (the ones dated September 11, 2007) are worth mirroring. Unfortunately, those latest document versions use a terrible font.

• Resurrecting SCD

  6 août 2010, par Multimedia Mike — Reverse Engineering

  When I became interested in reverse engineering all the way back in 2000, the first Win32 disassembler I stumbled across was simply called "Win32 Program Disassembler" authored by one Sang Cho. I took to calling it ’scd’ for Sang Cho’s Disassembler. The original program versions and source code are still available for download. I remember being able to compile v0.23 of the source code with gcc under Unix ; 0.25 is no go due to extensive reliance on the Win32 development environment.

  I recently wanted to use scd again but had some trouble compiling. As was the case the first time I tried compiling the source code a decade ago, it’s necessary to transform line endings from DOS -> Unix using ’dos2unix’ (I see that this has been renamed to/replaced by ’fromdos’ on Ubuntu).

  Beyond this, it seems that there are some C constructs that used to be valid but are now rejected by gcc. The first looks like this :

  PLAIN TEXT

  C :

  1. return (int) c = *(PBYTE)((int)lpFile + vCodeOffset) ;

  Ahem, "error : lvalue required as left operand of assignment". Removing the "(int)" before the ’c’ makes the problem go away. It’s a strange way to write a return statement in general. However, ’c’ is a global variable that is apparently part of some YACC/BISON-type output.

  The second issue is when a case-switch block has a default label but with no code inside. Current gcc doesn’t like that. It’s necessary to at least provide a break statement after the default label.

  Finally, the program turns out to not be 64-bit safe. It is necessary to compile it in 32-bit mode (compile and link with the ’-m32’ flag or build on a 32-bit system). The static 32-bit binary should run fine under a 64-bit kernel.

  Alternatively : What are some other Win32 disassemblers that work under Linux ?