DartPro 32 Cracking 'save' with encryption mechanism	Not Assigned
03 April 98	by Entropy
	Courtesy of Fravia's page of reverse engineering	slightly edited by fravia+
fra_00xx 980403 Entropy 0100 NA PC	A good work: precise to the point, and well-explaining a widespread protection scheme, which is a simple matter, sure... only once you have read this :-) Good reversers can only be judged by what they write and publish, what they "say" does not mean anything: any idiot could make out of this a ready-chewed patching program for the lusers out there, bragging merits he doesn't deserve... yet a good reverser will mostly propose means to IMPROVE the protection of the target he has cracked. That is what makes all the difference between +crackers and lesser crackers, between people that teach a lot (and could not care less about bragging), and people that brag (and lurk) a lot (and wouldn't probably have anything to teach anyway).
	There is a crack, a crack in everything That's how the light gets in
Rating	( )Beginner (x)Intermediate ( )Advanced ( )Expert

This demo of DartPro is crippled version of the original. Due to how the 

program is structured it needs to save the audio output to a file in order 

the process it recursively. The crippling was made by scrambling this 

output, so that they couldn't be used for anything else. This was very 

appealing because I never had the chance to decypher anything and the reward 

would be a fully functional version.

  This demo has mainly two limitations:

	  - doesn't let you use waves with more than 2 min of duration

	  - generated waves are scrambled

  

  Let's focus on the last one. For deciphering the scrambled code we create a

  wave file whose samples are a sequence from 0000h to 0FFFFh and then apply a

  nondestructive audio process, e.g. the DeClicker. Our generated file is smooth 

  except when crosses 7FFFh to 8000h, but that won't be a problem.

  

  Analyzing both waves - by making a text listing containing both waves

  side-by-side in decimal and binary representation:

  

      0 0000000000000000 30531 0111011101000011

      1 0000000000000001 30530 0111011101000010

      2 0000000000000010 30529 0111011101000001

      3 0000000000000011 30528 0111011101000000

      4 0000000000000100 30535 0111011101000111

      5 0000000000000101 30534 0111011101000110

      6 0000000000000110 30533 0111011101000101

      7 0000000000000111 30532 0111011101000100

      8 0000000000001000 28489 0110111101001001

      9 0000000000001001 28488 0110111101001000

     10 0000000000001010 28491 0110111101001011

     11 0000000000001011 28490 0110111101001010

     12 0000000000001100 28493 0110111101001101

     13 0000000000001101 28492 0110111101001100

     14 0000000000001110 28495 0110111101001111

     15 0000000000001111 28494 0110111101001110

     16 0000000000010000 13650 0011010101010010

     17 0000000000010001 13651 0011010101010011

     18 0000000000010010 13648 0011010101010000

     19 0000000000010011 13649 0011010101010001

     20 0000000000010100 13654 0011010101010110

     21 0000000000010101 13655 0011010101010111

     22 0000000000010110 13652 0011010101010100

     23 0000000000010111 13653 0011010101010101

     24 0000000000011000 29534 0111001101011110

     25 0000000000011001 29535 0111001101011111

     26 0000000000011010 29532 0111001101011100

     27 0000000000011011 29533 0111001101011101

     28 0000000000011100 29530 0111001101011010

     29 0000000000011101 29531 0111001101011011

     30 0000000000011110 29528 0111001101011000

     31 0000000000011111 29529 0111001101011001

     32 0000000000100000 13606 0011010100100110

                               ^       ^ ^^^

                       ...



  We can notice that [with the whole list]:

	  - some bits are left unchanged

	  - the scrambling is self-inverse, i.e. T[T(n)] = n

  This tell us a lot because the aren't many operations made to a number that

  have this properties - mainly exclusive OR (XOR) and rotation (ROL, ROR).

  So we compare pairs of numbers that differ only on a bit and see what bits

  depended of it and changed.



         Original                 Scrambled                XOR 30351

  ==================================================================

      0     0000000000000000   30531 0111011101000011   ----------------

      1     0000000000000001   30530 0111011101000010   0000000000000001

      2     0000000000000010   30529 0111011101000001   0000000000000010

      4     0000000000000100   30535 0111011101000111   0000000000000100

      8     0000000000001000   28489 0110111101001001   0001100000001010 <- Only these

      16    0000000000010000   13650 0011010101010010   0100001000010001 <- change

      32    0000000000100000   13606 0011010100100110   0100001001100101 <- the others

      64    0000000001000000   30467 0111011100000011   0000000001000000

      128   0000000010000000   30659 0111011111000011   0000000010000000

      256   0000000100000000   30275 0111011001000011   0000000100000000

      512   0000001000000000   30019 0111010101000011   0000001000000000

      1024  0000010000000000   29507 0111001101000011   0000010000000000

      2048  0000100000000000   32579 0111111101000011   0000100000000000

      4096  0001000000000000   26435 0110011101000011   0001000000000000

      8192  0010000000000000   22339 0101011101000011   0010000000000000

      16384 0100000000000000   14147 0011011101000011   0100000000000000

      32768 1000000000000000   63299 1111011101000011   1000000000000000



  This didn't work, at least, not completely, but showed the way out: bits 4-6

  are used too peek from a table value to XOR on the number.

  

      Original                 Scrambled          Table (HEX)

   ==========================================================

      0 0000000000000000   30531 0111011101000011	7743

      8 0000000000001000   28489 0110111101000001	6F41

     16 0000000000010000   13650 0011010101000010	3542

     24 0000000000011000   29534 0111001101000110	7346

     32 0000000000100000   13606 0011010100000110	3506

     40 0000000000101000   24680 0110000001000000	6040

     48 0000000000110000   19249 0100101100000001	4B01

     56 0000000000111000   17531 0100010001000011	4443

                  ^^^



   However the search of these table in the DART32DM.EXE was unsuccessful. To

   pinpoint the code "I've.class" tppabs="http://fravia.org/I've.class" used a conditional breakpoint on memory access of the

   .text segment, if the value in AX was 7743h:

   

     BPX CS:401000 CS:4E2A00 R IF AX==7743

   

   This didn't pinpoint the scrambler code but showed were was a memory

   buffer. The breakpointing of it did the trick.

   

	0049BFA9       mov     bx, [edx]		; buffer input

	0049BFAC       add     edx, 2

	0049BFAF       mov     ecx, ebx

	0049BFB1       mov     [esp+10h+arg_0], ecx

	0049BFB5       shr     ecx, 3			; filtering of the bits 4-6...

	0049BFB8       and     ecx, 7

	0049BFBB       mov     ax, 00509504[ecx*2]    ; ...for table lookup

	0049BFC3       xor     word ptr [esp+10h+arg_0], ax	; the XOR itself

	0049BFC8       mov     cl, byte ptr [esp+10h+arg_0]

	0049BFCC       mov     eax, [esp+10h+arg_0]

	0049BFD0       xor     cl, bl

	0049BFD2       and     ecx, 38h		; reversing the effect of XORing...

	0049BFD5       xor     ecx, eax		; ...the bits 4-6

	0049BFD7       inc     ebp

	0049BFD8       mov     [edx-2], cx		: buffer ouput

   

   The reason why the table wasn't found in the first place was because the 4-6

   bits hadn't been masked out yet. This is because this same table is also used 

   in another place for scrambling the 8 bits samples. All this was fixed by 

   filling the table with zeros.

   

   Another problem was the WAV header that had a non-standard encoding format

   instead of the PCM. This was fixed searching for cross-references of the 'fmt '

   string found in the WAV header.

   

   The 2 min limitation was overcame with the usual breakpoint on the

   MessageBoxA and tracing the callers until a conditional jump over the code

   was found.

   

   The nag-screen was eliminated with one of the techniques teached by 

   +ORC, and that worked fine.

This encryption scheme wasn't so hard after all. But even this has a reason: if 

someone play the scrambled output would still ear some resemblancy with the original 

sound, and get that feeling that it was almost there. This might create an even 

deeper "need" to buy the program.

Some simple things that could be done to improve the encryption and that 

could make it harder to reverse engineering world be: previous output/input 

dependancie, or using a key that could be hidden in the file, e.g. a expression 

involving the size, date, CRC or other properties.

homepage links search_forms +ORC students' essays academy database
reality cracking how to search javascript wars
tools anonymity academy cocktails antismut CGI-scripts mail_fravia+
Is reverse engineering legal?