Ok, I have read serveral of the post on the board about unpacking armadillo and they have helped a lot, but I still haven't been able to unpack my target successfully.
What I have done so far:

1. I ran armkiller on my target, and found the eip.bin file containing the oep, which I verified using windasm on my dump.

2. Then I used imprec on it to repair the iat. First it says the imported functions are ok, but when I build it the file doesn't run. So Then I increase the size of the iat, and some of the functions show up as invalid, but I can't seem to repair them because when I run auto trace the program crashes.

I am running winxp, I don't know if this helps or not, but please give me some advice on how I can fix the iat!

Hello sobdk !

Are you sure you rebuilt the right IAT?

I think you rebuilt Armadillo's IAT instead of the applications IAT which is wrapped by Armadillo. The other possibility would be that you didn't start at the IAT, but started rebuilding somewhere in the IAT and maybe left out the imports of some DLLs.

Why does everybody want to unpack DVD Region Free? This is not the first question about it and the people don't understand that they don't have a full working copy if the IAT and the OEP is rebuilt. Then you are only at the place where manual cracking starts.

It's useless to launch "trace" function for IAT rebuilding with Imprec : arm will manage to make imprec find wrong API calls !

Don't know wether newest versions of armkiller rebuild IAT or not... but I've found that the best way is to trace arm when it modifies the API pointers BEFORE launching the target : in this process (same proc is called for each api), you'll find somewhere in memory an array with the original api names... print it, so you can than check the apis imprec has rebuilt, and eventually correct them

Thanks for your help, I just want to make sure I understand what you are saying. I am a newbie when it comes to cracking, and haven't come across a program that has been packed before.

BenJ, are you saying that after I use armkill on my target there isn't a way to rebuild the iat automatically? If so, you mention a way to manually rebuild it. Could you be a little more specific? I understand what a iat does, but I don't know how to find the list of api's you mention in the memory, and I don't know what program to use to rebuild the iat after I have found the api's. I guess I am not sure how you would tell which api goes where either.

Sorry I have so many questions, I would like to learn, if you know a good tutorial about this please let me know.

sobdk:

It's my job (and self appointed at that) to remind people they are supposed to try to help themselves and search for answers before they post questions here. Our resident unpaxing guru, +Spl/\j has even started using my initials as a substitute for the word "search" (as in "you should do a JMI".

Your subject is Armadillo. Go to the top of the Forum and click the search button. On the left side you will see a place to enter a subject for your search. You can use more than one work and the "+" sign. Yes, I know that you said that you had " read several posts" but you still used armkiller, instead of trying to learn how to actually unpack this puppy.

Go back and actually READ the posts from several of the threads where they talking about actually unpacking Armadillo. Using "Armadillo + unpacking" I got 11 threads, at least two with 30+ posts. As I recall the one started by ThrawN has some good information in it. Most of the others will also.

If you "sux" at unpacking, READ the general unpacking threads on how to trace a re-directed IAT. The one right below this one on elcomsoft has some of +Spl/\l's wisdom.

I do not seek to give you a hard time. My mission is to teach "how to find information." If you learn THIS skill you are making great progress on becoming a good reverser. The information, certainly the basic information you have asked about, is out there (and is already here) and it is only a demonstration of lack of effort to not seek the information yourself BEFORE you ask someone here to take you by the hand and lead you to the basic knowledge necessary to do what you want.

It takes time and effort. There is NO easy way to actual learning. Make that effort and YOU will be the wiser for it. You will actually learn very little if someone just shows you how to solve the problem for THIS program. You want to learn how the IAT works and how protectors screw with it to try to prevent you from doing what you want to do here.

If everyone is in too great a hurry to crack their first "whatever" instead of learning the complex information necessary to understand what they are doing and trying to do, they have to keep coming back for the basic questions.

This is not the same as helping someone who read the material and doesn't understand it yet, but your response seems to suggest that you just haven't read enough yet. Give it a shot and come back with more focused questions.

Regards.

sodbk: I confirm what JMI wrote : some days ago, I was exactly at the same point you are. Now I've unpacked successfully several targets, without armkiller... and in between I've learned plenty of things !

Just to answer your questions :
- there is a difference between "resolving APIs" (resolve the right pointers to the right apis in iat), and "rebuild iat" (fix dump). Imprec will be usefull to rebuild IAT , but before you must verify that apis have been resolved correctly (whatever the tool you use : armkiller or your brain)

