Не одним, так другим средством оттрейсят, есть в конце-концов IDA и др. декомпилеры... Если прога дорогая - то самый лучший способ - шифровка проги и данных ключом, который генерится на основе подлинных паспортных данных покупателя. Ключ вводится каждый раз при запуске, а прога и данные декриптуются пофрагментно, по мере использования. Если пароль "вышел в тираж", то по имени будет ясно, кто его распустил. Но для мелких дешевых прог такой способ не годится - слишком геморно для юзера.
В шароваре я делаю так: пароль генерится на основе инициалов с креды, но вводится единожды, при инсталляции (это, конечно не гарантирует от покупки по 3.14зженной креде, но против етого никак не поборешься...). Хранится он в реестре, в зашифрованном виде, чтобы соседи не сперли, но особенно его прятять нет смысла, т.к. любые ф-ции чтения данных (из реестра, с диска) вычисляются элементарно. Затем, (Главная проблема!) загрузив пароль для проверки при очередном запуске проги, нужно так его спрятать в памяти, чтобы нельзя было найти, когда его будешь проверять (вот тут, я и сам с удовольствием бы поучился!). Беда в том, что если пароль хранится в памяти, то всегда можно поставить БПТ на эту ячейку, и таким образом найти фрагмент, где он пережевывается дальше. Я выкручиваюсь таким способом: Сохраняю его с помощью одной ф-ции АПИ, а читаю другой, для этого не предназначенной, используемой левым способом, так, чтобы найти все это нуно трейсить саму Вынь; но таких пар ф-ций очень мало, по етому, как конкретно я это делаю, разглашать не буду, ищи аналогичную пару сам...
1) кодить под УНИХ ж)
2) под виндами - есть куча наездов на айс, простые - смотреть на первый байт входа в функцию, работать с DRx использовать у себя int3, сложные - работать с multithread
теоретически - защититься нельзя
практически - запросто
КАК защититься от SoftIce маза-фака-щеет.22.08.01 19:42 Автор: :-) <:-)> Статус: Elderman
> > КАК защититься от SoftIce маза-фака-щеет. > > 1) кодить под УНИХ ж) > 2) под виндами - есть куча наездов на айс, простые - > смотреть на первый байт входа в функцию, работать с DRx > использовать у себя int3, сложные - работать с multithread > > теоретически - защититься нельзя > практически - запросто
Самый сложный способ - разработать свой виртуальный процессор и его рограммный эмулятор, и писать защиту на нем... желательно все это делать в ring0 :)
Посмотри книгу Криса Касперски "Техника и философия хакерских атак"
КАК защититься от SoftIce маза-фака-щеет.22.08.01 10:28 Автор: eVAL. Статус: Незарегистрированный пользователь
=====================================
* Details of FrogsICE returned code *
=====================================
Code 00
=======
This code is returned by FrogsICE when a soft executes an int03h opcode
but without using any special trick to detect SoftICE presence (backdoor
commands, magic values...see code 01/02).
This method of detection of SoftICE (as well as the following one) is
used by the majority of packers/encryptors found on Internet.
It seeks the signature of BoundsChecker in SoftICE
Still a method very much used (perhaps the most frequent one). It is used
to get SoftICE 'Back Door commands' which gives infos on Breakpoints,
or execute SoftICE commands...
It is also used to crash SoftICE and to force it to execute any commands
(HBOOT...) :-((
Here is a quick description:
-AX = 0910h (Display string in SIce windows)
-AX = 0911h (Execute SIce commands -command is displayed is ds:dx)
-AX = 0912h (Get breakpoint infos)
-AX = 0913h (Set Sice breakpoints)
-AX = 0914h (Remove SIce breakoints)
Each time you'll meet this trick, you'll see:
-SI = 4647h
-DI = 4A4Dh
Which are the 'magic values' used by SoftIce.
For more informations, see "Ralf Brown Interrupt list" chapter int 03h.
Here is one example from the file "Haspinst.exe" which is the dongle HASP
Envelope utility use to protect DOS applications:
4C19:0095 MOV AX,0911 ; execute command.
4C19:0098 MOV DX,[BX] ; ds:dx point to the command (see below).
4C19:009A MOV SI,4647 ; 1st magic value.
4C19:009D MOV DI,4A4D ; 2nd magic value.
4C19:00A0 INT 3 ; Int call.(if SIce is not loaded, jmp to 00AD*)
4C19:00A1 ADD BX,02 ; BX+2 to point to next command to execute
4C19:00A4 INC CX
4C19:00A5 CMP CX,06 ; Repeat 6 times to execute
4C19:00A8 JB 0095 ; 6 different commands.
4C19:00AA JMP 0002 ; Bad_Guy jmp back.
4C19:00AD MOV BX,SP ; Good_Guy go ahead :)
The program will execute 6 different SIce commands located at ds:dx, which
are: LDT, IDT, GDT, TSS, RS, and ...HBOOT.
* the "jmp to 00ADh" is performed via an SEH if the debugger is not loaded.
___________________________________________________________________________
Code 03
=======
Less used method. It seeks the ID of SoftICE VxD via the int 2Fh/1684h
(API Get entry point)
xor di,di
mov es,di
mov ax, 1684h
mov bx, 0202h ; VxD ID of winice
int 2Fh
mov ax, es ; ES:DI -> VxD API entry point
add ax, di
test ax,ax
jnz SoftICE_Detected
Method identical to the preceding one except that it seeks the ID of SoftICE
GFX VxD.
xor di,di
mov es,di
mov ax, 1684h
mov bx, 7a5Fh ; VxD ID of SIWVID
int 2fh
mov ax, es ; ES:DI -> VxD API entry point
add ax, di
test ax,ax
jnz SoftICE_Detected
Method seeking the 'magic number' 0F386h returned (in ax) by all system
debugger. It calls the int 41h, function 4Fh.
There are several alternatives.
The following one is the simplest:
mov ax,4fh
int 41h
cmp ax, 0F386
jz SoftICE_detected
Next method as well as the following one are 2 examples from Stone's
"stn-wid.zip" (www.cracking.net).
They are both a bit harder to detect but FrogsICE intercepts them without
any problems:
Method of detection of the WinICE handler in the int68h (V86)
mov ah,43h
int 68h
cmp ax,0F386h
jz SoftICE_Detected
Note that, while loaded, FrogsICE will patch interrupt 68h so that it
will be impossible for an application to detect SoftICE.
=> it is not possible to set a BPINT 68 with softice but you can hook a 32Bit
app like this:
BPX exec_int if ax==68
(function called is located at byte ptr [ebp+1Dh] and client eip is
located at [ebp+48h] for 32Bit apps)
__________________________________________________________________________
Code 08
=======
It is not a method of detection of SoftICE but a possibility to crash the
system by intercepting int 01h and int 03h and redirecting them to another
routine.
It calls int 21h functions 25h and 35h (set/get int vector) and ds:dx points
to the new routine to execute (hangs computer...)
FrogsICE intercepts the set int vector call (function 25h)
mov ah, 25h
mov al, Int_Number (01h or 03h for FrogsICE)
mov dx, offset New_Int_Routine
int 21h
This method is closed to methods 03 and 04 (int 2Fh/1684h) but it is only
performed in ring0 (VxD or a ring3 app using the VxdCall).
The Get_DDB service is used to determine whether or not a VxD is installed
for the specified device and returns a Device Description Block (in ecx) for
that device if it is installed.
mov eax, Device_ID ; 202h for SICE or 7a5Fh for SIWVID VxD ID
mov edi, Device_Name ; only used if no VxD ID (useless in our case ;-)
VMMCall Get_DDB
mov [DDB], ecx ; ecx=DDB or 0 if the VxD is not installed
Note as well that you can easily detect this method with SoftICE:
bpx Get_DDB if ax==0202|ax==7a5fh
=>Disable or clear breakpoints before using this feature. DO NOT trace with
SoftICE while the option is enable!!
This trick is very efficient:
by checking the Debug Registers, you can detect if SoftICE is loaded
(dr7=0x700 if you loaded the soft with SoftICE loader, 0x400 otherwise) or if
there are some memory breakpoints set (dr0 to dr3) simply by reading their
value (in ring0 only). Values can be manipulated and or changed as well
(clearing BPMs for instance)
The method used by FrogsICE to detect Debug Registers access is only available
for 486i+ CPU.
=>FrogsICE will NOT show the BleuScreenOfDeath while hooking debug registers.
See FrogsICE.txt
This method is most known as 'MeltICE' because it has been freely distributed
via www.winfiles.com. However it was first used by NuMega people to allow
Symbol Loader to check if SoftICE was active or not (the code is located
inside nmtrans.dll).
The way it works is very simple:
It tries to open SoftICE drivers handles (SICE, SIWVID for Win9x, NTICE for
WinNT) with the CreateFileA API.
Although this trick calls the CreateFileA function, don't even expect to be
able to intercept it by installing a IFS hook: it will not work, no way!
In fact, after the call to CreateFileA it will get through VWIN32 0x001F
service _VWIN32_ReleaseWin32Mutex (via Kernel32!ORD_0001/VxDCall function)
and then browse the DDB list until it find the VxD and its DDB_Control_Proc
field.
In fact, its purpose is not to load/unload VxDs but only to send a
W32_DEVICEIOCONTROL (0x23) control message (DIOC_OPEN and DIOC_CLOSEHANDLE)
to the VxD Control_Dispatch proc (how the hell a shareware soft could try
to load/unload a non-dynamically loadable driver such as SoftICE ;-).
If the VxD is loaded, it will always clear eax and the Carry flag to allow
its handle to be opened and then, will be detected.
You can check that simply by hooking Winice.exe control proc entry point
while running MeltICE.
If this example, FrogsICE will then return 'detection at cs:00401071'
(call to CreateFileA + 1 instruction) and 'string ref at cs:00402025'.
=>FrogsICE will fetch the caller's name just to ensure it is not Loader32.
If it is, it will not hook it.
=>FrogsICE cannot be detected using this method ;-)
There could be hundreds of BPX you could use to detect this trick.
-The most classical one is:
BPX CreateFileA if *(esp->4+4)=='SICE'|*(esp->4+4)=='SIWV'|*(esp->4+4)=='NTIC'
-The most exotic ones (could be very slooooow :-(
BPINT 30 if eax==002A001F && (*edi=='SICE'|*edi=='SIWV') ; will break 3 times :-(
-or (a bit) faster:
BPINT 30 if (*edi=='SICE'|*edi=='SIWV')
BPX KERNEL32!ORD_0001 if *edi=='SICE'|*edi=='SIWV' ; will break 3 times :-(
-Much faster:
BPX VMM_GetDDBList if eax->3=='SICE'|eax->3=='SIWV'
Note also that some programs (like AZPR3.00) use de old 16-bit _lopen
function to do the same job:
This trick is similar to int41h/4fh Debugger installation check (code 05
& 06) but very limited because it's only available for Win95/98 (not NT)
as it uses the VxDCall backdoor. This detection was found in Bleem Demo.
push 0000004fh ; function 4fh
push 002a002ah ; high word specifies which VxD (VWIN32)
; low word specifies which service
(VWIN32_Int41Dispatch)
call Kernel32!ORD_001 ; VxdCall
cmp ax, 0f386h ; magic number returned by system debuggers
jz SoftICE_detected
Here again, several ways to detect it:
BPINT 41 if ax==4f
BPINT 30 if ax==0xF386 ; SoftICE must be loaded for this one
BPX Exec_PM_Int if eax==41 && edx->1c==4f && edx->10==002A002A
BPX Kernel32!ord_0001 if esp->4==002A002A && esp->8==4f ; slooooow!
Not a real method of detection, but a good way to know if SoftICE is
installed on a computer and to locate its installation directory.
It is used by few softs which access the following registry keys (usually #2) :
Note that some nasty apps could then erase all files from SoftICE directory
(I faced that once :-(
As for the MeltICE trick, FrogsICE will return both the address of the
registry key string data reference inside your program and the call to RegOpenKeyExA+1
instruction.
Useful breakpoint to detect it:
BPX _regopenkey if *(esp->8+0x13)=='tICE'|*(esp->8+0x37)=='tICE'
This code is returned when an app tries to detect FrogsICE VxD via a call
to CreateFileA.
Method used and returned values are the same as for the MeltICE detection.
The only difference is that FrogsICE will always fool the app to avoid a crash
(FrogsICE would hook itself :-(
Returned when FrogsICE hooked any write attempt/modification to the IDT.
This part prevent any app to fool FrogsICE by modifying the int01 vector
inside the IDT and then freely checking the Debug Registers.
FrogsICE will always avoid any attempt.
Returned when FrogsICE hooked a call to VMM 'Test_Debug_Installed' service.
As the name says, its purpose is to determines whether a debugger is running
on your system (ring0 only).
VMMCall Test_Debug_Installed
je not_installed
This service just checks a flag.
Frog's Print April 2000
КАК защититься от SoftIce маза-фака-щеет.22.08.01 12:08 Автор: myrmidon Статус: Незарегистрированный пользователь
Есть такая прога, вроде PEcrypt, она криптует РЕ эгзешники и ещо можно замутить с помощью ней антидебиггерные функции, сам пробывал, при загруженном софтайсе прога, обработанная этим PEcrypt'ором просто показывала мессагу что в системе запущен софтайс или ещо чтото, и незапускалась
А какой смысл защищаться от дебугера?23.08.01 04:31 Автор: Zef <Alloo Zef> Статус: Elderman
Не одним, так другим средством оттрейсят, есть в конце-концов IDA и др. декомпилеры... Если прога дорогая - то самый лучший способ - шифровка проги и данных ключом, который генерится на основе подлинных паспортных данных покупателя. Ключ вводится каждый раз при запуске, а прога и данные декриптуются пофрагментно, по мере использования. Если пароль "вышел в тираж", то по имени будет ясно, кто его распустил. Но для мелких дешевых прог такой способ не годится - слишком геморно для юзера.
В шароваре я делаю так: пароль генерится на основе инициалов с креды, но вводится единожды, при инсталляции (это, конечно не гарантирует от покупки по 3.14зженной креде, но против етого никак не поборешься...). Хранится он в реестре, в зашифрованном виде, чтобы соседи не сперли, но особенно его прятять нет смысла, т.к. любые ф-ции чтения данных (из реестра, с диска) вычисляются элементарно. Затем, (Главная проблема!) загрузив пароль для проверки при очередном запуске проги, нужно так его спрятать в памяти, чтобы нельзя было найти, когда его будешь проверять (вот тут, я и сам с удовольствием бы поучился!). Беда в том, что если пароль хранится в памяти, то всегда можно поставить БПТ на эту ячейку, и таким образом найти фрагмент, где он пережевывается дальше. Я выкручиваюсь таким способом: Сохраняю его с помощью одной ф-ции АПИ, а читаю другой, для этого не предназначенной, используемой левым способом, так, чтобы найти все это нуно трейсить саму Вынь; но таких пар ф-ций очень мало, по етому, как конкретно я это делаю, разглашать не буду, ищи аналогичную пару сам...
А какой смысл защищаться от дебугера?23.08.01 19:39 Автор: zelych Статус: Member
> Не одним, так другим средством оттрейсят [skip..]
вот-вот.. а можне ещё и через JTAG, в этом случае вообще ничего не поможет.. (разве что прогу написать весьма мутно и длинно, чтобы крацкеру не охота было в этом ковыряться)
А какой смысл защищаться от дебугера?23.08.01 11:37 Автор: Glory <Mr. Glory> Статус: Elderman
> Затем, (Главная проблема!) загрузив пароль для проверки при > очередном запуске проги, нужно так его спрятать в памяти, > чтобы нельзя было найти, когда его будешь проверять (вот > тут, я и сам с удовольствием бы поучился!). Беда в том, что > если пароль хранится в памяти, то всегда можно поставить > БПТ на эту ячейку, и таким образом найти фрагмент, где он > пережевывается дальше. А зачем пароль прятать то. Раз в реестре он храниться в хешированном виде - так и сверять в программе не пароли а хеши надо. Один хеш - пароль, а второй - генерится на основе юзерских данных. А шифрануть можно каким-нить сильным алгоритмом - напр. тем же ГОСТом - вернее модифицировать его под свои нужды.
А какой смысл защищаться от дебугера?23.08.01 05:14 Автор: Улыбка Статус: Незарегистрированный пользователь
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
