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

[Newbie_Cracker]

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

[The Boss]

Password Reminder 1.6 is protected with SDProtector!

www.sdprotector.com

This is simple loader for remove some limitation!

[Newbie_Cracker]

SDProtector searches for following strings (in Password Reminder):

SYSTEM\CurrentControlSet\Services\IceExt
OLLYDBG
UKILLOD
FLYODBG
DEBUG_API_SPY_WND_CLASS
OLLYDBG -UKILLOD -
IMPORT RECON STRUCTOR
DFCG SUPERVER IMPORT RECONSTRUCTOR
[ LORDPE DELUXE ]
DFCG LORDPE
FILE MONITOR - SYSINTERNALS
REGISTRY MONITOR - SYSINTERNALS
FLYODBG -
AUTO DEBUG FOR WINDOWS
MDIClient
ACPU
ACPUASM
ACPUDUMP
ACPUSTACK
ACPUINFO
ACPUREG
TCPU
TCPUASM
TCPUDUMP
TCPUSTACK
TCPUINFO
TCPUREG

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:

compression of the application - up to 60%
encryption of the application
counteraction to application memory dumping with ProcDump-like tools.
application integrity check.
powerful protection against most known (and unknown) debuggers
counteracts disassemblers- defeat reverse engineering!
counteraction to memory patching.
defeat API hook (protect any special technique you use).
API for interaction between application and protection routines
runtime code en/decryption
encryption of license-specific code

automation of license generation
licensing system featuring up to 1024 bit public key cryptography
registration via keyfiles or text keys
blacklisting of stolen or compromised keys
detect backdating or reinstallation to gain additional usage.
ability to create trial keys and hardware dependent keys

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.

[taos]

Originally Posted by Android

So there must be a special trick to detect Unkown debuggers.
Hope someone can reveal it.

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

[Newbie_Cracker]

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 :

004EB707   |74 08                 JE SHORT PASSWORD.004EB711
004EB709   |D0AB 0A120010   SHR BYTE PTR DS:[EBX+1000120A],1

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 :

004FBB7A    8038 CC         CMP BYTE PTR DS:[EAX],0CC
004FBB7D    74 0A            JE SHORT PASSWORD.004FBB89

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 :

Don't know how to continue because memory at address 76ADF 3F7 is not readab. Try to change EIP or pass exception to program.

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.

[taos]

Originally Posted by newbie_cracker

[CODE]

004FBB7A    8038 CC         CMP BYTE PTR DS:[EAX],0CC
004FBB7D    74 0A            JE SHORT PASSWORD.004FBB89

This code "maybe" a BP detection because CC is the opcode of INT 3.

Originally Posted by newbie_cracker

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

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 .
The protection can read and compare this registers.
Maybe that uses a code-execute time detection too.

Regards

[Newbie_Cracker]

Thanks taos.

Originally Posted by taos
This code "maybe" a BP detection because CC is the opcode of INT 3.

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!

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


EnJoy

[hosiminh]

@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,if I don;t have a registered version in my hands,I cannot make any assumptions.But i'd like to have one...

[Newbie_Cracker]

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

[dyn!o]

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.