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?