Original report in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776193
It also has a reproduced attached.

Original text:
unshield is vulnerable to directory traversal via "../" sequences. As a
proof of concept, unpacking the attached InstallShield archive creates a
file in /tmp:

$ ls /tmp/moo
ls: cannot access /tmp/moo: No such file or directory

$ unshield x data1.cab
Cabinet: data1.cab
 extracting: ./Bovine_Files/../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../tmp/moo
--------  -------
         1 files

$ ls /tmp/moo
/tmp/moo

I noticed that the author of the -i option followed up with a patch for the manpage, which was never applied: see https://sourceforge.net/p/synce/patches/30/ for the thread, and https://sourceforge.net/p/synce/patches/_discuss/thread/c593a57c/83f6/attachment/update_manpage.diff for the patch.

Follow up on #38

The International Patch for Baldur's Gate 1 (available e.g. from https://www.fileplanet.com/13569/10000/fileinfo/Baldur's-Gate-Patch-%28v.-1.1.4315-International%29) seems to have a strange index: Each group contains the same file in several language specific versions, however the extracted file will always be the Spanish version (probably because it is the last one in the index). This unfortunately makes it impossible to extract the file for a specific language.

Steps to reproduce:

• Unpack the archive
  7z x bgintl114315.exe
• View the file dialog.tlk in the package contents
  unshield l data1 dialog.tlk
  As can be seen all files appear multiple times.
• Extract the file in any language except Spanish
  unshield -g "English" x data1 dialog.tlk
• View the language contents of the file
  strings ./English/dialog.tlk

Appveyor allows automatically building binaries after every commit and publishing artifacts.

This has not been updated for a while:

$ unshield -V
Unshield version 1.4. Copyright (C) 2003-2013 David Eriksson.

Hi,

with autoconf, we built libunshield with SONAME 0, with the switch to cmake, it's now 1 (1.3, actually, matching the release number). Is that intentional?

Greets

Steps to reproduce:
unshield --version

Expected result:
unshield 1.4.3, MIT License, https://github.com/twogood/unshield

Actual result:

unshield: invalid option -- '-'
Syntax:

	unshield [-c COMPONENT] [-d DIRECTORY] [-D LEVEL] [-g GROUP] [-i VERSION] [-e ENCODING] [-GhlOrV] c|g|l|t|x CABFILE [FILENAME...]

Options:
	-c COMPONENT  Only list/extract this component
	-d DIRECTORY  Extract files to DIRECTORY
	-D LEVEL      Set debug log level
	                0 - No logging (default)
	                1 - Errors only
	                2 - Errors and warnings
	                3 - Errors, warnings and debug messages
	-g GROUP      Only list/extract this file group
	-h            Show this help message
	-i VERSION    Force InstallShield version number (don't autodetect)
	-e ENCODING   Convert filename character encoding to local codepage from ENCODING (implicitly sets -R)
	-j            Junk paths (do not make directories)
	-L            Make file and directory names lowercase
	-O            Use old compression
	-r            Save raw data (do not decompress)
	-R            Don't do any conversion to file and directory names when extracting.
	-V            Print copyright and version information

Commands:
	c             List components
	g             List file groups
	l             List files
	t             Test files
	x             Extract files

Other:
	CABFILE       The file to list or extract contents of
	FILENAME...   Optionally specify names of specific files to extract (wildcards are supported)

Hi - I'm attempting to unpack / deobfuscate an old InstallShield 5.0.2 file set from 1997 (ZIP available: https://ashbysoft.com/download/dpcb1197-Wireplay.zip). the _sys1.cab and _user1.cab archives unpack using the -O switch, but I have two issues with data1.cab:

1/ the cab doesn't have the data files in - they appear to be already decompressed in the current folder (their file sizes match decompressed size reported by cab listing), unshield errors with 'File is not in the cabinet'.
2/ the data files appear to be obfuscated/encrypted in some way (eg: Readme.txt), I can see unshield has some deobfuscation support but I cannot test it due to issue 1..

FWIW I am one of the original developers of the binaries I'm trying to unpack and happy to have a go at adding out-of-cabinet data file support but wanted to raise the issue here and see if there are any quick checks I can do to discover if the files are obfuscated or encrypted.

I have tried using unshield on the following cabinet set from InstallShield 15 installers with no luck.

sp71906.zip

After issue #5 was fixed, I went to Debian and Ubuntu repositories to see the version there (and perhaps request them to package the new v0.9), when I noticed they are still using 0.6 from 2009!

Not only that, their "upstream" links points to http://sourceforge.net/projects/synce/ , which looks like an unrelated project (that shares twogood as a common author). And the watch file (that looks for new releases) points to http://sourceforge.net/projects/synce/files/Unshield , which has only unshield-0.6.tar.gz from 2009-07-16.

Maybe this SynCE used to host Unshield? Well, Debian (and by proxy Ubuntu and Mint) could be requested to update their URLs to point here instead. And you could also git tag versions from 0.7 to 0.9 so they can package all the goodies you guys did since 2009 :)

