Log in

View Full Version : Asprotect Debugger ...


Manko
January 29th, 2004, 20:22
Hi, guys!

I'm really sorry to come draging with this old piece of shit again...
But due to demand, and since that site won't host it anymore...

I won't post source since it's become such a tangled web...
Maybe if I rewrote it again...
Anyway, if you're after my "secrets" I'd be glad to share anyway...

This is "latest" asprdbgr... We will call it asprdbgr_build_100,
though it's not... ehrm...

It hasn't been tested too good, so I might regret posting it.

101:
Fixed major bug to do with diphandling, that would crash targets...
Added commandline handling.

102:
Fixed bug in commandlinehandling...
Now you can load .dll with asprdbgr. (It will load it through the LoadDLL.exe)
(Droppping dlls work too, ofcourse.)

103:
Fixed bug in stolenmutatedbytes-handling... (Thanks, SideSwipe!)
Fixed several bugs trying to get a mysterious target working, didn't work but fixed a couple of other targets.

104:
Some more targets will work now. (That it LordWays?)

105:
Sigh! Major fuckup! My lack of time and therefore testing is responsible.
App would erase almost all IAT sometimes. It won't now, hopefully!

106:
Had to improve IAT handling since it still erased valid entries sometimes.
Now it seems to be a thing of the past. It'd better be!

/Manko

Js
January 29th, 2004, 22:16
Hiya,
A lazy man's tool, I like it a lot .
cheers

Manko
January 30th, 2004, 20:19
Hi!

It seems I had broken some of the functionality doodling with the source, after my site downed... all fixed now!
(A whole line of aspr targets would crash...)

I have also added commandline parsing so I and anyone else can drop files on it, or put it in "SendTo" or similar.

Next build I hope to have added the ability to load .dll's directly in asprdbgr.
It's not hard, only I'm pressed for time, or lazy, at times...

Look at first post for download!

/Manko

hitman_crk
January 30th, 2004, 21:28
Thank you bro
Tool very good

Manko
January 31st, 2004, 21:18
Ooops! Fucked up with the commandlinehandling...
fixed. Also, if you should want you can now load dlls...

I'm working on finding a few bugs that stops asprdbgr from doing it's job on some few (I hope) targets, even old ones...

l8er...

/Manko

sinker
January 31st, 2004, 21:26
Nice work~ Manko

/sinker

lordways
January 31st, 2004, 23:36
it is nice tool

xiangxue
February 2nd, 2004, 09:47
thanks

Manko
February 3rd, 2004, 20:18
Hi!

103:
Fixed bug in stolenmutatedbytes-handling... (Thanks, SideSwipe!)
Fixed several bugs trying to get a mysterious target working, didn't work but fixed a couple of other targets. (Thanks Harding?! Hmm... deleted mail, so I'm not sure who to thank!)

Please feel free to bug me about bugs!

/Manko

ZZZ
February 3rd, 2004, 20:19
Very good tool!

But i have a last problem with stolen bytes.

Please write, how find stolen bytes with AsprDbg.

Thanks!!!!

esther
February 4th, 2004, 12:02
I have already flush it in the toilet with wrappers

evaluator
February 4th, 2004, 12:33
how about Tools Forum?

esther
February 4th, 2004, 12:36
how about using the search button on the top of the forum

SpeKKeL
February 4th, 2004, 15:29
Quote:
[Originally Posted by esther]how about using the search button on the top of the forum


Archh..., my browser kills yellow Search-buttons...

Spekk.

lordways
February 5th, 2004, 06:41
I think asprdbgr1b is better than asprdbgr1.03.

dELTA
February 5th, 2004, 10:18
Thanks for that extremely useful piece of information lordways, you wouldn't by any chance want to elaborate a little?

esther
February 5th, 2004, 12:15
>>Archh..., my browser kills yellow Search-buttons...

how about changing you spectacles LOL

Manko
February 5th, 2004, 16:49
Hi, LordWays!

U might be right about that, to atleast some extent. After some of the 1b versions, the source was fucked pretty badly by some idiot (It was me...) and I've now been working to get it on track again.
Some targets that works with 1b won't work on 103, but then again 103 actually can do some that no version 1b could do properly...

