In most cases the target will not contain any shell SDK calls or have many VMed code which do require a running shell, so that's all it takes to unpack the target.
Talking about import protections, if you find it difficult to understand, I suggest that you pick ONE specific program like calc.exe or notepad.exe and try to protect it.
Soon you will figure out that there is not many ways to do that, you can:
1. Use random locations for each function address
2. Replace call [iAT] instructions and retrieve API during runtime
And that pretty much covers every different methods you can see in many protectors.
For #1, if you found it hard or inefficient to scan entire code section and locate all those locations, you should analyze the shell code and find the part that retrieves & fills API addresses. Make a log or something like what I did in my previous IAT fix scripts.
For #2, you will need to scan the code section and identify these calls, then make a run trace to each of them, discover their corresponding API addresses. This is most likely what you will see in SE scripts.
You may ask, is it really that simple like ... Yes! Keep in mind that any additional code adding to a simple call [iAT] will have significant performance impact on the program, so there cannot be many tricks, even the code must be simple. For case #1, the address filling process can loop many thousand times, for case #2, think of a typical message loop. So you won't see any heavy VM there, have a cup of tea and find proper ways to handle them.
Why is unpacking all about IAT fixing? Because IAT is the only thing a protector can do with "blind" targets. Unless you are dealing with a protector designed for the sole purpose of protecting that one single program, or it can't just randomly pick some places and insert extra code there. Some protectors feature resource anti dump and stuff, but that either depends on API hooking or resource tree manipulation. Considering there is usually not many resources in UnpackMEs, you can always find & dump them manually.