Btw, congrats for the new versions!

I am not able to extract the data.cab file through unshield

data.cab
https://mega.nz/#!Dh0CQLjL!ctzP_Ijd0XfDP6N9bSxpdWP4j7oSuzCJDeKC0mi7Glg

data.hdr
https://mega.nz/#!65Nx3KaD!ctzP_Ijd0XfDP6N9bSxpdWP4j7oSuzCJDeKC0mi7Glg

could you help me extract the files ?

Hi,

unshield can't decompress 3 files from data1.cab provided by the Spanish version
of "the Feeble Files" (Charisma.smk, Qtime.smk & Run95.exe)

Without the -O flag, this archive can't be uncompressed at all.

Log for one of the 3 files:

unshield -D 3 -O x data1.cab Charisma.smk > charisma.txt 2>&1
http://ssh.detiste.be/charisma.txt

Whole CD1:
https://drive.google.com/file/d/0B6x6rDZxk-NbUkZaT28waXlaMWs/view

The (only ?) usefull inner archive:
http://ssh.detiste.be/data1.cab (26M)

Greets,

Original report in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776238

Unshield aborts while testing this (slightly corrupted) archive:

$ unshield t data1.cab
Aborted

I would expect it to print an explanatory error message and exit
normally with non-zero exit code instead.

Backtrace:
#0  0xf7fdc425 in __kernel_vsyscall ()
#1  0xf7e19307 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0xf7e1a9c3 in __GI_abort () at abort.c:89
#3  0xf7fb5794 in unshield_component_new (header=0x804dfd0, offset=646) at component.c:54
#4  0xf7fb8eff in unshield_header_get_components (header=0x804dfd0) at libunshield.c:155
#5  0xf7fb942d in unshield_read_headers (unshield=0x804dfb0, version=-1) at libunshield.c:309
#6  0xf7fb95db in unshield_open_force_version (filename=0xffffd9c2 "data1.cab", version=-1) at libunshield.c:361
#7  0x08049db1 in main (argc=3, argv=0xffffd804) at unshield.c:574

This was reported in 2004 in Debian Bug Tracking System: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260174