(I do have a nagging suspicion that I still have some broken functionality to take care of that I havn't yet thought of...)

I have been strugling with a couple of hard cases recently and can't seem to get them to work the way I'd like it so I decided to do it the easy way... It might slow the app a little on those targets, but might still be exactly be what you're looking for...

If it isn't I'd like to know what you think I have screwed up and example of which target(s) will demonstrate this... also, I don't have the version you're using anymore, so that might be something I'd like to have too...

104: More targets work now... See above... (Within the hour...)

/Manko

Quote:
[Originally Posted by lordways]I think asprdbgr1b is better than asprdbgr1.03.

JMI
February 5th, 2004, 16:58
Manko:

Many wish we had the time and the skill to mess up even half as badly as you may have possibly inadvertantly done with some versions of this tool. Remember that those who aren't satisfied with your efforts should better spend their time and effort in writing their own damn tools, then complaining about something into which they put no effort other than pressing a couple of buttons.

Regards,

Manko
February 5th, 2004, 17:11
Hi, ZZZ!

Quote:
[Originally Posted by ZZZ]Very good tool!

But i have a last problem with stolen bytes.

Please write, how find stolen bytes with AsprDbg.

Thanks!!!!


Ya, there's one very ugly method and then there's other methods...

The Uglyyyy:
Copy a large chunk of memory, starting well before and weeell after the address stated in asprdbgr. (Experiment...)
Copy it as new section into dumped and IAT-fixed exe, remembering to correct PE, particularly we want this new section to occupy the same memory are as it did in original, also you need to make the section above very large in virtual... hrm...
Use address stated in asprdbgr as new entrypoint.
If you have fixed all other things that don't have anything with stolen bytes to do, it will hopefully work.
This could be automated...

Other methods:

use softice alongside asprdbgr to look at or sometimes follow mutated code to find stolen bytes.
It can be done live or after it's been done already... Doesn't matter much...
Labba has tut for this and the whole manual way...
Also some just try and figure out afterwards looking at registers and stack, what code might make them this way, and stick it in there...

Remember, you don't really need to place the code at the original entry point, as long as you jump to the right place after executing whatever code you like... (There's always plenty of places to put code in a exe...)

/Manko

sonkite
February 6th, 2004, 17:56
How come sometargets unpack fine and others crash what other tricks does aspr use other than stolenbyte? Would be nice with some info on this.

Manko
February 6th, 2004, 18:24
Hi, Sonkite!

Quote:
[Originally Posted by sonkite]How come sometargets unpack fine and others crash what other tricks does aspr use other than stolenbyte? Would be nice with some info on this.


There are numerous possibilities, but they can be sorted in few categories:

1. Traps made in dips.
2. Tests inside main app to see if aspr is still there.
3. Faulty unpacking...

Back in the days, when I learnt aspr it was quite common for authors to use dips to set up flags, asprcalls or initialize variables, so the unwary dumper would be fooled...

Also it was and is possible to now and then see functions in the protected app the try and write to one of the emulated API's. This will work with aspr, but will crash the unpacked app, since you aren't allowed to write in kernel-space.

Faulty unpacking? Many possibilities... Mainly badly resolved IAT, bad OEP or as you said stolen bytes not resolved right...

There's probably more to be said and explained about this... .. .

/Manko

Manko
February 6th, 2004, 18:38
Hi, JMI!

Thanks! You have given me new resolve to continue with messing up these new versions as well.
Pitty I've now taken to actually giving different builds different names...

(PS Thanks! DS)

/Manko

regor
February 10th, 2004, 17:13
Hi Manko,

I appreciate your work and i would like to thank you for this update. Are you still providing the source of your tool ?

RegoR.

Manko
February 10th, 2004, 19:00
Hi!

Thanks!

I might be persuaded to give out my increasingly tangled and poorly commented source... Get back to me more privately!

/Manko

Quote:
[Originally Posted by regor]Hi Manko,

I appreciate your work and i would like to thank you for this update. Are you still providing the source of your tool ?

