Haha.. Wow, okay, I think some of us got things confused somewhere along the thread here. I think britedream did first (no offence ), then I did, and it was only Wurstgote who had things straight the whole time .

After rereading the thread, and redumping the app, I believe britedream's misunderstanding came from the comment on the instruction at 578911: ;<&kernel32.GetModuleHandleA>

I think britedream thought that [40781E] pointed directly to kernel32.GetModuleHandleA, which is at 77E7AD86, and so his suggestion was to make the instruction MOV EAX, 62A43C so that EAX would contain the same value in the dumped exe as in the original packed exe (since in the original packed exe, [40781E] pointed to 62A43C).

But, britedream my friend, [40781E] does indeed still point to 62A43C. 62A43C used to be a thunk to ASPR's emulated GetModuleHandleA function. But, 62A43C is now (after rebuilding the imports) a thunk jumping to GetModuleHandleA, thus Olly's offending (though not erroneous, as "&" was referring to a jump to the address of (as & is used in C) GetModuleHandleA) comment. So as Worstgote said,
Worstgote, in this, you are absolutely correct!

As to my own confusion, I can only attribute it to tiredness and maybe too much alcohol . Meaning, I have no real excuse... What I had been alluding to in my post about my laziness was that if changing the value in EAX really had fixed things, it would have been a cleaner solution (in my opinion) than NOPping those two instructions.

That all having been said, I believe my solution to NOP the instructions at 578919 and 57891E is still the best solution to this particular problem.

Also, Worstgote, your analysis of the code looks to me to be 100% correct. But, you already knew it was.

So, have you managed to find a resource editor yet? Also, why not install Visual Studio? Or, why do you not already have it installed? Your understanding and general knowledge of these subjects so far made me think you were already a programmer?

Regards,
Satyric0n