usual unpacking, rv-recovered, manually fixed unresolved apis
(maybe badly, i don't know anymore)
all assembled and it wouldn't work
as far as i know there is no post oep dips (except for
emulated/redirected apis)
i'm completely and utterly stuck here

if there is an aspr expert with some spare time ...
you can find (exe only + my revirgin "resolved" text file) here
oep is 5D04B0, just to speed things up

hxxy://downloads.come2store.com/puzzled/ht.zip

thank you


edit
****
exe is ~ 1 mb

Hi Puzzled,

I'm puzzled too! could you post more about your findings...
Another thing please read the posting guidelines

what about them ? where did i go wrong ?
this is unpacking isn't it ?
i gave you oep and resolved "input" for revirgin
(if you'd like to try that is)

what do you want me to say ? i've used softice (what else)
started rv then started proggy then ...blahblah ... then pasted inputs into exe then ...
i'm not that new

forgot to say just on thing - when runninng my lame unpacked exe everthing gets stalled somewhere in the resource parsing - no blue screens, no crash - and i finally have to kill process

Hi puzzled,

>i'm not that new

Whether you are new or not is not important.
Your description is very very vague.Ihe more you post the more we know whats the problem.Since you are not new you should write more on how you work on this and ppl will learn also

ah shoot what a debut

i've read quite a few threads here. two things are obvious
- aspr topic is beaten to death
there is nothing spectacular in this proggy, everything i used
or encountered is already described elsewhere,
- there is some general discomfort about discussing this particular protection all over again

and there is no use of code snippets, mem addresses etc
unless you actually try ...
nothing vague in my description
cookbook unpacking, cookbok fixing - it does not work
target available offboard (saving some bandwidh)
two (initial) time consuming tasks included
oep and it

the ones who actually tried might have found
that a call at 006B83FC (aka 002B83FC aka 014DCE98)
is actually FreeResource, not freakin GetVersion
silly me
well i've said i'm a lamer

ok, asprotect removed, works well on 9x/2k/xp
fixed properly, one crc check, activated ...

dede, however, does not take it at all (though it identifies
proggy as delphi 6 when dumped from memory) !
2.5 nor 3.0b nor 3.02

and forms looking really strange in exescope/resource hacker

wtf ? would someone enlighten me please ?

asprotected
pqrs://downloads.come2store.com/puzzled/ht.zip

unpacked
abcd://downloads.come2store.com/puzzled/ht_unpacked.rar

thanks

brothers, sisters, romans ?
anyone ?
just take a look at the bloody thing, please
(forms that is, in a resource viewer such as exescope)
or process with dede

Hi,
The reason there's no reponese cuz you didn't show your effort here.We will treat it as a crack request and would delete in 2 days...

for christ sake, I DID ALL THE JOB ALREADY
which was the reason i posted this in a separate thread.
it is unpacked, fixed and cracked. done. finito.
isn't that bloody obvious ?

all i need is that someone with bettter knowledge
about delphi forms give a second opinion ...
cripted (not likely), protected, stripped, new format, what ?

Probably be better if you confirmed your download files were OK before you start spouting off too much.

WinRAR gives me the following error messages on multiple d/l attempts on your unpacked file:
1 ht_unpacked2.rar: Unknown method in ht_unpacked.exe
2 ht_unpacked2.rar: No files to extract


To start with, the fact you are supplying a link to a fully unpacked app makes it a crack, justification enough for deleting the whole thread outright.

But since your request is a little bit different I'll try to help. I've noticed DeDe sometimes doesn't handle unpacked apps, hardly surprising considering the .rsrc section was likely asp packed as well except for the original icon and version information. You may need to rebuild some pointers in the PE header to the RCDATA resources or you've got some other corruption going on. Try PEBrowse and see if the pointers and pointers to the pointers in the various resource section entries are valid.

">forms looking really strange in exescope/resource hacker"

'Really strange' means what?

Forget about posting your unpacked file, how about a more descriptive approach to the problem and you might find you'll get a more positive response from people.

Kayaker

of course i did



it was packed with winrar 3.0. i've just redownload the file
and it unpacks ok.
caveat: no download managers




i just saw the import table attachment deleted here for the same reason.
where is the line ? and if i post all the relevent information in a text form here then it's kosher ?
a crack ? for what ? nobody even knows the apps name.

Hi

I'm not trying to get into a debate over this. I've got winrar 2.71, maybe this has something to do with the corrupt file, which is why I suggested you describe the problem in case nobody else could view it either.

Where is the line between what's OK to post as an attachment and what's not? That's a good question. It's a balance between supplying what's honestly needed to get help on a valid problem, versus what may be a pure crack request, versus what we can get away with without giving the TPA and others ammunition with which to launch yet another lame attempt at closing this place down.

There's a history here that may not be apparent to the newbie or casual viewer, or even to the regulars, as to the continuing attempts of certain individuals/groups to get the hosting ISP to close this site. After several unsuccessful attempts (the latest not that many weeks ago), their final arguments have withered to the occasional accusation that this site supplies cracks or serial numbers. Their unfounded accusations of "warez" have disappeared at least from their latest libelous statements.

So, it falls on the admins to try to keep these dogs at bay. My theory is if we can keep the discussions under the realm of "intellectual property", and don't give 'em anything smelling like a crack or s/n, then they've got no case and we'll be left alone. Am I being anal (or delusional) about this? Probably, but that's what I'm getting paid for ;-> This is however a community MB, and all decisions are at least open for discussion.

This is *partly* why I try to stress describing the problem rather than posting some file or other. Another reason, and probably more important, is that I've always found that the process of having to describe a problem in an understandable manner to someone else goes a long way towards actually solving that problem yourself. Too often posts are vague 'help me' requests with little to go on, after the person has finally given up.

I hope people better understand my actions of deleting certain attachments, and maybe someone has a better idea of guidelines we can follow.

Kayaker

my god, i really look like an ueber prick, heh ?
first esther accused me of asking a cracking service,
then you accused me of crack distribution !
in the same thread, lmfao


anyway, here is what i've found.
TPF0 identifiers are missing from all forms.

00 00 00 00 10 TCodeGenerate.frm

instead of

TPF0 10 TCodeGenerate.frm


when i entered the strings manually resources became visible in all res viewers.
file does not run (invalid data stream) until the same identifier is
entered in the .data section, offset 1D021C ( virtual 5D161C)
dede can (sort off) process modified file from memory.

also, complete PackageInfo (RcData) is stripped down.
is there any way to recreate this one ?

Heh, heh, it's nothing personal I hope you understand. I'm probably the one who looks like a ueber prick, but I figure it's the price I have to pay for trying to protect the board. I've been hanging around here a long time and I've seen the board disappear a couple of times, and it's only because of the hard work of Woodmann and Tsehp that it was able to be back up on another server within a few days. I've also seen us close to being off the air again more than once as well since, so this more than anything has probably made me an overprotective mother hen ;p But we've got a good thing here, so I figure it's worth it.

That aside, now that it's described, that's actually an interesting problem. It's odd that the file would be dumped without the TPF0 identifiers already present in memory. Can you confirm that they are in the original file just before dumping?

It's *possible* that once a Delphi forms are created, the resources themselves are no longer required unless they need to be recreated. If the forms were created during unpacking then the TPF0 Ids might theoretically be erased afterwards, which would fup the dump. There would be overhead doing it this way because forms like the About box would have to created hidden until called, but once created or copied elsewhere in memory, the original resource template itself might not be needed. Just a theory.

If the resource section is identifiable at all in Reshack, can you 'fix' the problems and recompile the script to get it recognized by DeDe?

Kayaker

to the best of my knowledge, everything that is missing
wasn't there in the first place ( based on unpacking/decrypting
aspr routine observation)
which indicates that it's not needed at all !
and is stripped down just to confuse decompilers.
dede, reshack etc are obviously heavily relying on
before mentioned info.
maybe future versions ...

now, is this a built-in delphi compiler "security" measure
(delphi 6 client/server enterprise)
or some lucid programmers moments ?

it would be helpfull if someone actually take a look
at both packed and unpacked exes


sidenote: you cannot actually try the proggy, databases are missing but take it on my word - unpacked thingy works
perfectly

Hi

I had a good look at the original file, the problems may be associated with some changes introduced in Delphi 6, or possibly that it's a language-specific compiler option, the program is definitely non-english in origin. There's nothing obviously tricky going on, everything is standard Asp, all form creation calls and such are in regular code. ResHack recognizes the resource structure fully, except for the usual Icon and Version info. DeDe recognizes nothing, neither does Exescope.

The only thing unusual is the 1st dword of most of the Rcdata resources, and as you mentioned PackageInfo, which simply seems to be a list of form and control names and such, is empty. It may be something compiler specific with the language used. Rather than TPF0 identifying the start of each resource, there's a zero dword, then the length of the string that follows.

With some of the resources you could guess that they have a new identifier and the "TPF0" becomes unnecessary. There are several "T" forms that look to be changed to "TQR" forms for example.

---------------------------
This Delphi 6 foreign-language app:
00 00 00 00 0B 54 51 52 41 62 6F 75 74 42 6F 78 .....TQRAboutBox
0A 51 52 41 62 6F 75 74 42 6F 78 04 4C 65 66 74 .QRAboutBox.Left

Regular Delphi 5 English app:
54 50 46 30 09 54 41 62 6F 75 74 42 6F 78 08 41 TPF0.TAboutBox.A
62 6F 75 74 42 6F 78 04 4C 65 66 74 03 24 01 03 boutBox.Left.$..
----------------------------

But then with others it's obvious there must be a pointer list somewhere:
00 00 00 00 0B 54 53 70 6C 61 73 68 46 6F 72 6D .....TSplashForm


Probably a manual rebuild as you are doing is all you can do, unless you want to give a shot at trying to reverse DeDe itself and get it to recognize the unusual structure.

Good Luck,
Kayaker

well i could change a thing or two in dede
but only if i face at least one more example of
this childish obfuscation

that's it then, thank you guys and girls for not banning
my sore ass for vague descriptions, lame explanations
and sneaky attempts of crack trafficking

I don't like mysteries (or maybe I do and that's the point , but I was wondering if it was *possible* that the programmer made some changes manually to this Delphi app to prevent DeDe and other reversing utilities from fully recognizing it, or whether it was just some compiler accident or something. Wouldn't actually be a bad trick, Asprotect is efficient enough as a packer to reduce executable size for distribution, but it's really not as secure as it once was (we all know that story ;p

*If* the app is laid naked from Asprotect then it falls on any further protection the programmer may have implemented, and DeDe is arguably the disassembler of choice for Delphi apps. So I did a little checking and found that the "TPF0" identifier at the start of every Rcdata resource form can actually be replaced by any other string combination, including zeroes, as long as another location is changed to reflect the new "identifier of the form identifier".

For example, an Rcdata resource normally begins with "TPF0"

0004E3E8 54 50 46 30 06 54 46 6F 72 6D 31 05 46 6F 72 6D TPF0.TForm1.Form

and there seems to be another single location that tells Delphi to look for this:

00042AB7 00 00 40 1C 46 54 50 46 30 ..@.FTPF0


But these can be replaced with *anything* and the app will still run, but DeDe won't recognize it. i.e., here I replaced TPF0 with "1234":

0004E3E8 31 32 33 34 06 54 46 6F 72 6D 31 05 46 6F 72 6D 1234.TForm1.Form

00042AB7 00 00 40 1C 46 31 32 33 34 ..@.F1234


I don't know what this single location (@ 0042AB7) that defines the identifier actually represents, but it seems common to all Delphi apps I checked. I also tried replacing the PackageInfo structure (which DeDe also uses to get its Unit List) with zeroes, and again the app ran OK.


So I don't know if this solves a mystery or creates one, but there it is for what it's worth ;-)

Later,
Kayaker

Interesting that one can change those first few bytes to totally throw off the decompiler like that, and still have the app run perfectly.. thanks for the analysis, will keep in mind

I ran into something similar (see thread "Delphi Obfuscation". Dede could still recognize and disassemble most of it, except that the procedure code for the "About" dialog thing was totally garbage... Knowing that's where someone might go looking first, I think the author did it intentionally somehow.. didn't really look into how it was done, haven't had time, but it involved some encrypted strings that are all decrypted at a certain point..

Basically, the limitation in shareware version was that you couldn't enter more than 12 tasks at once. My approach was to find the spot right where the decryption occured, bpmb ds:xxxxxx rw the text in ram that it prints when you try to enter >12 tasks, a couple minutes later I found the comparison.

Interesting and weird protection.

Seems that Chameleon Clock and Chameleon Desktop have similar issues.. I'm looking into those as soon as I have time.