I think your being bitten by Unicode conversion. You could try using :raw on the open

open FILE, '>output.dat:raw' or die $!;
[download]

or using binmode on FILE before writing to it.

i'm never sure about binmode, never had to use it. same with utf8, but that's where your problem lies. go check out perldoc perldelta and see what it says about utf8

$ perl -e '$f="\xff\x01\x67";print $f' | od -t x1
0000000 ff 01 67
0000003

$ perl -e '$f="\xff\x01\x67";use Encode; $f=encode("utf8", decode("iso
+-8859-1",$f));print $f' | od -t x1
0000000 c3 bf 01 67
0000004
[download]

binmode FILE

solved my problem... thanks for the help, everyone. It was indeed that nasty business with the utf8/RedHat 9/Perl 5.8.0

use strict;
use warnings;

open FILE, ">output.dat";
my $data = "\xff\x01\x67";
print FILE unpack("H*",$data);
close FILE;
[download]

Update: Gulp... woops, you said you're using a hex editor, which presumably "unpacks" it to the stringified hex representation for you. Perhaps the problem is that you're saving it little-endian and reading it big-endian, or vice versa, in which case pack and unpack will still be helpful for converting back and forth.

UPDATE2: I was unable to replicate the problem you describe with the following code snippet:

use strict;
use warnings;

open FO, ">test.out";
my $data = "\xff\x01\x67";
print FO $data,"\n";
close FO;

open FI, "<test.out";
while ( <FI> ) {
    chomp;
    print unpack("H*",$_), "\n";
}
close FI;
[download]

       For example, if you had "en_US.UTF-8" as your locale, your
       STDIN and STDOUT were automatically "UTF-8", in other
       words an implicit binmode(..., ":utf8") was made.  This
       meant that trying to print, say, chr(0xff), ended up
       printing the bytes 0xc3 0xbf.  Hardly what you had in mind
       unless you were aware of this feature of Perl 5.8.0.  The
       problem is that the vast majority of people weren't: for
       example in RedHat releases 8 and 9 the default locale set-
       ting is UTF-8, so all RedHat users got UTF-8 filehandles,
       whether they wanted it or not.  The pain was intensified
       by the Unicode implementation of Perl 5.8.0 (still) having
       nasty bugs, especially related to the use of s/// and
       tr///.  (Bugs that have been fixed in 5.8.1)

       Therefore a decision was made to backtrack the feature and
       change it from implicit silent default to explicit con-
       scious option.  The new Perl command line option "-C" and
       its counterpart environment variable PERL_UNICODE can now
       be used to control how Perl and Unicode interact at inter-
       faces like I/O and for example the command line arguments.
       See "-C" in perlrun and "PERL_UNICODE" in perlrun for more
       information.
[download]

Abigail