A working patch ready to merge was also provided (tho the syntax is not optimal, better than -f FILE for a single file (or multiple -f) is to do as tar and many other tools: all arguments (not options) after the cabinet name are filenames to be extracted.

This is a very needed feature! And it is present in virtually all extractors, like zip, 7z, rar, tar, gz, etc. Much more useful, IMHO, than -c or -g (which I honestly have no idea what they are)

This could be implemented by extracting everything, but not actually saving the extracted data, as bzip2 does

Source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=269588

How do you compile this program to use it? How do does the program function? I want to combine/extract multipart cab files. There are no written instructions on how to use this, i would appreciate if you could update the description with a tutorial.

Source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776238

#13 (comment)

The current message is Failed to open data1.cab as an InstallShield Cabinet File

I has issues compiling unshield under MinGW, the 64-bit version. I have attached the following patch of changes I had to do to make it build. It also allows overriding the use of OpenSSL with the internal MD5 code, even when OpenSSL is found.

unshield.patch.txt

I'm extracting this old Korean game. It has only one file with the filename in Korean, and that file is either extracted with gibberish as filenames, or errors out.

No options or -R results in:

extracting: ./App_Executables/custom/A_AúÄ¿½ºÅO½ºÅ²,,µå'A1y.txt

Extracting with -e results in:

Could not encode text to 'EUC-KR' error Illegal byte sequence
Failed to extract file 'A_AúÄ¿½ºÅO½ºÅ²,,µå'A1y.txt'.Run unshield again with -D 3 for more information.

I've tried EUC-KR, ISO-2022-KR, and KSC_5601. KSC_5601 didn't extract any of the files.

The correct filename is 유저커스텀스킨만드는법.txt

P.S. On a slightly unrelated note, is there a generic command to extract only the program files, skipping the IS internal files? As far as I understand the group(s) containing the program files vary between IS versions (or every single program).

I have tried using unshield on the following cabinet set from InstallShield 21 installers with no luck.

sp72968.zip

I'm having an issue with ready cabinets when a path I give unshield contains numbers. I image this may take few changes to fix, and the workaround is just to be in the folder where the cabinet is, but I figured I should make you aware of the issue.

unshield -D 3 l sp71906\data1.cab
[unshield_fopen_for_reading:60] File sp1.hdr not found even case insensitive

[unshield_read_headers:232] Could not open .hdr file 1. Reading header from .cab file 1 instead.
[unshield_fopen_for_reading:60] File sp1.cab not found even case insensitive

[unshield_open_force_version:363] Failed to read header files
Failed to open sp71906\data1.cab as an InstallShield Cabinet File

aef

Would be nice to pulish binaries as a release asset. I can't compile this on my pc, and I think most people hae the same situation (most people are not application developers).

Since it says the build passes, something must have been built ;)
Not sure if that means Linux/macOS/Windows, but those are the ones people likely want.

Shouldn't be too hard to provide these? You gotta build them anyway in order to test if the program still builds at least...

I'm trying to build/test unshield on Alpine Linux (with musl libc), and all of the bundled tests fail. I've included the output from running the following manually (as found in the baldur gate test sh script):

./build/src/unshield -D 3 -d extract1 x data1.cab

Output:

unshield_fail.log

When trying to extract a cab file using a too long custom output path, the program crashes because of a buffer overflow. A contrived example call is:
unshield -d $(python -c "print 'A'*300") x ./abc/_SYS1.CAB

The line in question is here:
https://github.com/twogood/unshield/blob/master/src/unshield.c#L388
where char dirname[256]; is fixed-length, but output_directory's length is (unbound) variable, coming directly from the argument.

To fix this, I suggest using strncpy or checking that the output_directory doesn't exceed some length.

Below is the output it gives me:

Cabinet: ./abc/_SYS1.CAB
*** buffer overflow detected ***: unshield terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fb29fea97e5]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fb29ff4a56c]
/lib/x86_64-linux-gnu/libc.so.6(+0x116570)[0x7fb29ff48570]
/lib/x86_64-linux-gnu/libc.so.6(+0x1158c2)[0x7fb29ff478c2]
unshield[0x4019d9]
unshield[0x40219d]
unshield[0x401f26]
unshield[0x401693]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fb29fe52830]
unshield[0x4017b0]
======= Memory map: ========
[...]

We bought a machine from China and it came with software. I tried installing the software but it couldn't finish setting up so I did some troubleshooting and found that there was a file labelled data2.cab which was failing to extract and I suspect its the one prohibiting the software to install.

Running on SheevaPlug, unshield simply 'Aborts' when I try to extract a cab.

The problem lies with macros READ_UINT16 & READ_UINT32 in lib/internal.h.
In a nutshell, some processors will not tolerate a pointer that is not correctly aligned for the 'pointed to' type. This arm is one of those.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html

Unfortunately, the layout of the CAB/HDR files seems to take no interest in the memory alignment of its content, so successful execution is highly improbable. With these macros the correct values will only be read about 1 in 4 times. Failure is guaranteed.

I've replaced the existing definitions with the following. It now works on my SheevaPlug, and I see no reason why it should not work on any other cpu, but I haven't tested.