RegoR.

Manko
February 13th, 2004, 20:22
Hi, all!

Quote:
[Originally Posted by Manko]Thanks! You have given me new resolve to continue with messing up these new versions as well.
/Manko


Ehr... I did it...

105:
Sigh! Major fuckup! My lack of time and therefore testing is responsible.
App would erase almost all IAT sometimes. It won't now, hopefully!

Actually it was pretty strange... I had problems with syminitialize...
It would not initialize correctly if I chosed debugee with getopenfilename...
If i got name from commandline it WOULD work... Really crazy!

I had to solve it by again running syminitialize in same thread as the rest of the app. Sadly that means that if syminitialize hangs my whole app will hang...

aparently symbol_handling is sensitive to wich thread it is run in according to more than one source on the web... but why then did it work when i got name from commandline? It was still run in different thread!?

GetOpenFileName does something... hmm...

Never mind...

New build is above, sorry to those who were affected...

/Manko

evaluator
February 14th, 2004, 07:26
GetOpenFileNameA on XP, first-time mostly does RaiseException inside

LiKuS
February 15th, 2004, 11:34
Build 105

sprDbgr v1.0beta (:P) Made by me... Manko.

iEP=401000 (Name of Target Removed- Identify Target Specific Code Only by PM.)

IAT Start: 4DB000
End: 4DB76C
Length: 76C
IATentry 4DB1F8 = 19D1CD8 resolved as GetCommandLineA
IATentry 4DB294 = 19D1CB8 resolved as GetCurrentProcess
IATentry 4DB2D0 = 19D1C64 resolved as GetModuleHandleA
IATentry 4DB324 = 19D1C8C resolved as GetVersion
IATentry 4DB364 = 19D1CC8 resolved as LockResource
IATentry 4DB390 = 19D17A4 resolved as GetProcAddress
12 invalid entries erased.
Dip-Table at adress: 19D7AB4
0 4091E0 0 409210 4091F0 0 0 409220 409230 409C80 0 0 0 0
Last SEH passed. (19D39EE) Searching for signatures. Singlestepping to OEP!
Call + OEP-jump-setup at: 19E7088 ( Code: E8000000 5D81ED )
Mutated, stolen bytes at: 19E70D4 ( Code: 64EB0169 EB01E856 )
Erase of stolen bytes at: 19E7037 ( Code: 9CFCBF76 709E01B9 )
Repz ... found. Skipping erase of stolen bytes.
possible (temp)OEP: 4A0469 (Reached from preOEP: 19E7048)
possible (temp)OEP: 49E140 (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E141 (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E146 (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E14A (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E14C (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E152 (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E157 (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E159 (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E15E (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E160 (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E162 (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E164 (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E166 (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E168 (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E16A (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E16D (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E16E (Reached from preOEP: 4A4697)
possible (temp)OEP: 49E73A (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E73B (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E73D (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E73F (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E744 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E749 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E74F (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E750 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E757 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E75A (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E75B (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E75C (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E75D (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E760 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E764 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E767 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E76A (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E76D (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E76F (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E771 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E773 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E778 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E77B (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E77E (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E781 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E785 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E788 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E78B (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E791 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E796 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E799 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E7DC (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E7DF (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E822 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E825 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E827 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E828 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E82A (Reached from preOEP: 4A2C76)
possible (temp)OEP: 49E830 (Reached from preOEP: 4A2C76)
possible (temp)OEP: 4A2C7B (Reached from preOEP: 49E876)
......

dELTA
February 15th, 2004, 18:42
And the point of that post is what exactly?

JMI
February 15th, 2004, 19:04
I believe it is a non-expressive complaint that he never actually reached the "final" OEP. But then Eval tells me I suck at interpreting the "obscure" posts of others.

Regards,

Manko
February 17th, 2004, 18:55
Hi!

Thanks to sonkite, I finally fixed the dbgr so it wont fuck up the IAT.
Damn stupid symbolhandling shit... hrm...

106:
Had to improve IAT handling since it still erased valid entries sometimes.
Now it seems to be a thing of the past. It'd better be!

/Manko