- I had got problems in the past with former versions of armkiller:all the pointers were not correctly resolved. That's why I went into manual unpacking. For this all necessary info is in this forum.

Thanks BenJ and JMI

I appreciate your replies, infact I new I would get these replies from someone because I seemed to have made the fatal cracker flaw in my post I asked for help. Go Figure. Every forum I have ever read when someone doesn't understand and asked for help they always get the do a search reply. It is for that very reason that I don't normally ask, I just skip to the do a search part, which of course I did prior to my post.

JMI
I went back again and read every post about armadillo that I could last night thinking that I might have missed something or that maybe now that I was further into my target that some of it would be more helpful. Unfortunately while there is a lot about armadillo on these forums they are all about older versions, I am working with 2.52 I think, and there info doesn't seem to apply to me. The info on the boards about 2.52 and later, is very vague, and doesn't help much at all. I also did searches elsewhere last night, and found a tutorial that helps with manual unpacking in general though there target was with asprotect. This tutorial seemed pretty good, and I am sure there is a lot of good info out there I just need to find it. How else did you guys learn to do this shit right?

Anyway I have one question which is similar to what I asked to begin with. It was mentioned by BenJ that because amardillo mangles the iat it can't be fixed by imprec or revirgin. In every post/tut that I read when it comes to the iat part of unpacking your target every one says they used revirgin, or imprec to trace them. The ones who don't say they used these tools say they manually rebuilt the iat but don't say how. I guess I don't understand why some people say that you can't use imprec or revirgin, but everyone seems to use them without claiming that they did other stuff first(redirected the api calls). Infact the short instructions with armkiller tell you to use these tools.

I hope my post doesn't sound angry, believe my I'm not, and I do appreciate the efforts of anyone who replies.

As always I will continue to search for the answers

JMI!

WHY YOU DON'T USE "SEARCH" BUTT0N BEFORE POSTING?????????????

I found many identical posts from you~;0

evaluator:

Our musician friend, didn't you see the "repeat" symbol at the end of the measure? I had to "repeat" the measure, err, message again. It's my job.

sobdk:

Perhaps it would be useful to take a step back and consider the basic concept of what the protectors do and what they have to start with. For this process you need a good understanding of the PE format and how things are generally organized in such files. You need a general understanding of how import and export tables function and how they are generally organized within a PE file. For example, you start with the understanding that a PE file MUST be able to find its imports and exports, or it CAN NOT function. The imports are organized in the IAT, which tell the program what special pieces of other code the programs needs to work properly, regardless of whether it comes from Windo$e or something specific to that program.

Now, if you have this general understanding about how things HAVE to work, you are a leg up on the process of restoring the program to that condition by removing the protector's tricks designed to prevent you from finding out how to register or otherwise use the software fully without paying for it. So next you need some general understanding of the types of "tricks" that the protectors use to mess with your mind and attempt to keep you from seeing the real code.

There are several basic tricks that they can try to make that task more difficult. They can, and the better ones do, mess with efforts to disassemble and/or debug the program, under the theory that if you can't see the code, you can't "fix" it. They can encrypt parts or all of the code to make it difficult to understand. They can screw with the IAT in several ways, but the more common it to give you something that may "look" like the IAT, but it has been redirected somehow in an effort to screw with the IAT reconstructors, Revirgin and Imprec. So you end up with an IAT, but it doesn't seem to lead to the correct APIs, so the "dumped" program doesn't work.

So we need some generic plans of attack on their efforts. The first and formost is to understand that the program HAS to remove its obfuscation and/or have code that leads to the CORRECT APIs, or it CAN'T work. If you start from that point, then you recognize that your job is to FIND where this happens, that point in the protector's code where the relevant part of the code is decrypted and/or re-directed somewhere else. This can be done is several different ways and the "correct" code could be written to the file somewhere and a way to find it written in the "original" location, or it might be stored in memory, either encrypted or decrypted.

Assuming you master the first hurdle and can actually look at the code (because if you can't, you aren't going to manually unpack it) you need to realize that you can actually trace the protection code as it decrypts or moves the important code parts somewhere else. This is different from tracing a dump of the exe, which is generally assumed to be the code AFTER the protector's code has done it's thing and moved stuff around, and maybe back again.

