#16
|
|||
|
|||
I see you having hard time, this target isn't a hard one, I did unpack it for a member req. just use my script "asproep"
to go to the oep, write your stolen bytes, then right click on the first one , choose orign here, dump, and fix iat, target should be running, but if u try to choose an option it will exit. so u have to change address 5788b9 to read mov eax,62a43c in stead of mov eax, dword ptr ds:[40701e]. this is on windows xp. it will run fine after that. regards. |
#17
|
|||
|
|||
britedream: Your input, as always is greatly appreciated (I still consider you the master of ASProtect, after all it was you who taught me ), but I think Wurstgote's excercise here is more for learning purposes than to simply get the app unpacked and be done with it. And for learning purposes, what better way is there than to do everything manually?
Quote:
Quote:
Quote:
FYI, the DATA section is for initialized data, the BSS section is for uninitialized data (namely, the data is initialized at runtime). Last edited by Satyric0n; 02-11-2004 at 23:11. |
#18
|
|||
|
|||
Quote:
As SatyricOn proposed, I'm now trying to "clean up" the unpacked exe to make it smaller. Not really necessary, I know, but nevertheless a good way to get some practice! Quote:
So I'll have to see if I can fix that. Regards Wurstgote |
#19
|
|||
|
|||
Quote:
http://www.exetools.com/forum/showthread.php?s=&threadid=2441 It is just another aspect of ASProtect's protection; once you know about it, you take it for granted that it will happen, and it is easy to fix. Regards, Satyric0n |
#20
|
|||
|
|||
To Satyric0n !
Great pleasure to hear from a nice friend,please forgive my ignorance,I thought he is having hard time, so I tried to help. |
#21
|
||||
|
||||
@ britedream:
You turned my attention to another aspect of ASPR, thanks for that! Later I will have a look at the thread mentioned by SatyricOn. @ SatyricOn: Quote:
Quote:
So far I know that the data in .mackt is needed since it contains the IAT. That mean I need to find a way to store the IAT entries somewhere else. Quote:
I thought of using only the _disk_ space at offset 226000 to store the .mackt part, but without changing the virtual offset of the .mackt section. While loading the app, the loader would see that the section located at file-offset 22600 should go to VA 313000 in memory, so the section at VA 22600 isn't occupied and Delphi can use it for whatever it wants. Quote:
Regards Wurstgote |
#22
|
|||
|
|||
Quote:
There is still a solution you haven't thought of yet, though, that I think is best solution (if only because it is more conventional than your idea ). If you feel you have exhausted your thoughts on this subject, I will explain it also. But, I like the way you think about the situation (most people wouldn't bother), as you come up with some very creative ideas. Regards, Satyric0n |
#23
|
|||
|
|||
Quote:
Perhaps you're right and sections need to be in linear order inside PE files. Tomorrow I'll take a closer look! Quote:
Quote:
Have a good night (or day, in case you're on the other side of the world) Wurstgote |
#24
|
|||
|
|||
Quote:
I was wrong I've made an error when recalculating some resulting offsets, but after fixing that stuff, everything runs fine. So it's definitely not necessary for the sections to stay in sequential order inside the file. Although it may be an interesting thing, it's kind of pointless. As you've reminded me a few posts above, the goal should be to completely delete the unnecessary sections, not simply shifting them around. And if the point would be just to reduce filesize, it's enough to set the raw size of sections containing only zeros to zero. I suspect that after wading through knee-deep hex-editing stuff I've reached the same point where I had started So it's time to rethink the matter! Regards Wurstgote |
#25
|
|||
|
|||
Quote:
Quote:
Also, recall now my descriptions of these sections: Code:
.data -- this section is named randomly by ASProtect, and holds ASPR's IAT, some redirected resources, etc .adata -- this section is used as in-memory data storage by ASPR |
#26
|
|||
|
|||
Quote:
So the .mackt section is completely gone! But, man, that was tedious work! First, I've examined the .mackt part at 313000. It starts with a bunch of IMAGE_IMPORT_DESCRIPTORs, with everything but Name and FirstThunk zeroed. Name points again to the .mackt section, while FirstThunk points to section 22a000. So I took a look there: The RVAs in FirstThunk lead to RVAs pointing to IMAGE_IMPORT_BY_NAMEs, which are again located in the 313000 section. Next I fired up a hex editor and changed all pointers to Names in .mackt, so that they point now to corresponding addresses in 22B000 space. After that I've copied the whole .mackt stuff to 22B000, overwriting the data there. Next step was to change all RVAs that pointed to IMAGE_IMPORT_BY_NAMEs to point to the 22B000 area. Then I only had to fix the "Import Table" directory entry to the new value 22B000 and delete the .mackt section. And guess what? Yes, Sir, it works! But I hope there's an easier and less error prone way to do this? So, on to the next section-killing adventure, and thank again for guiding me through this stuff Regards Wurstgote |
#27
|
|||
|
|||
UPDATE: .adata send to hell
|
#28
|
|||
|
|||
Quote:
Quote:
Regards Last edited by Satyric0n; 02-12-2004 at 22:16. |
#29
|
|||
|
|||
Ok, here's the easy way to be rid of the .mackt section:
As I said earlier, the section at 22A000 is called .idata, and was the original IAT/import table before packing, but ASProtect makes it unusable. So, we can use that section again for the new imports, with very little work. In ImpRec, you see a groupbox called New Import Infos, and in there, there is a checkbox called Add new section, which is checked by default. If you uncheck that, you can now set the RVA that you want the imports to be written to. So, we first try putting 22A000 in there, and hit Fix Dump. We get a warning saying that the IAT will be overwritten if we continue. This doesn't look good , but lets continue anyway. Continue to fix dump, then go into LordPE or PE Tools or whatever, and change the location of the import table to 22A000 and the size of the import table to the size that ImpRec tells us it is. But, when we try to run the app, it doesn't work . Ok, we need a new approach. If you click on options in ImpRec, we see quite a few things we can configure. One groupbox in particular looks interesting, New Imports. In there is an option called Create New IAT. Well, if we create a new IAT, it wont matter if we overwrite the old one, does it? So lets check that and hit OK. Still with Add new section unchecked and 22A000 put in the RVA box, lets hit fix dump again. This time we don't get a warning, looking good... It takes a while, then is done giving us a "success" status. When we go to fix the import table size and location in LordPE, we see that ImpRec has already fixed these things for us. Good! Let's try to run it. Unfortunately, that doesn't work either. But that doesn't mean we aren't on the right track. Actually, we did exactly the right thing, but there's one thing ImpRec doesn't do for us that we still need to do manually (it seems to me this is either a bug in ImpRec, or a feature that should really be added..). Before we fix dump, we need to go zero out the contents of the entire .idata section. What is happening, is that ImpRec is overwriting the portions it needs to, but leaving garbage data in the remainder of the section. So, in our dumped file before running ImpRec, lets open it in WinHex (or your hex editor of choice), go to 22A000, select the size of that section, and fill the whole section with 00s. In WinHex, you can do this by hitting Ctrl+L, and with Fill With Hex Values selected, leave in 00 as the value, and hit OK. Once that's done, save the file, and go back to ImpRec. With Create New IAT still checked, and Add New Section still unchecked, and 22A000 still in the RVA, do fix dump. Once again, it takes a while, and once its done, we see in LordPE that the import table location and size has been fixed for us just like last time. But unlike last time, when we try to run the exe, it works! So, that wasn't so bad. By just clearing the .idata section before running ImpRec, and running ImpRec with the right options, we can be rid of the unnecessary .mackt section. Definately much easier than correcting all the imports by hand, no? Regards, Satyric0n Last edited by Satyric0n; 02-12-2004 at 22:55. |
#30
|
|||
|
|||
And again: Kotaus!
I'll try it at soon as possible... At the moment I'm stuck with .data. Okay. It contains 8 bytes for the relocation table at 2EA9C4 and the following 20 bytes are the TLS directory. My plan was to put those 28 bytes to the empty section at 22E000 and then change the directory entries for Relocation and TlsTable with LordPE. After saving, the app runs, but if I try to delete the .data section - BOOM! - nothing... I've checked the single fields in the TLS for references on addresses in the .data range, but nada. So I suppose that .data contains some more information I need to relocate. But what may that be? Regards Wurstgote |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
one newbie question | SubzEro | General Discussion | 7 | 03-12-2015 06:05 |
ASPR, ARMA question | sgdt | General Discussion | 3 | 04-09-2006 03:38 |
ASPR 1.2 question | gabri3l | General Discussion | 42 | 05-01-2004 15:09 |
a newbie question about CRC32 | abccc | General Discussion | 13 | 04-23-2004 03:13 |
"newbie" question for crackers ;) | newbie007 | General Discussion | 4 | 10-07-2003 04:46 |