I would also suggest that you need to understand just what the heck an "unpacking" process does and I mean on an assembly language level, since this is the form in which you are most likely going to see it in a debugger. First consider it conceptually. Something with a certain size, whether it is the entire program, exe, dll, whatever, has been "packed." So, in this process of analysis, we know that "size does matter."
Now, as a general concept, packed code (or, for that matter, crypted code)will not run. So, some part of the code
has to run to "unpack" the "packed" parts. Now to be effective, it simply
has to know "how much" to apply it's unpacking routine to, or it will start doing "something" with parts of the code which was not originally "packed" and
that part will now not work.
So, again, conceptually, the "unpacking routine" is going to take a chunk of code of a certain size and work its magic on that chunk and now you have code that
will run.
So this suggests that there has to be, somewhere, something which tells the "unpacking routine" how many times it is supposed to work its magic before it
has to stop or wreck the rest of the program. So now there is something you have to find which has the "count" of how many times the routine needs to "cycle" through its steps before it is done.
This suggests that you are looking for a routine which takes a portion of the code located somewhere else in the program and "adds something to it" or does "some other mechanical" process to the "packed" code so that it has returned to its "original" form. Having worked its magic on a particular chunk of the packed code it needs to know whether it has "finished" its job. So you can assume that there has to be some form of a "compare" near the end of the routine, where it checks to see if it is "done" yet. This could take several forms, such as subtracting from a starting number and branching when "0" is reached, or maybe comparing to an "ending" address in the code where it knows it is done. The point being you will see that the code is going to "return" or "branch" or "jump" back to the "unpacking" part
until it has reached whatever point that is and
then it will go somewhere else, like maybe to the original OEP.
And just to keep things interesting, maybe
before it jumps off to the OEP, it might actually "erase" the "unpacking code" so that if some evil cracker dumps the running program, the "unpacking code" isn't there to be seen.
Regards,