/*
  Access unaligned little endian data retrieved from CAB/HDR files.
  Pointers to buffered data are declared as pointers to uint8_t.

  Some processors (e.g. ARM types) will not tolerate a pointer that
  is not correctly aligned for the pointed to type.

  Other processors (e.g. Intel) don't care about these. So this
  approach is suboptimal for them. Could be optimized if it matters.

  Adapted from kernel source: include/linux/unaligned/le_byteshift.h
*/

static inline uint16_t get_unaligned_le16(const uint8_t *p)
{
    return p[0] | p[1] << 8;
}

static inline uint32_t get_unaligned_le32(const uint8_t *p)
{
    return p[0] | p[1] << 8 | p[2] << 16 | p[3] << 24;
}

#define READ_UINT16(p)   get_unaligned_le16(p)
#define READ_UINT32(p)   get_unaligned_le32(p)

Hope this helps. Thanks for making the tool available.

Hey,

it seems that the code we embed in lib/convert_utf/ConvertUTF.c is not really free software.

Here is an explanation of the issue in ghostscript:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823100
https://bugs.ghostscript.com/show_bug.cgi?id=697121

the fix for ghostscript is here:
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=273a133110838ee5702e7eb6409a853c598211b2
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=727aeab76c39026722e3e492a30ae2f7c218c1ec

I'm getting trouble extracting a cabinet.

Version from header is 16:

[unshield_read_headers:226] Reading header from .hdr file 1.
[unshield_read_headers:303] Version 0x02000640 handled as major version 16
[unshield_get_cab_descriptor:81] Cabinet descriptor: 000d192a 002026f0 002026f0 00000168
[unshield_get_cab_descriptor:83] Directory count: 90
[unshield_get_cab_descriptor:84] File count: 20901

There are 20901 files.

Searching inside the setup.exe:

$ strings /mnt/1/setup.exe | grep -i shield
http://www.installshield.com/isetup/ProErrorCentral.asp?ErrorCode=%d : 0x%x&ErrorInfo=%s
InstallShieldPendingOperation
SOFTWARE\InstallShield\16.0\Professional
    name="InstallShield.Setup"
<description>InstallShield.Setup</description>

At lib/component.c on line 53, using gdb, self->file_group_count is 151, exceeding the MAX_FILE_GROUP_COUNT limit set as 71 in lib/cabfile.h at line 16.

52 self->file_group_count = READ_UINT16(p); p += 2;
53 if (self->file_group_count > MAX_FILE_GROUP_COUNT)
54     abort();

As seen in i6comp at line 34, the max file groups is 512.

33 #define CSFG_MAX 512
34 #define CSCP_MAX 512

Changing the MAX_FILE_GROUP_COUNT to 512 produces a segmentation fault:

0x00007ffff7bd59eb in get_unaligned_le32 (p=0x7ffffcd1eb10 <error: Cannot access memory at address 0x7ffffcd1eb10>) at ~/unshield/lib/internal.h:138
 138        return p[0] | p[1] << 8 | p[2] << 16 | p[3] << 24;
(gdb) bt
#0  0x00007ffff7bd59eb in get_unaligned_le32 (p=0x7ffffcd1eb10 <error: Cannot access memory at address 0x7ffffcd1eb10>) at ~/unshield/lib/internal.h:138
#1  0x00007ffff7bd605a in unshield_header_get_components (header=0x55555575a030) at ~/unshield/lib/libunshield.c:145
#2  0x00007ffff7bd66f6 in unshield_read_headers (unshield=0x555555759ff0, version=0xffffffff) at ~/unshield/lib/libunshield.c:317
#3  0x00007ffff7bd68e2 in unshield_open_force_version (filename=0x7fffffffe4a3 "/mnt/1/data1.cab", version=0xffffffff) at ~/unshield/lib/libunshield.c:369
#4  0x000055555555690c in main (argc=0x5, argv=0x7fffffffe138) at ~/unshield/src/unshield.c:578

However using the following "patch" on lib/component.c, allows to continue on big file_group_count, with the original MAX_FILE_GROUP_COUNT set at 71:

