How to defeat Password Reminder 1.6 ? (An unknown protector)
 

Hello everybody.
Password Reminder is packed with a unknown protector which screws famous crack tools. Simply it detects OllyDbg, LordPE, FileMon, RegMon, ImprRec, SoftIce and... Also detects patched OllyDbg and LordePE using re-pair v0.51.
An amazing part is it detects OllyDbg HARDWARE Breakpoints. (Is it possible?)!! :(
Only IceExt (with costum driver name) defeats it.
This protector has Anti-Mem patching feature too. I tried to patching memory by ABEL, PELG and others and all of them failed to read process !

Please test it. How could it be defeated and unpacked?

Download link :
hxxp://www.newpowersoft.com/password%20reminder/setup.exe

Password Reminder 1.6 Loader
 

Password Reminder 1.6 is protected with SDProtector!

www.sdprotector.com

This is simple loader for remove some limitation!

SDProtector searches for following strings (in Password Reminder):

I renamed OllyDbg Class and file name, and changed anything contains OLLYDBG and above mentioned strings, like pugins. But no success...
How does this damn protector detects OllyDbg and its Hardware BPs? :(

Hi,
I'm also interested to know.
But checking the site of this protector gives these results in Key Features:

What has attracted me is this line.

powerful protection against most known (and unknown) debuggers

So there must be a special trick to detect Unkown debuggers.

Hope someone can reveal it.

Regards,
Android.

The most powerful tool is FrogsIce - this reports type of antidebugging protection
and EIP address.However, it exists only for Win98 ...

regards.

Maybe this can help you:
*isdebugpresent can detect unknow debuggers.
*comparing firsts bytes of API funcs with CC can detect an unknow debugger.
*setting SetUnhandledExceptionFilter, if you are under a unknow debugger, you can detect it.
*Reading the trap bit ( four debug registers DR0,DR1,DR2,DR3 ).
*if the unknow debugger uses total api redirection you can compare func address with image base.
*in win9x reading the IDT or with VWIN32_Int41Dispatch.
etc...

Regards

Only IceExt could bypass its SoftIce detection. But in OllyDbg...

The only possible ways for OllyDbg detection are describied in Pumqara's article. All of the methods could be bypassed except APi Redirection of OllyDbg. When I try to set Memory Breakpoint on GetProcAddress, SDProtector detetcs the BP and cuases an exception which OllyDbg could not process it.
When I set Harware Breakpoints, SDProtector caused below exception :

The address contanis nothing and debugging will be finished. I converted the JE to JMP and execption never occured.
After that, the second exception occured :

The first line could not be processed. I tried to NOPed it (before executing), but there was alot this CMP, more than 40 (I became tired to count it :( ).
After NOPing about 6th of them, program debugged normally. Then a message poped up :
After pressing SHIFT+F9, the famous strings of Debugger detected appeared it STACK WINDOW, without any messagebox.

That was the whole story.

One question is important :
Is there a fixed address in memory which used by OllyDbg for storing breakpoint addresses? How SDProtector detects them?


And I have another question. Please somebody answer me :
Why existing loader generators couldn't grap ProcessID of protected program by SDProtector?

Thanks for reading this damn post.
Please share your information about SDProtector.

Best regards.

This code "maybe" a BP detection because CC is the opcode of INT 3.
AFAIK when you set a BP, Olly puts a CC to use its handler, so I think no memory is used to store it, only wait until INT 3.
If you're talking about Hardware BP, I think Olly stores its addresses in a local var, so no fixed address...Ummh!! I know that Registers DR0-DR3 are for debug breakpoints and curiously Olly only can set 4 Hardware BP :rolleyes:.
The protection can read and compare this registers.
Maybe that uses a code-execute time detection too.

Regards

Thanks taos.


When I set only hardware BP, SDProtector checks the presence of "int 3" ? The above mentioned CMP could not be done and...debugging will be finished. It's unusual !

How could I know where it reads dr0 to dr3 values?
There is a jungle of junk codes :(

I red somewhere about fs:[20h] and fs:[30h] tricks used by ACProtect. Maybe SDProtector uses them too. The question is method of finding them. :(
Is it possible using conditional tracing like this ?
TC EIP=="some opcodes"

Regards.

today i played with this target.. check if all is OK.
btw, it's marked as SD1.1 at start of 1st section??

original IT restored; OEP bytes restored from 00495C50h;
resource restored by PExplorer; there was 7 crypted code blocks,
wich decrypted on runtime;

..
shit, failed for attach!

SDProtector Pro Edition 1.12 unpacking tutorial
 

at hxxp://www.angelfire.com/indie/zong


EnJoy ;)

@newbie_cracker

For Imprec - it looks for file "ImportREC.exe" and for title "Import REConstructor v1.6..."

You can easy change title with Customizer or similar program.


For LordPE - SDpacker absolutely hates this tool . Apply the same steps as for ImpRec :)

btw. It shows wrong Image_Size of process ( 0x00036000 ). Use any other tools for dumping .



@KaGra

I like your tuts , but what would you do if your target is packed with regged version of packer and you don't have intro Nag to attach ?

well...
 

well,if I don;t have a registered version in my hands,I cannot make any assumptions.But i'd like to have one...

Thanks hosiminh

My problem solved in patching the process in memory. Greetings to The Boss.

I bypassed LordPE detection and dumped the flle. But PE tools dumped better than lordpe, without any errors. Is there a good dumper except Lordpe and PE Tools?

The remaining problem is OllyDbg detection and Unpacking method.

Regards

It depends what you mean. The best dump is always a manual dump. The way of dumping running process simultaneously with its execution (like LordPE, PETools do) is a weak and not "clean" idea. Usually it forces you to keep redundant sections but most of all it makes unpacked executable a lot bigger than original one.

Anyway, it's only my private opinion and you can always work this way. For Delphi executables the best dumper is DeDe (with ability to find OEP).

Regards.