Tages.5.5.Generic.Unpacker-iND

[munsterbuster]

Its sizzling through some p2p and ftp boards. And its on some pre bots < not nuked until now.

[Joe Forster/STA]

I can't keep the pace with modern copy protection but, from what I read from you people here, the greatest advantage Tagés is that cracking a software, protected by it, doesn't mean that cracking another software, also protected by it, will be easier. Now then, how come there's a general unpacker for it?!

[Muji-FightR]

Actually, there _must_ be a generic way to unpack one specific version (!) of a protector as every protector has to protect programs in a special way, otherwise it wouldn't work, huh ?
Afaik you cannot create random protection, well you can but it will eventually all be the same, even tho you have 10 special api redirections, vm entries, opcode interpreters, whatever

If you know all the 10 'random' ways of protection, it should be possible...

[TippeX]

agreed, especially if you use a sandbox style technique, then resolving api's and creating loggers for their api handlers and so on is pretty damned simple...

[caki]

Maybe it patches CD check? New Safedisc API can be a bitch (but still generally resolveable with a sandbox-like technique that TippeX mentioned) but patching the CD check is a much nicer way to deal with Safedisc, because that is mostly general, no matter what the protection options on Safedisc are...

[Joe Forster/STA]

Excuse me but what is "sandbox-style technique"?

[TippeX]

all api's from a dll are rerouted (with care taken into effect for forwarded exports etc..).. new rerouted api has a 'pre' and 'after' portion, between it is the 'live' portion...

like this

pre code -> output param info, stack, whatever (if its an api you're interested in and you've coded the handler for it)
real code -> simply pushes the params again (if any) and calls api
after code -> api has been called, log info or run handler etc.. (preserving registers), code then returns (fixing up stack and cleaning up)

problems -> multi threading.. your handler must handle the case of multi threading, so use locals on the stack, also generally needs to be done in asm (so its clean and tidy.. and small)..

after you've got it all working, its pretty damned nice

every export should have its own unique address, making import table fixing etc a doddle

once you've then 'targeted' the api's you're after you can then code record/playback portions, making the call do whatever you like...

simple in theory, hard to get done, once done its probably the most powerful system you can handle- requires no anti debugging and pretty much has complete control of the process (code wont use debug api's for example.. in 2k or higher all the handlers and rerouting is local, ie: not global on the system, so it wont be 'seen' by anti debug code and so on.. provided its coded well of course...)

the record/playback does work for some protections...

many methods to get it done...

1. dll injection (can get very messy)
2. 'fixing' windows file protection, and patching dlls and so on.. and using events/flags to enable/disable handler code.. tons of work but pretty damned safe.. generally if you're doing this, you've got to be good.., and if you want to be safe use vmware
3. both of the above

only shit thing is when you have it done, lots of lamers ask you for it..... (and none should get it)

[cdkiller]

yeh i´ve also heard about this tool, but i don´t know if it´s real...
why releasing such a tool? so developers can have an eye into it and check how...?

but a generic tages 5.5 unwrapper can be done (like Muji-FightR said) because the Tages Basic executable wrapper is the same in every version of 5.5