Aspacking a manually UnAspacked file

I have a wee project. I am trying to Aspack an application which was initially Aspacked. I manually unpacked it, patched it, and am now trying to repack it.

The completed unpacked and patched file runs fine - I have removed the original .ASPR and .RSRC sections - relocating relevant 'bits' to other parts of the program. Relocation section has been removed as the pointers pointed nowhere.

I have, with some difficulty managed to repack it, but when attempting to run it it displays an APPLICATION (i.e. not a system error) message box EACCESSVIOLATION. I believe it has trouble accessing some of it's DLLs.

It seems strange to me that the unpacked file runs but the packed one doesn't. I can only assume that I've made an error in my import table somewhere, the system is able to relocate successfully for the unpacked file but not for my packed one.

I don't know which version of AsPack it was originally packed with however expect it to be about the latest version available. I am packing it with AsPack 1.04b (believe it or not).

I'm just wondering if anyone has done similar work and I if might be missing something obvious?


Further details:

Close inspection of my (manually dumped part way through the unpack - table at end of unpack had been overwritten) import table reveals possibly some areas for concern.

The AsPack version I have adds a .DATA section.

Prior to my relocating the original TLS data (from the original .ASPR section) the file would pack but I would get system error messages when attempting to run it.

I have many more details on the steps I have gone through to get to this point. If anyone is interested in helping me I'll give further infos. I guess this is just 'testing the water' so to speak.

Any help appreciated

mark_E

hello mark_E,

are you sure that you handle with Aspack or is it maybe ASprotect?
use PEiD or FileInfo to find out wich one is used.

Hi GlObAl,

Apologies for the delay in replying . . . I've just got back to work after 4 days off.

. . . thought someone might ask the question you've just asked! Please read .ASPR as .aspack

At the end of the day, however, I don't care what it's packed with as I now know it's definitely unpacked O.K. and my 'mods' are all sound.

Interestingly enough, when I pack the newly dumped file, I get the exception messages mentioned. If I then unpack this file it runs O.K. Go figure . . .

It seems that the packed program, when attempting to run, calls a routine a number of times and retrieves a value from [FS:2C]. The first time it calls this routine a value is returned which the program doesn't like, subsequent calls return a value the program can live with. I can change this value and get the program to run, everything SEEMS to work O.K. I don't, as yet, know what this routine is checking . . .

I am reluctant to patch this without knowing what it does.

I feel I'm still making progress here , albeit slow.

Any suggestions appreciated.

mark_E

After packing with 1.04b, .tls section contained data - previously it was all 0000s. Proggy was getting data from here but unable to clear the data without crashing the program.

Have resolved, NOT solved, the problem by downloading AsPack 2.12 and packing my dump with that.

All is sweet! . . . but real frustrated that I couldn't solve the problem.

Can anyone shed any light on what happened here? Has anyone got any info on tls and threads? - I don't quite follow what was happening here!

the routine you were talking about, is it a part of the application or was it one of the Tlsxxx API functions?

to my knowledge, FS:[2Ch] points to the TLS array for the current thread and references to it will be seen whenever one of the TLS slots are being accessed.

is that the IMAGE_TLS_DIRECTORY itself or the data it points to?
you will need to make sure that the data pointed to by the structure is in order...

most likely this is where you have failed.

edit:
perhaps the sections involved were not given the correct access flags when you relocated the TLS data?

regards, sna

I would think this would be a section access problem too. Perhaps one of the sections were readwrite, but made readonly by the loader before you managed to dump the process?

Hi sna, squidge

Thanks for the reply!

I started to write this and the post just got longer and longer and longer and more and more hard to follow - to answer your queries CORRECTLY I would need to retrace my steps to ensure accuracy. If you are interested I will do this.

So the short answers are:

sna

the routine you were talking about, is it a part of the application or was it one of the Tlsxxx API functions?

. . . part of the application

is that the IMAGE_TLS_DIRECTORY itself or the data it points to?

the IMAGE_TLS_DIRECTORY - just the offset. The correct data was already in the .rdata section (originally this offset pointed to the .aspack section)

sna and squidge

I stuffed around with various section characteristics quite a bit in attempting to work out what was happening - quite probably overlooked something!

Summary:

I expect that you guys are right as I don't really know much about all this but . . .

. . . it seems strange to me that the resultant application packed with Aspack 1.04b wouldn't run and yet packing the exact same file with 2.12 would. I would think that if there was a problem with the dumped file it would show up irrespective of the AsPack version it was being packed with. The only thing I can think of is that the 'b' in 1.04b does stand for beta.( It also seems strange that the file packed with 1.04b, when dumped, would run fine.)

mark_E

hello,

you really need to repack it? i mean have you thinking about inlinepatching your target?

for aspack its really easy to inlinepatch it...

Yes! I did think of inline patching this but in the end there were such a large number of changes that I thought it would be easier to just repack it.

mark_E