So if you have reached the OEP and then dumped your exe, there is a very good chance that the protector has ALREADY screwed the IAT. One safer approach, but often more difficult, is to watch the protector's code "unwind" itself and often you can actually see it decrypt an IAT and then mess with it in some fashion. For this type of protection scheme, you can often trace to that "magic moment" and then dump the IAT and paste it into a later dump from the OEP and, by that means, "fix" whatever the protector's code did to it, AFTER it decrypted it.

Another technique involves understanding how the re-directed IAT's function and using a debugger (again assuming you have mastered the attempt to prevent you from doing this very thing) and "trace" the IAT entries to determine where they actually go and "fix" your dumped IAT with this information.

So where does all this get you. If you understand that the protectors are working very hard to try to stay ahead of +tsehp and the author of Imprec and find some way to make revirgin and/or imprec fail to "resolve" the IAT or, better yet, make you THINK you have the correct IAT, when you don't, you will understand that for some protector's products, you need to check the results to make sure they are correct.

If you don't understand how to trace an API in the IAT, you only know how to use someone else's tool, and when the protectors learn how to mess with the tool, you are screwed. If you know how to defeat anti-debugger and anti-disassembler code, you have a leg up and now you only need to know how to trace and what to look for.

So to answer your question on how does one learn how to do this sh*t right, the direct answer is that at some point we read a great deal of material on each of the concepts I mentioned above, not just those directed at our "immediate" target" and eventually, over time, one gets a "feel" for the code and a better clue as to where to try to break into their efforts to see the important stuff.

You might not see this as "help" or as not the "help" you want "now." But I believe it is the help you really need to make real progress.

Regards.

JMI

Thank you I do find what you said very helpful, I had already found some tutorials that explained the method of finding the IAT in a debugger and tracing each jmp to the part of the code that redirects each api. But I like the idea of your method, which is probably what BenJ was saying about finding the IAT in memory before the protector mangles it and dump it. I will try both and see if I can succeed at one of them.

I think with the tutorials I have found and your help I will be able to get this one.

All you cracking masters just remember if a newbie asks to learn, and not just the answer it doesn't hurt to point them somewhere like anticrack.de, www.woodman.com, or somewhere they can find good info. "Do a search" is pretty vague for a newbie. I didn't even know this forum existed until I read the readme file in armkiller. And this forum has lots of info. And the whole "newbies need to learn to search the internet" thing is great, but you should remember that you learned that in one of Fravia's tutorials, so point them to it.

sobdk:

I agree with your point about not just saying "search" and that is why I try to always give some guidance on where and/or how to find information. If you read my first post to you, you will notice it does contain some pointed directions on techniques for finding information on your subject, because it wasn't clear the extent of the search you had already done. I try to make it a practice to include an "if you had used the search button you would have found "XXX" type statement along with the reminder to try first to help oneself.

I truely wonder how many of our readers here have actually taken the trouble to visit the Fravia companion site and explored its many facets and wealth of information. That is where I started and the section on "How to Search" was one of the very first sections I reviewed and downloaded and studied.

I'm sure that people come here from all sorts of different paths through the dark codewoods. As I recall I did a basic search on one of the old line seach engines of "cracking" and "reversing" and just started checking our things that looked interesting and ended up here.

As for pointing people to anticrack.de, I refer people to specific section of their archive all the time and their site is Linked at the bottom of this Forum. CrackZ' archive also is worth reviewing if you haven't checked it out yet.

I have a general reluctance to refer people to tuts, even though I have more than 16 gigs of them on my HD, because I tend to believe that starting too early to just FOLLOW a tut inhibits the learning process necessary to gather the broad range of knowledge needed to do MORE than follow. Others have different opinions, but I believe that tuts are useful for studing concepts more that techniques, because by the time you get a tut the software programmer should have already changed something in the code and if you are relying on the tut, instead of an understanding of what you are doing, you are screwed again.

One has to assume, and you know what that makes of "u" and "me," that the protectors are reading boards like this to see what is said about their product and reacting to that information. We know Alexey LongRussianSurName reads the fourm from time to time because he has posted here. So learning how to crack v2.4 of something doesn't always mean that you know how to attack v2.4b or v4.5 of something. If you learn the basic concepts, then you have a head start and have to only discover the "new" twists.

And we don't direct people to 66.36.228.12 when they are already here, but, again, I have frequently directed people on other forums to seek answers here.

Regards.