52   self->file_group_count = READ_UINT16(p); p += 2;
53   if (self->file_group_count > MAX_FILE_GROUP_COUNT)
54       printf("WARNING: self->file_group_count = %d\n", self->file_group_count);
55       if(self->file_group_count > 512) 
56           abort()

This patch allows me to extract the cabinet without error, but obviously I have no idea of why.

Using valgrind to check buffer overflow (count bigger than MAX), shows no errors:

$ valgrind src/unshield -d test x /mnt/1/data1.cab
...
          19911 files
==9926== 
==9926== HEAP SUMMARY:
==9926==     in use at exit: 0 bytes in 0 blocks
==9926==   total heap usage: 436,953 allocs, 436,953 frees, 8,169,910,049 bytes allocated
==9926== 
==9926== All heap blocks were freed -- no leaks are possible
==9926== 
==9926== For counts of detected and suppressed errors, rerun with: -v
==9926== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

And the number of files is the same as extracted, but not equal to the number of files in the header 20901:

$ find test/ -type f  | wc -l
19911

Cabinets are large, in total ~1GB. Any ideas?

Now, I'm assuming it's InstallShield 17 based on the version of ISSetup.dll. ISCAB just says "Fatal Error", and unshield says a lot of stuff, but I couldn't really figure out how to redirect the output. The problem is all groups get extracted (or so it seems) except for the group/component containing the actual program files.
This is a commercial program of ~7GB total, so I can't upload it. I can, however upload data1.hdr and data1.cab (~20MB), if that will help, however the actual files that fail to extract are in data2.cab.

I am trying to extract files from this file
http://tkool.jp/assets/files/2003rtp.zip

command I use :

unar -encoding SHIFT-JIS 2003rtp.zip
cd "2003RTPｾｯﾄｱｯﾌﾟ"
unar RPG2003RTP.exe
cd RPG2003RTP
unshield x data1.cab

However, unshield cannot set the original character encoding like unarchiver, all non-ascii characters are converted to underline (In this case these characters are encoded in shift-jis).
Any way to solve the problem?

I know I didn'd keep an eye on this for a while, but I still use Unshield daily. Currently Unshield doesn't preserve the timestamp of the extracted files, but it's preserved in all (some?) versions of cab archives.

There are several commits since version 1.0, so please make new release.

I have some stock invester pro installshield exe, use exiftool I can see that they are created using various versions of installshield , before version 12 unshield work perfectly, but after version 17 till 19, unshield list file in a strange way, only one character for each part in the path/filename,
Imgur

any known issues for this? thanks

I contacted David directly about a couple of files I found that were identified as InstallShield cabs, but which unshield couldn't open. He asked me to file an issue, so here it is.

Download the .exe from http://www.dell.com/support/drivers/us/en/04/DriverDetails/Product/dell-venue-8-pro?driverId=4F5N3&osCode=WB32A&fileId=3298803898&languageCode=en&categoryId=NI , extract it (it's a typical self-extracting .exe) and see the files data1.cab and data2.cab . They're pretty clearly InstallShield files, but unshield doesn't open them.

Using retail C&C Generals and unshield f097b07 (current master), I tried extracting assets for use in https://github.com/TheAssemblyArmada/Thyme, but unshield complains:
Failed to open Data1.cab as an InstallShield Cabinet File

This is surely an InstallShield installer:

$ strings setup.exe | grep -ic installshield
39

The Data1.cab file identifies itself as:

00000000  4d 53 43 46 00 00 00 00  49 84 3c 0a 00 00 00 00  |MSCF....I.<.....|

Any idea what could be the problem?

cabextract and unshield have useful warnings when you attempt to unpack each other's files with them. However, both have URLs that are out of date.

unshield_warning("Found Microsoft Cabinet header. Use cabextract (http://www.kyz.uklinux.net/cabextract.php) to unpack this file.");

  sys->message(fh, "WARNING; found InstallShield header. "
               "This is probably an InstallShield file. "
               "Use UNSHIELD from www.synce.org to unpack it.");

