I've got a 16-bit DOS-based program that's been packed with an unknown packer. The file is an EXE at about 5kb. I've noticed that the filename is copied into the file itself at position 0x200, prefixed by the letters "bm". The strings used inside the program are easily readable, and I've noticed the string "Packed file is corrupt" near the end of the file.

The header of the file is as follows (starting from the "MZ" header signature) : (all hex) 4D 5A D6 01 0A 00 00 00 20 00 5C 01 FF FF 1A 02 80 00 00 00 10 00 FD 00 1E 00 00 00 01 and the rest of the bytes are 0x00 upto 0x1FF.

From the information - does anyone have any idea to packer used? There are some other files in the same directory that are protected with CopyControl and compressed in the same way, so I'm wondering if this is some kind of shell around the program. However, this particular compressed file doesn't care whether or not the protection exists or is valid.

It seems that, from various strings in the executable, that the original compiler was Borland C 4.5 (It requires BRUN45.EXE to run)

I've tried to run CCLOOK on the programs, but it just returns no results, saying there's no copycontrolled programs on the disk. The program itself has a copyright of 2002. It can not be downloaded from the net, only bought via mail order.

Hi Squidge

Anything DOS packer related I usually head over to Exelist at
http://groups.yahoo.com/group/exelist/messages/

There's a couple of things from there you might want to check out

ROSE SWE UnPaCKER PaCKaGE by Ralph Roth
http://come.to/rose_swe

and the Typ 2002 file recognition/ archive lister/ compiler detection proggy typ_d32.arj
http://www-user.tu-cottbus.de/~kannegv/programm/typ_d32.arj
or
http://www-user.tu-cottbus.de/~kannegv/programm/index_e.htm


I haven't had occasion to use either one of them but they might be able to detect the packer/wrapper, if not, someone on that forum might be able to help.

Kayaker

Hello squidge !

The EXE is not packed. It was only linked with LINK /EXEPACK, so the relocations are stripped off the EXE and are "compressed" at the end of the EXE to save disc space. When you run the file it relocates itself.

The signature "bmFILENAME" is not used in C programs. BRUN45.EXE is the "Quick Basic/DOS" runtime library, so it's no C program but a BASIC program.

If you had a CopyControl protected DOS EXE, you would have seen it with CCLOOK.

The "MZ"-header of a DOS EXE is the same as the "MZ"-header of a PE file (expect value at 3Ch) and uninteresting to indentify a packer.

There can be a fine line in some cases with compression vs packing. I have never really seen any formal definitions. Compression is a form of protection. Cracking groups hate it also because they generally cannot release a patch but instead must release the whole exe patched which is a lot larger . Unless they can code specific unpacker logic into the crack program. Since you have a DOS Basic program(boy do I remember the good old days of BASIC PDS 7.1) I recommend checking out this site made by DoDi the maker of the vb decompilers.: http://members.aol.com/vbdis/ He decided to start working on older basic. However I havent seen a formal decompiler yet but it is possible and actually should not be that difficult. Should be easier than VB. Basic compiler can compile with a dependency the runtime or it can link the runtime in staticly but either way it is interpreted code not native.

Snatch

Thanks for the replies, I think therefore the best approach would be to try and track down a version of Quick Basic and the compiler and see if I can (manually or by writing a program) decompile any of the programs. I may then be able to release my own decompiler.

Looking at the code again with IDA, it certainly seems like an executable stub, followed by a lot of unknown data, which I assume would be the tokenised code to interpret.

Sounds like BASIC. Visual Basic actually is very quick cut it simply pushes the main program structure on the stack and calls ThunRTMain of the VB Virtual Machine which then takes care of the rest of the loading. But in old BASIC its got to do a lot more work like loading the dependency file or if its staticly linked then the loading code is all in the program. It is not even in the same ballpark as VB decompilation though and frankly I dont see why there hasnt been a decompiler for it yet. Take a look at that web page he has a useful utility on there. Of course you may need to translate the German but thats what babelfish is for .

Snatch

Hello Snatch !

The program is not packed nor compressed. I put "compressed" in double-quotes to show that it is really not like that.

The relocation "compression" works after a simple idea.
What takes less space?

?? DWords
1 DWord followed by ?? Words

I think the answer is clear.
(assuming you have more than 1 relocation)

I managed to find QuickBasic, and the compiler and help files, and it seems EXEPACK does more than simple compression of the relocation part. According to the documentation, it also does Microsoft's most famous compression - RLE, compressing runs of the same byte. This certainly seems to hold true as I've managed to decompress the file and put the reloc info back in it and there's a lot more nulls now than there was before. The program still runs as a bonus too

Now that the first program is in a state to be decompiled, I turned my attention to the second and last. This seems to be the same compression, but with some kind of encryption applied over the top. There's no "bm<Filename>" at address 0x200, although I have figured out that If I take the bytes at 0x200, and then XOR them each by 0xD5, the result is "bl<Filename>". Considering that the code at the program entry point is completely different than normal, I'm assuming this is some kind of wrapper than an manual attempt at disguising the program.

So now this is becoming more of a challenge - I've got to strip the encryption from the program before I can decompress and reloc it, and get it ready for decompilation.

If any wants to have a look at the program, I'll happily email it to them (It's 54.9Kb).

Ok, I got a version of CopyControl from MicroCosm and played with it for a while. It seems the encryption on the second file is actually the copycontrol shell. It seemed like nothing more than simple XOR encryption by 0xD5. Wrote a little C program to decrypt it, and now it's decrypted, decompressed and ready to be decompiled like the first file. Cool thing is, it still works and no longer depends on the token being on the HD in order to function

No idea why CCLOOK didn't find it, unless I was using an out of date version (3.03 - last version you can download without a user/pass combo).

Thanks for the help people - and if anyone wants to help me on the quest of designing a QuickBasic decompiler, let me know. I have seen them for download, but the authors wanted £500 upwards before they would send them

That is a clever way to compress relocations never thought of that .

As far as your compression goes why not try something like TEU it is very good at unpacking. If at that point its not unpacked then maybe the strings are encrypted within the program as in youve unpacked it as much as you can. I remember trying to crack old Sierra games. I gave up every time. They had an interpreter and data files. The data files contained the entire game but unfortunately I had no way of reading or changing them. And reversing their entire interpreter would have been a lot of work. That protection was truly brilliant though. And it made it easier for them to code the game too. Too bad when Sierras games went to Windows they couldnt keep that up. Look at Half-Life theres more crazy patches and things for it then most games . Though most of those are hooks on OpenGL since its pretty open to exploitation.

Snatch