Why can't I re-Dillo it?

I hope this wasn't asked before. If if has, I am sorry and please deleted my thread.

I am newbie at unpacking but maybe found something useful. I dumped few targets protected by Armadillo 3.xx and then I wanted to re-protect it with Armadillo. Well when adding my dumped file in Armadillo, its shows it as already Protected. The reason for that is because of two bytes in PE Header.
*Copy/Paste from Olly*
004000DA 53 DB 53 ; MajorLinkerVersion = 53 (83.)
004000DB 52 DB 52 ; MinorLinkerVersion = 52 (82.)
I don't really know what role these bytes play in but I usually zero out both and then I can Dillo the file.

In the attached pic you see these two bytes in black when looking at them in a hex editor. You basically find "PE" then count 18h bytes from there and you will land on the correct location. They read "SR" in ASCII.

Hope this helped someone.

Here is a Copy/Paste from Hex editor for those that can't download attachments.

00000000 4D5A 9000 0300 0000 0400 0000 FFFF 0000 B800 0000 0000 0000 MZ......................
00000018 4000 0000 0000 0000 0000 4584 0500 0000 0000 0000 0000 0000 @.........E.............
00000030 0000 0000 0000 0000 0000 0000 C000 0000 0E1F BA0E 00B4 09CD ........................
00000048 21B8 014C CD21 5468 6973 2070 726F 6772 616D 2063 616E 6E6F !..L.!This program canno
00000060 7420 6265 2072 756E 2069 6E20 444F 5320 6D6F 6465 2E0D 0D0A t be run in DOS mode....
00000078 2400 0000 0000 0000 D94B C4DB 9D2A AA88 9D2A AA88 9D2A AA88 $........K...*...*...*..
00000090 1E36 A488 9C2A AA88 F435 A388 9F2A AA88 7435 A788 9C2A AA88 .6...*...5...*..t5...*..
000000A8 5269 6368 9D2A AA88 0000 0000 0000 0000 0000 0000 0000 0000 Rich.*..................
000000C0 5045 0000 4C01 0800 69B4 1E40 5B4C 6F72 6450 455D E000 0F01 PE..L...i..@[LordPE]....
000000D8 0B01 5352 0030 0200 0070 0300 0000 0000 7815 0000 00D0 0100 ..SR.0...p......x.......

... something similar I wanted to know Why can't I re-ASPR

Regards,

[JMI]

Well, let's put on our thinking caps here. Ploop. Hat goes on.

Do you suppose ASPR also adds something to the PE header to check if its "already" protected by ASPR.? Well, how the heck would someone be able to determine that? Ponder, ponder, ponder. Think, think, think.

I know. Let's look at the PE header for something we already have we know is not packed by ASPR - Notepad (unless, of course, yours already is ). Yah, Yah, but then what do we do , huh, huh? Well, why don't we just ASPRize the darn thing and then look at the PE header again. Maybe even use a file compare program (insert name of your favorite here) and actually see if that sneaky guy with the long Russian surname puts something in the header.

Well gosh. Why didn't I think of that?? I must be too old.

Regards,

you most clean up the sections and code armadillo mades into the app. or sure will read it as it was protected

Wicked stuff JMI

JMI I said "I wanted to know" and not "I want to know". That means I already found out using the big lesson in my signature

Regards,

[JMI]

Hi ferrari:

I actually "assumed" YOU already knew, but thought the "lesson" might be useful for those who hadn't "thought" about such things.

Regards,

Wow JMI thats the exact method I used to find the "SR" in Armadillo. I guess this should work for any protector.

Crk: The Armadillo's I worked with are 2.xx - 3.75, I don't know if what you say is true for newer Armadillo but the ones I played with all I had to do is change those two bytes. I don't know if cleaning up dillo code is really necessary but its not easy I don't think, same for the sections, you can't just delete them to introduce black holes. If you have any more info, I would appreciate it.

[JMI]

And just in case the full use of this comparison technique hasn't become clear, you can also "compare" cracked and uncracked versions of almost any software and discover all the changes which were made. This won't tell you "why" the changes were made, but knowing "where" would usually permit you to disassemble the code and try to figure out "why" it was changed at certain locations, such as to pass the "good boy/bad cracker" checks, etc.

For example, if you discover where version x.x.4 was patched, it is at least a good possibility that version x.x.5 might be made to work by patching in the same places. And in this instance, "same places" does NOT necessiarly mean the "same address," although it might be the same. It generally means "in the same routine" found in the previous version. The vendor may have moved that routine somewhere else in the code or an addition to the code might move it slightly forward or backward in the code, so one needs to actually "LOOK," rather than just blindly changing stuff at location 4XXXXXXX.

Regards,

Regards,