The URL for cabextract should be https://www.cabexract.org.uk/ - what should the URL for unshield be?

From the original post: "currently, I achieve this by extracting into a temporary directory and running diff over them".

Source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=269588

The file unshield_config.h isn't made available to source files when building in a build jail.

Steps to reproduce:

git clone git://github.com/twogood/unshield.git
cd unshield
mkdir -p __build_jail__
cd __build_jail__
cmake ..
make

Error message:

Scanning dependencies of target convert_utf
[  9%] Building C object lib/convert_utf/CMakeFiles/convert_utf.dir/ConvertUTF.c.o
Linking C static library libconvert_utf.a
[  9%] Built target convert_utf
Scanning dependencies of target libunshield
[ 18%] Building C object lib/CMakeFiles/libunshield.dir/bswap.c.o
In file included from /tmp/git/unshield/lib/bswap.c:2:0:
/tmp/git/unshield/lib/internal.h:6:29: fatal error: unshield_config.h: No such file or directory
 #include "unshield_config.h"
                             ^
compilation terminated.
make[2]: *** [lib/CMakeFiles/libunshield.dir/bswap.c.o] Error 1
make[1]: *** [lib/CMakeFiles/libunshield.dir/all] Error 2
make: *** [all] Error 2

Hi,
I was just adding the unshield package to my Overlay - since the in-tree (Gentoo) ebuilds are very out-dated.

I'm still carrying this small patch for the live (git) ebuild:
diff -u1 -rN a/CMakeLists.txt b/CMakeLists.txt --- a/CMakeLists.txt 2016-02-24 08:35:02.521305407 +0000 +++ b/CMakeLists.txt 2016-02-24 08:48:59.499423674 +0000 @@ -62,2 +62,3 @@ include_directories(${CMAKE_CURRENT_BINARY_DIR}) +include_directories(${CMAKE_CURRENT_BINARY_DIR}/lib)

It would be nice if I wasn't :-)

Source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776239

Original report in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776239

Unshield crashes on this (slightly corrupted) archive:

$ unshield t data1.cab
Segmentation fault

GDB says it's an out-of-bounds read:

#0  0xf7fb565a in get_unaligned_le32 (p=0x5f40e4e8 <error: Cannot access memory at address 0x5f40e4e8>) at internal.h:138
#1  0xf7fb5732 in unshield_component_new (header=0x804dfd0, offset=1463549952) at component.c:30
#2  0xf7fb8eff in unshield_header_get_components (header=0x804dfd0) at libunshield.c:155
#3  0xf7fb942d in unshield_read_headers (unshield=0x804dfb0, version=-1) at libunshield.c:309
#4  0xf7fb95db in unshield_open_force_version (filename=0xffffda22 "data1.cab", version=-1) at libunshield.c:361
#5  0x08049db1 in main (argc=3, argv=0xffffd864) at unshield.c:574

Hi, How to install this library on linux. please write build instruction.

$ ./rebuild.sh 
+ export CFLAGS=-Wall -Werror -ggdb3
+ cmake -DCMAKE_INSTALL_PREFIX:PATH=/var/tmp/unshield .
-- OPENSSL_FOUND: TRUE
-- USE_OUR_OWN_MD5: ON
-- BUILD_STATIC: OFF
-- Configuring done

If we have OpenSSL, don't use our own MD5 code.

If one wants to have play around with TinyCC one has to stop the search for a C++ compiler.

It seems that this could be achieved with a minimal change in 'CMakeLists.txt' by specifying the language explicitly:
project(unshield C)
An alternative to changing this line would be to add instead:
enable_language(C)
Both of these option have been tested successfully.

[ source: https://cmake.org/pipermail/cmake/2010-August/039239.html ]

When trying to extract cab files from Texas Instruments Avigo Manager, extraction goes into infinite loop.

unshield -D3 x data5.cab results in this:
http://pastie.org/pastes/10830939/text?key=9gocgtm2mhruuhy0ngiq

Same thing for all the cab files in the zip.

Here is a direct link to the file in question: https://www.ti.com/organizers/avigo/docs/avigomanager11b22.zip