I was wondering why some packers refuse to repack files that have already been packed using another program.

Is it just because there is no expected benefit from packing a file twice, and so they just refuse? I guess this makes sense for dedicated compressors like UPX, since it probably wouldn't be able to compress a file further.

What part of an exe could be modified that would prevent another packer from scrambling/encrypting the code again?

This is a good question, but I think the answer is different from what you think. I'd bet that most packers don't check to see if the file is already packed, they check for the file to be "normal". And most packed file aren't really normal, as the unpack code has become the loader of sorts for the executable, and it has to process the relocations, the imports, etc. I think that when the new packer gets a look at what the old packer has done, it bails out.

Now, as for what it sees that prevents it from packing again, that sounds like a science experiment for you!

(Back in the DOS days, this didn't exist. I used to pack stuff several times, and even convert it from .com to .exe, and back along the way).

Thanks a lot for the explanation. I certainly intend to investigate this further.

Interesting question. Just as a general reference this might be useful

Win32 Portable Executable Packing Uncovered

http://securitylabs.websense.com/content/Assets/HistoryofPackingTechnology.pdf

That paper was great, thanks for the link.

I also found "the official" Microsoft PE specification (converted it to PDF and attached for reference) but at 70 pages it was a little disappointing - not the bible I was hoping for.

I don't suppose you happen to know of any similar articles that go into greater detail, describing how relocations are handled, the effects of DEP .etc ?