My end goal is to make changes to the file and then upload it back to the tools so that all 65+ tools do not have to be manualy updated.

If your goal is specifically to change the user name and/or password for one or more records, where the existing username and password are already known before you read the file, then you have a reasonable chance of success -- so long as you follow the advice in the 2nd reply above -- because it looks like those are fixed-width fields.

Even if you don't have a clear idea of where the record boundaries are, the fact that a known username and password can be found at a specific distance from each other in the input data makes it pretty simple to splice in a new username and/or password -- unless (as suggested in the first reply) this change needs to be incorporated into some sort of checksum value elsewhere in the record.

If some simple experiments with valid tools (to apply edits that create valid/usable versions of the file) show that you can just change the username and password without further ado, you could slurp the whole file into a scalar, and apply s/// based on the known old and new username/password:

# assuming INFILE and OUTFILE are already open,
# and string variables are already set...

my $match =
    $old_username . "\x00"x(84-length($old_username)) .
    $old_password . "\x00"x(84-length($old_password));

my $replace =
    $new_username . "\x00"x(84-length($new_username)) .
    $new_password . "\x00"x(84-length($new_password));

$/ = undef;
my $filedata = <INFILE>;
$filedata =~ s/$match/$replace/;

print OUTFILE $filedata;
[download]

(updated to use the correct field width (84); actually, the password field width might be different -- no way to tell for sure, but 84 is probably a safe bet).

If you're trying to change something else in the data besides user name and/or password, well, so far there just isn't enough information available to handle that. You need to get real documentation about the file format to build your own editor for it.