ok, in our typical pe file we might have the following sections:

TEXT
DATA
.idata
.rdata
.reloc
.rsrc
.tls

So far I am only encrypting TEXT and DATA in my packer. Clearly .idata can't be touched as it contains the imports, how about the other 4?

Will the PE loader might the resources being crypted? what about relocations, if we are going to load at default address.

and wtf is rdata for?

The more i can encrypt the better the packer will be. e.g. hxdef is detected when encrypting TEXT+DATA, but undetected when i crypt all sections (at which point it is clearly useless).

Any info you guys can provide is much appreciated.

well with my limited knowledge the simple answer would be:
without writing your own loader you can crypt everything the pe loader does not need.
.idata contains the imports, we cannot crypt it.
.edata contains the exports, we cannot crypt it. (I guess you ment edata not rdata)
.rsrc contains the resource directory structure and should be cryptable.
.reloc contains the base relocations if we crypt it and the mapped adress is not right the loader cannot fix it and exe will crash.

oh and btw. different compilers name sections different.
.text is .icode or something when using borlan c++.

some additions from me:
.rdata is usually the same as .idata. Some programs use only one of them, some others use them both.
instead of crypting .idata and .rdata, you can crypt the code section and delete the import table, use GetProcAddress and LoadLibrary to write everything to the FirstThunk pointers mentioned on the import table, and crypt the imported function list. Then it can be restored when unpacking the program.
And normally, the name of these sections aren't important at all. You can call any section as whatever you want, the location of the import table, export table etc. is in the PE header, so you can merge everything in just one section.

from the perspective of AV detection the import table is irrelevent. it cannot be used for creating a signature, hence i am not interested in recreating it myself.

i have done some more coding / testing and found that once TEXT, DATA and rsrc are encrypted, Mcafee cannot recognise the trojan any more.

My only bits of work left are:

a. use a detour on original entry point to avoid needing to put entry point in unusual place (causes the win32 new detection)

b. put in place proper encryption

c. make stub polymorphic

Is anyone aware of AV detecting a jmp at the entrypoint as being bad?

does anyone know why hxdef fails to be loaded by the pe loader once the resources are encrypted? this works fine on some other apps i tried, but not hxdef.

m8 give me a email see if i can help!

Well it depends, an AV is able to trace through code, obviously if its jumping to what is deemed malicious code then it can detect it. But just having a jmp at the entrypoint is not "bad".

I am sure that it matters, but I can't say now which AV sees it.. I think Bitdefender...
If you change OEP to JMP, it will say Explorer Hijack or something..

oh i forgot about this thread.

yes it is bad, and i got around it with a creative detour at the original EP.