![]() |
|
|
|
#1
|
|||
|
|||
|
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,
__________________
JMI |
|
#2
|
|||
|
|||
|
Thank you very much for the explanations guys (it was a very good explanation bu JMI). I tried to reply earlier, but I think an anti-spam system prevented me (It said I couldn't post again for 24hours).
taos - thanks for the tip with "getting OEP", I was previously googling for "unpacking aspack" and didn't make any ground with the tutorials I found, but adding OEP led to a nice tutorial here here. ne_viens, I dont want to just unpack the file - as then I have to give my friends the complete file, rather then just a little patch. Thank you for the example code! I have now finished the patch and all is working well, so im very happy.
|
![]() |
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Finding which packer has been used | rcer | General Discussion | 16 | 11-03-2019 01:56 |
| Finding API Address | britedream | General Discussion | 5 | 10-05-2006 21:28 |
| meaning of a p-code Registration routine | wassim_ | General Discussion | 0 | 09-29-2006 22:49 |