Recherche avancée
Autres articles (75)
-
La sauvegarde automatique de canaux SPIP
1er avril 2010, parDans le cadre de la mise en place d’une plateforme ouverte, il est important pour les hébergeurs de pouvoir disposer de sauvegardes assez régulières pour parer à tout problème éventuel.
Pour réaliser cette tâche on se base sur deux plugins SPIP : Saveauto qui permet une sauvegarde régulière de la base de donnée sous la forme d’un dump mysql (utilisable dans phpmyadmin) mes_fichiers_2 qui permet de réaliser une archive au format zip des données importantes du site (les documents, les éléments (...) -
Script d’installation automatique de MediaSPIP
25 avril 2011, parAfin de palier aux difficultés d’installation dues principalement aux dépendances logicielles coté serveur, un script d’installation "tout en un" en bash a été créé afin de faciliter cette étape sur un serveur doté d’une distribution Linux compatible.
Vous devez bénéficier d’un accès SSH à votre serveur et d’un compte "root" afin de l’utiliser, ce qui permettra d’installer les dépendances. Contactez votre hébergeur si vous ne disposez pas de cela.
La documentation de l’utilisation du script d’installation (...) -
Automated installation script of MediaSPIP
25 avril 2011, parTo overcome the difficulties mainly due to the installation of server side software dependencies, an "all-in-one" installation script written in bash was created to facilitate this step on a server with a compatible Linux distribution.
You must have access to your server via SSH and a root account to use it, which will install the dependencies. Contact your provider if you do not have that.
The documentation of the use of this installation script is available here.
The code of this (...)
Sur d’autres sites (7243)
-
Chrome times out on streaming FFMPEG output from ASP.NET Web Api
3 août 2014, par Hayden McAfeeI’ve got a unique problem here !
UPDATE 2 So it turns out the development below is FALSE, the inconsistency of the bug made it seem like not closing the stream made it work... but in fact the same issue persists !
UPDATE Interesting development ; if I comment outffmpegBufferedIn.Close();below, the entire stream always goes through fine... the request just never ends. What could be going on here ?I’m writing a web service that stores audio files in Azure Blob Storage, and converts them to MP3 live when requested through my ASP.NET Web API endpoint. I accomplish this by using ’DownloadToStream’ via the Azure Storage API, feeding that stream through the STDIN of an FFMPEG process, and sending the STDOUT stream as the request response.
The block of code that does this looks like this :
public HttpResponseMessage Get(Guid songid)
{
// This could take awhile.
HttpContext.Current.Server.ScriptTimeout = 600;
Process ffmpeg = new Process();
ProcessStartInfo startinfo = new ProcessStartInfo(HostingEnvironment.MapPath("~/App_Data/executables/ffmpeg.exe"), "-i - -vn -ar 44100 -ac 2 -ab 192k -f mp3 - ");
startinfo.RedirectStandardError = true;
startinfo.RedirectStandardOutput = true;
startinfo.RedirectStandardInput = true;
startinfo.UseShellExecute = false;
startinfo.CreateNoWindow = true;
ffmpeg.StartInfo = startinfo;
ffmpeg.ErrorDataReceived += ffmpeg_ErrorDataReceived;
// Our response is a stream
var response = Request.CreateResponse();
response.StatusCode = HttpStatusCode.OK;
// Retrieve storage account from connection string.
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(
CloudConfigurationManager.GetSetting("StorageConnectionString"));
// Create the blob client.
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
// Retrieve reference to a previously created container.
CloudBlobContainer container = blobClient.GetContainerReference("songs");
// Retrieve reference to a blob
CloudBlockBlob blockBlob = container.GetBlockBlobReference(songid.ToString());
ffmpeg.Start();
ffmpeg.BeginErrorReadLine();
// Buffer the streams
var ffmpegBufferedIn = new BufferedStream(ffmpeg.StandardInput.BaseStream);
var ffmpegBufferedOut = new BufferedStream(ffmpeg.StandardOutput.BaseStream);
blockBlob.DownloadToStreamAsync(ffmpegBufferedIn).ContinueWith((t) => {
ffmpegBufferedIn.Flush();
ffmpegBufferedIn.Close();
});
response.Content = new StreamContent(ffmpegBufferedOut);
response.Content.Headers.ContentType = new MediaTypeHeaderValue("audio/mpeg");
System.Diagnostics.Debug.WriteLine("Returned response.");
return response;
}This works quite well in all browsers - all except for Chrome, which has an interesting way of buffering audio streams. Chrome will buffer the first 2 megabytes of a stream, then keep the connection open and wait until the user gets closer to playing the next segment of a file before consuming the rest of the stream. This should be fine - and for some songs it is. For others, I get this :
At first I thought this was due to some kind of timeout - But it happens at a different time and size for each file. It is consistent within about 15 seconds on the same songs, however. The output on the server side is normal - no exceptions thrown, and FFMpeg finishes encoding the song successfully.
Here’s the server-side output of the above request :
ffmpeg version N-64919-ga613257 Copyright (c) 2000-2014 the FFmpeg developers
built on Jul 23 2014 00:27:32 with gcc 4.8.3 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
libavutil 52. 92.101 / 52. 92.101
libavcodec 55. 69.100 / 55. 69.100
libavformat 55. 48.101 / 55. 48.101
libavdevice 55. 13.102 / 55. 13.102
libavfilter 4. 11.102 / 4. 11.102
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.100
Input #0, mp3, from 'pipe:':
Metadata:
TSRC : AUUM71001516
title : Sunlight
track : 2
artist : Bag Raiders
copyright : 2010 Modular Recordings
genre : Electronic
album : Bag Raiders
album_artist : Bag Raiders
disc : 1/1
publisher : Modular Recordings
composer : Chris Stracey/Jack Glass/Dan Black
date : 2010
Duration: N/A, start: 0.000000, bitrate: 320 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 320 kb/s
Stream #0:1: Video: mjpeg, yuvj420p(pc, bt470bg), 600x600 [SAR 300:300 DAR 1:1], 90k tbr, 90k tbn, 90k tbc
Metadata:
title :
comment : Other
Output #0, mp3, to 'pipe:':
Metadata:
TSRC : AUUM71001516
TIT2 : Sunlight
TRCK : 2
TPE1 : Bag Raiders
TCOP : 2010 Modular Recordings
TCON : Electronic
TALB : Bag Raiders
TPE2 : Bag Raiders
TPOS : 1/1
TPUB : Modular Recordings
TCOM : Chris Stracey/Jack Glass/Dan Black
TDRL : 2010
TSSE : Lavf55.48.101
Stream #0:0: Audio: mp3 (libmp3lame), 44100 Hz, stereo, s16p, 192 kb/s
Metadata:
encoder : Lavc55.69.100 libmp3lame
Stream mapping:
Stream #0:0 -> #0:0 (mp3 (native) -> mp3 (libmp3lame))
size= 6kB time=00:00:00.21 bitrate= 227.6kbits/s
size= 102kB time=00:00:04.31 bitrate= 193.7kbits/s
size= 202kB time=00:00:08.56 bitrate= 192.9kbits/s
size= 341kB time=00:00:14.49 bitrate= 192.5kbits/s
size= 489kB time=00:00:20.82 bitrate= 192.4kbits/s
size= 642kB time=00:00:27.35 bitrate= 192.3kbits/s
size= 792kB time=00:00:33.75 bitrate= 192.2kbits/s
size= 950kB time=00:00:40.49 bitrate= 192.2kbits/s
size= 1106kB time=00:00:47.15 bitrate= 192.2kbits/s
size= 1258kB time=00:00:53.63 bitrate= 192.1kbits/s
size= 1415kB time=00:01:00.31 bitrate= 192.1kbits/s
size= 1563kB time=00:01:06.66 bitrate= 192.1kbits/s
size= 1710kB time=00:01:12.90 bitrate= 192.1kbits/s
size= 1857kB time=00:01:19.17 bitrate= 192.1kbits/s
size= 2008kB time=00:01:25.63 bitrate= 192.1kbits/s
size= 2162kB time=00:01:32.21 bitrate= 192.1kbits/s
size= 2299kB time=00:01:38.03 bitrate= 192.1kbits/s
size= 2457kB time=00:01:44.80 bitrate= 192.1kbits/s
size= 2600kB time=00:01:50.89 bitrate= 192.1kbits/s
size= 2755kB time=00:01:57.52 bitrate= 192.1kbits/s
size= 2864kB time=00:02:02.17 bitrate= 192.1kbits/s
size= 3022kB time=00:02:08.88 bitrate= 192.1kbits/s
size= 3172kB time=00:02:15.31 bitrate= 192.1kbits/s
size= 3284kB time=00:02:20.06 bitrate= 192.1kbits/s
size= 3385kB time=00:02:24.40 bitrate= 192.1kbits/s
size= 3529kB time=00:02:30.51 bitrate= 192.0kbits/s
size= 3687kB time=00:02:37.25 bitrate= 192.0kbits/s
size= 3838kB time=00:02:43.71 bitrate= 192.0kbits/s
size= 3988kB time=00:02:50.11 bitrate= 192.0kbits/s
size= 4138kB time=00:02:56.53 bitrate= 192.0kbits/s
size= 4279kB time=00:03:02.54 bitrate= 192.0kbits/s
size= 4408kB time=00:03:08.03 bitrate= 192.0kbits/s
size= 4544kB time=00:03:13.85 bitrate= 192.0kbits/s
size= 4683kB time=00:03:19.78 bitrate= 192.0kbits/s
size= 4805kB time=00:03:24.95 bitrate= 192.0kbits/s
size= 4939kB time=00:03:30.67 bitrate= 192.0kbits/s
size= 5049kB time=00:03:35.38 bitrate= 192.0kbits/s
size= 5141kB time=00:03:39.32 bitrate= 192.0kbits/s
size= 5263kB time=00:03:44.49 bitrate= 192.0kbits/s
size= 5372kB time=00:03:49.17 bitrate= 192.0kbits/s
The thread 0xb24 has exited with code 259 (0x103).
size= 5436kB time=00:03:51.91 bitrate= 192.0kbits/s
size= 5509kB time=00:03:55.02 bitrate= 192.0kbits/s
size= 5657kB time=00:04:01.32 bitrate= 192.0kbits/s
size= 5702kB time=00:04:03.22 bitrate= 192.0kbits/s
video:0kB audio:5701kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.005738%Any ideas ? I’m grateful for suggestions - I’ve been chasing this for a week now !
-
FFmpeg - downmixing FLAC 6.1 to AAC 5.1
7 juillet 2014, par MartijnI can’t seem to figure out how to do this. I’ve been staring at these commands :
https://trac.ffmpeg.org/wiki/AudioChannelManipulationBut to no avail. It’s a tad above my level, sadly. Here’s the ffmpeg -i output for the video in question :
ffmpeg version N-64012-g61df081 Copyright (c) 2000-2014 the FFmpeg developers
built on Jun 16 2014 22:01:59 with gcc 4.8.3 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex--enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
libavutil 52. 89.100 / 52. 89.100
libavcodec 55. 67.100 / 55. 67.100
libavformat 55. 43.100 / 55. 43.100
libavdevice 55. 13.101 / 55. 13.101
libavfilter 4. 8.100 / 4. 8.100
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.100
Input #0, matroska,webm, from '[Coalgirls]_Spirited_Away_(1920x1038_Blu-ray_FLAC)_[92372194].mkv':
Metadata:
title : Spirited Away
encoder : libebml v1.3.0 + libmatroska v1.4.0
creation_time : 2014-07-03 01:32:13
Duration: 02:04:32.29, start: 0.000000, bitrate: 15972 kb/s
Chapter #0.0: start 0.000000, end 99.099000
Metadata:
title : 00:00:00.000
Chapter #0.1: start 99.099000, end 196.238000
Metadata:
title : 00:01:39.099
Chapter #0.2: start 196.238000, end 443.526000
Metadata:
title : 00:03:16.238
Chapter #0.3: start 443.526000, end 645.395000
Metadata:
title : 00:07:23.526
Chapter #0.4: start 645.395000, end 1023.022000
Metadata:
title : 00:10:45.395
Chapter #0.5: start 1023.022000, end 1368.534000
Metadata:
title : 00:17:03.022
Chapter #0.6: start 1368.534000, end 1716.048000
Metadata:
title : 00:22:48.534
Chapter #0.7: start 1716.048000, end 2008.173000
Metadata:
title : 00:28:36.048
Chapter #0.8: start 2008.173000, end 2301.674000
Metadata:
title : 00:33:28.173
Chapter #0.9: start 2301.674000, end 2651.816000
Metadata:
title : 00:38:21.674
Chapter #0.10: start 2651.816000, end 2906.821000
Metadata:
title : 00:44:11.816
Chapter #0.11: start 2906.821000, end 3271.351000
Metadata:
title : 00:48:26.821
Chapter #0.12: start 3271.351000, end 3729.017000
Metadata:
title : 00:54:31.351
Chapter #0.13: start 3729.017000, end 4091.587000
Metadata:
title : 01:02:09.017
Chapter #0.14: start 4091.587000, end 4476.847000
Metadata:
title : 01:08:11.587
Chapter #0.15: start 4476.847000, end 4750.579000
Metadata:
title : 01:14:36.847
Chapter #0.16: start 4750.579000, end 5139.760000
Metadata:
title : 01:19:10.579
Chapter #0.17: start 5139.760000, end 5478.890000
Metadata:
title : 01:25:39.760
Chapter #0.18: start 5478.890000, end 5853.806000
Metadata:
title : 01:31:18.890
Chapter #0.19: start 5853.806000, end 6318.937000
Metadata:
title : 01:37:33.806
Chapter #0.20: start 6318.937000, end 6625.118000
Metadata:
title : 01:45:18.937
Chapter #0.21: start 6625.118000, end 6771.098000
Metadata:
title : 01:50:25.118
Chapter #0.22: start 6771.098000, end 6914.199000
Metadata:
title : 01:52:51.098
Chapter #0.23: start 6914.199000, end 7253.580000
Metadata:
title : 01:55:14.199
Chapter #0.24: start 7253.580000, end 7472.288000
Metadata:
title : 02:00:53.580
Stream #0:0: Video: h264 (High 10), yuv420p10le(tv, bt709), 1920x1038, SAR 1:1 DAR 320:173, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
Metadata:
title : Spirited Away
Stream #0:1(jpn): Audio: flac, 48000 Hz, 6.1, s32 (default)
Metadata:
title : 6.1 FLAC
Stream #0:2(eng): Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s
Metadata:
title : 5.1 AC3
Stream #0:3(fre): Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s
Metadata:
title : 5.1 AC3
Stream #0:4(ger): Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s
Metadata:
title : 5.1 AC3
Stream #0:5(fin): Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
Metadata:
title : 2.0 AC3
Stream #0:6(kor): Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s
Metadata:
title : 5.1 AC3
Stream #0:7(chi): Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s
Metadata:
title : 5.1 AC3
Stream #0:8(chi): Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s
Metadata:
title : 5.1 AC3
Stream #0:9(eng): Subtitle: ssa (default)
Metadata:
title : English
Stream #0:10(fre): Subtitle: ssa
Metadata:
title : French
Stream #0:11(ger): Subtitle: ssa
Metadata:
title : German
Stream #0:12(eng): Subtitle: ssa
Metadata:
title : Songs + Signs
Stream #0:13: Attachment: ttf
Metadata:
filename : MyriadPro-Regular.otf
mimetype : application/x-truetype-font
Stream #0:14: Attachment: ttf
Metadata:
filename : MyriadPro-SemiboldIt.otf
mimetype : application/x-truetype-font
Stream #0:15: Attachment: ttf
Metadata:
filename : Vesta-Bold.otf
mimetype : application/x-truetype-font
Stream #0:16: Attachment: ttf
Metadata:
filename : Vesta-Bold_2.otf
mimetype : application/x-truetype-font
Stream #0:17: Attachment: ttf
Metadata:
filename : AR CENA_0.TTF
mimetype : application/x-truetype-font
Stream #0:18: Attachment: ttf
Metadata:
filename : tahomabd.ttf
mimetype : application/x-truetype-font
Stream #0:19: Attachment: ttf
Metadata:
filename : palai.ttf
mimetype : application/x-truetype-font
Stream #0:20: Attachment: ttf
Metadata:
filename : pala.ttf
mimetype : application/x-truetype-fontAs you can see, one of the streams is a FLAC 6.1 stream. I wanted to convert that to AAC, and I know how to do that, basically like this :
ffmpeg -i "input.mkv" -codec:v copy -codec:a aac -strict -2 -b:a 320k -f matroska "output.mkv"But apparently AAC doesn’t support 6.1 audio :
...
[aac @ 03b26860] Unsupported number of channels: 7
Output #0, matroska, to 'd:\Movies\[Coalgirls]_Spirited_Away_(1920x1038_Blu-ray_FLAC)_[92372194].aac.mkv':
Stream #0:0(jpn): Video: h264, yuv420p10le, 1920x1038 [SAR 1:1 DAR 320:173], q=2-31, 23.98 fps, 90k tbn, 1k tbc (default)
Stream #0:1(jpn): Audio: aac, 0 channels, 128 kb/s (default)
Metadata:
encoder : Lavc55.67.100 aac
Stream #0:2(eng): Subtitle: ssa, 128 kb/s (default)
Metadata:
encoder : Lavc55.67.100 ssa
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (flac (native) -> aac (aac))
Stream #0:9 -> #0:2 (ssa (native) -> ssa (native))
Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or heightThat’s fine, so I wanted to downmix it to 5.1 and encode as AAC. But I can’t seem to work out how to. Any advice ?
-
Reverse Engineering Italian Literature
1er juillet 2014, par Multimedia Mike — Reverse EngineeringSome time ago, Diego “Flameeyes” Pettenò tried his hand at reverse engineering a set of really old CD-ROMs containing even older Italian literature. The goal of this RE endeavor would be to extract the useful literature along with any structural metadata (chapters, etc.) and convert it to a more open format suitable for publication at, e.g., Project Gutenberg or Archive.org.
Unfortunately, the structure of the data thwarted the more simplistic analysis attempts (like inspecting for blocks of textual data). This will require deeper RE techniques. Further frustrating the effort, however, is the fact that the binaries that implement the reading program are written for the now-archaic Windows 3.1 operating system.
In pursuit of this RE goal, I recently thought of a way to glean more intelligence using DOSBox.
Prior Work
There are 6 discs in the full set (distributed along with 6 sequential issues of a print magazine named L’Espresso). Analysis of the contents of the various discs reveals that many of the files are the same on each disc. It was straightforward to identify the set of files which are unique on each disc. This set of files all end with the extension “LZn”, where n = 1..6 depending on the disc number. Further, the root directory of each disc has a file indicating the sequence number (1..6) of the CD. Obviously, these are the interesting targets.The LZ file extensions stand out to an individual skilled in the art of compression– could it be a variation of the venerable LZ compression ? That’s actually unlikely because LZ — also seen as LIZ — stands for Letteratura Italiana Zanichelli (Zanichelli’s Italian Literature).
The Unix ‘file’ command was of limited utility, unable to plausibly identify any of the files.
Progress was stalled.
Saying Hello To An Old Frenemy
I have been showing this screenshot to younger coworkers to see if any of them recognize it :
Not a single one has seen it before. Senior computer citizen status : Confirmed.
I recently watched an Ancient DOS Games video about Windows 3.1 games. This episode showed Windows 3.1 running under DOSBox. I had heard this was possible but that it took a little work to get running. I had a hunch that someone else had probably already done the hard stuff so I took to the BitTorrent networks and quickly found a download that had the goods ready to go– a directory of Windows 3.1 files that just had to be dropped into a DOSBox directory and they would be ready to run.
Aside : Running OS software procured from a BitTorrent network ? Isn’t that an insane security nightmare ? I’m not too worried since it effectively runs under a sandboxed virtual machine, courtesy of DOSBox. I suppose there’s the risk of trojan’d OS software infecting binaries that eventually leave the sandbox.
Using DOSBox Like ‘strace’
strace is a tool available on some Unix systems, including Linux, which is able to monitor the system calls that a program makes. In reverse engineering contexts, it can be useful to monitor an opaque, binary program to see the names of the files it opens and how many bytes it reads, and from which locations. I have written examples of this before (wow, almost 10 years ago to the day ; now I feel old for the second time in this post).Here’s the pitch : Make DOSBox perform as strace in order to serve as a platform for reverse engineering Windows 3.1 applications. I formed a mental model about how DOSBox operates — abstracted file system classes with methods for opening and reading files — and then jumped into the source code. Sure enough, the code was exactly as I suspected and a few strategic print statements gave me the data I was looking for.
Eventually, I even took to running DOSBox under the GNU Debugger (GDB). This hasn’t proven especially useful yet, but it has led to an absurd level of nesting :
The target application runs under Windows 3.1, which is running under DOSBox, which is running under GDB. This led to a crazy situation in which DOSBox had the mouse focus when a GDB breakpoint was triggered. At this point, DOSBox had all desktop input focus and couldn’t surrender it because it wasn’t running. I had no way to interact with the Linux desktop and had to reboot the computer. The next time, I took care to only use the keyboard to navigate the application and trigger the breakpoint and not allow DOSBox to consume the mouse focus.
New Intelligence
By instrumenting the local file class (virtual HD files) and the ISO file class (CD-ROM files), I was able to watch which programs and dynamic libraries are loaded and which data files the code cares about. I was able to narrow down the fact that the most interesting programs are called LEGGENDO.EXE (‘reading’) and LEGGENDA.EXE (‘legend’ ; this has been a great Italian lesson as well as RE puzzle). The first calls the latter, which displays this view of the data we are trying to get at :
When first run, the program takes an interest in a file called DBBIBLIO (‘database library’, I suspect) :
=== Read(’LIZ98\DBBIBLIO.LZ1’) : req 337 bytes ; read 337 bytes from pos 0x0 === Read(’LIZ98\DBBIBLIO.LZ1’) : req 337 bytes ; read 337 bytes from pos 0x151 === Read(’LIZ98\DBBIBLIO.LZ1’) : req 337 bytes ; read 337 bytes from pos 0x2A2 [...]
While we were unable to sort out all of the data files in our cursory investigation, a few things were obvious. The structure of this file looked to contain 336-byte records. Turns out I was off by 1– the records are actually 337 bytes each. The count of records read from disc is equal to the number of items shown in the UI.
Next, the program is interested in a few more files :
*** isoFile() : ’DEPOSITO\BLOKCTC.LZ1’, offset 0x27D6000, 2911488 bytes large === Read(’DEPOSITO\BLOKCTC.LZ1’) : req 96 bytes ; read 96 bytes from pos 0x0 *** isoFile() : ’DEPOSITO\BLOKCTX0.LZ1’, offset 0x2A9D000, 17152 bytes large === Read(’DEPOSITO\BLOKCTX0.LZ1’) : req 128 bytes ; read 128 bytes from pos 0x0 === Seek(’DEPOSITO\BLOKCTX0.LZ1’) : seek 384 (0x180) bytes, type 0 === Read(’DEPOSITO\BLOKCTX0.LZ1’) : req 256 bytes ; read 256 bytes from pos 0x180 === Seek(’DEPOSITO\BLOKCTC.LZ1’) : seek 1152 (0x480) bytes, type 0 === Read(’DEPOSITO\BLOKCTC.LZ1’) : req 32 bytes ; read 32 bytes from pos 0x480 === Read(’DEPOSITO\BLOKCTC.LZ1’) : req 1504 bytes ; read 1504 bytes from pos 0x4A0 [...]
Eventually, it becomes obvious that BLOKCTC has the juicy meat. There are 32-byte records followed by variable-length encoded text sections. Since there is no text to be found in these files, the text is either compressed, encrypted, or both. Some rough counting (the program seems to disable copy/paste, which thwarts more precise counting), indicates that the text size is larger than the data chunks being read from disc, so compression seems likely. Encryption isn’t out of the question (especially since the program deems it necessary to disable copy and pasting of this public domain literary data), and if it’s in use, that means the key is being read from one of these files.
Blocked On Disassembly
So I’m a bit blocked right now. I know exactly where the data lives, but it’s clear that I need to reverse engineer some binary code. The big problem is that I have no idea how to disassemble Windows 3.1 binaries. These are NE-type executable files. Disassemblers abound for MZ files (MS-DOS executables) and PE files (executables for Windows 95 and beyond). NE files get no respect. It’s difficult (but not impossible) to even find data about the format anymore, and details are incomplete. It should be noted, however, the DOSBox-as-strace method described here lends insight into how Windows 3.1 processes NE-type EXEs. You can’t get any more authoritative than that.So far, I have tried the freeware version of IDA Pro. Unfortunately, I haven’t been able to get the program to work on my Windows machine for a long time. Even if I could, I can’t find any evidence that it actually supports NE files (the free version specifically mentions MZ and PE, but does not mention NE or LE).
I found an old copy of Borland’s beloved Turbo Assembler and Debugger package. It has Turbo Debugger for Windows, both regular and 32-bit versions. Unfortunately, the normal version just hangs Windows 3.1 in DOSBox. The 32-bit Turbo Debugger loads just fine but can’t load the NE file.
I’ve also wondered if DOSBox contains any advanced features for trapping program execution and disassembling. I haven’t looked too deeply into this yet.
Future Work
NE files seem to be the executable format that time forgot. I have a crazy brainstorm about repacking NE files as MZ executables so that they could be taken apart with an MZ disassembler. But this will take some experimenting.If anyone else has any ideas about ripping open these binaries, I would appreciate hearing them.
And I guess I shouldn’t be too surprised to learn that all the literature in this corpus is already freely available and easily downloadable anyway. But you shouldn’t be too surprised if that doesn’t discourage me from trying to crack the format that’s keeping this particular copy of the data locked up.
Syndiquer tout le site
