As I understand the OP...

I think you may well be right in your interpretation of what the OP has asked for.

But the (only?) way the data could end up in that byte/word ordering, is if it is being stored as unsigned longs on a little-endian machine. In which case, it would be better to unpack it as such, and so avoid the slow, manual reordering:

printf "%0x\n", $_ for unpack 'V2', "\x45\xd2\xff\x76\x89\x3a\x00\x33"
+;;
76ffd245
33003a89

#or 

printf "%0x\n", $_ for unpack 'L<2', "\x45\xd2\xff\x76\x89\x3a\x00\x33
+";;
76ffd245
33003a89
[download]

I'm always wary of these questions when they are couched in terms of "hex" and "binary", which means different things to different people. Often either term is misused to mean ascii-fied hex data.

In this case, the impression left by the OPs code and question are, that he is a C programmer using perl and trying to do things "the C way", and is unaware of unpack.

Finally, depending upon what 'mode' his hex editor is in, it could be that the byte ordering of the raw data is being 'messed' with for display.

In much the same way as od appears to 'mess' with the ordering, depending upon how you ask it to interpret the data:

c:\test>od -t xC src.bin
0000000 45 d2 ff 76 89 3a 00 33
0000010

c:\test>od -t x2 src.bin
0000000 d245 76ff 3a89 3300
0000010

c:\test>od -t x4 src.bin
0000000 76ffd245 33003a89
0000010
[download]