Negative Starting Address of the First Audio Track
Invalid File Sizes
By the time of the arrival of monochrome terminals and 133" diskettes [i] , there was already an ugly, but very easy protection technique to prevent media from being copied at the file level. By means of changing file structures, protection developers could ruin a diskette to that point that working with it was only possible provided that the introduced changes were taken into account. The protection program, being aware of the file-system errors, could operate with it without encountering any problems. Standard OS built-in utilities, on the other hand, failed to do so. Note that, at that time, there were not yet widely available hacking copiers
For instance, the protection often consisted of several files referring to common clusters. In this case, writing data into the same file resulted in their immediate appearance in another, which the protection mechanism could use to achieve its purposes. Naturally, after copying the files to another disk, the common clusters were written to different locations and the cunning mechanism of implicit data exchange ceased to operate. The protected program also ceased to operate. This, of course, only happened provided that the user managed to copy the disc contents at all Copying files with overlapping clusters resulted in their multiple replication in each copied file. Because of this, the file size grew to such an extent that the capacity of the entire hard disk was insufficient to store it! If the last cluster of the file happened to be glued to its starting point (i.e., the file got looped), both its size and the time required for its copying immediately became infinite Naturally, disk doctors were already available by that time, but they failed to produce the desired result, since correction of the file system rendered the protection system unusable (for example, in the aboveconsidered case with the file looping, if the protection relied on the fact that the file start follows after its end, this technique became inapplicable after processing the disc with the disc doctor utility, with all the resulting consequences).
The file systems of CDs, naturally, are very different from those used on diskettes. The general principles of introducing errors, however, are very similar. By increasing the fictitious lengths of the protected files ten times or more, the developer of a protection mechanism can raise their total size up to hundreds of gigabytes. Thus, in order to copy a protected disc, you d need a stack of DVDs or a large hard drive. A protection mechanism that remembers the original lengths of all files can operate with them without encountering any problems. However, most file copiers won t understand this humor, and, consequently, will go crazy.
Going outside of the file limits, in principle, shouldn t cause any problems. CD file systems are very easy. CDs do not support file fragmentation, and, consequently, don t require FAT. All files take a continuous sequence of sectors, and only the two most important characteristics are related to any file: the number of the first sector of the file specified in the LBA (Logical Block Address) format and its length, specified in bytes. All other attributes, such as file name and its creation time, are of no importance, because we are currently speaking only about sectors.
An increase in the file length results in the capturing of a number of sectors adjacent to its tail. Provided that the number of the last sector belonging to the file doesn t exceed the number of the last sector of the disc, file copying, in principle, will be carried out normally. By in principle we mean that all of the other files that are encountered in the copying process will be included into the copy. If the number of the last sector of our file goes beyond the limits of the disc, the CD-ROM drive reports an error and stops reading. Standard copiers built into the operating system, as well as most third-party tools, automatically remove the tail of the incompletely copied file from the disk. As a result, the user achieves no result at all. Of course, it isn t too difficult to write a custom copier . However, how do we know what number of bytes we actually need to copy? How can we determine where the useful information is and where the over-end garbage begins? This is exactly the problem that we are now going to solve!
However, not everyone has CDs protected using this method. Therefore, we are going to create one right now! Let s take any unprotected disc and protect it on our own (the title of this book is, after all, Protecting against Unsanctioned CD Copying, not Protection cracking ). The first task we must accomplish is obtaining an image of the disc that we are going to protect. The best way of doing this is using Roxio Easy CD Creator or any other similar program. Clone CD is not suitable here, since it refuses to carry out short sector read (i.e., user data only) and always processes entire sectors by forcibly adding the checksum and error-correction codes to the end of each sector. As a result, none of our manipulations will produce any effect. They will, on the contrary, be corrected automatically on the fly by the drive s firmware. It is possible, of course, to compute a new checksum and error-correction codes after entering the required changes, but why complicate our life unnecessarily? If you do not have Easy CD Creator, take Alcohol 120%, and choose the Standard ISO images option.
OK, now let s assume that the CD image has been successfully saved in the trask.iso file, with which we are going to work now. Open this file using HIEW or any other HEX editor and find the sector that contains the TOC. A pretty business! How can we find it? To do so, we need at least to view the Joliet/ISO-9660 file system specification or exert a bit of mental effort. Since the file size is specified in bytes, not in sectors (it just can t be specified in sectors, file systems that measure files in blocks became obsolete long time ago), then we can find the required field using a trivial context search. Choose the file the length of which we are going to measure, and convert it to a hex. For instance, let it be the file named 01 ”Personal Jesus.mp3 having the length of 3,591,523 bytes. In hex notation, taking into account the inverse byte order, this value will appear as follows: 63 CD 36 00 . Press <F7> and enter the sequence that we are looking for
| |
| |
| |
| |
The desired value is actually present in the disc image. In fact, there are not one, or even two, but four such occurrences! No, this isn t some kind of devilry ”in fact, this is how it should be. Contemporary CDs contain two file systems: one of them, ISO-9660 , is written to the disc exclusively for compatibility with obsolete software, limiting the maximum length of a file name to 11 characters (eight for the name itself, and the remaining three for the filename extension). Contemporary software operates with more advanced file systems, including Joliet, developed by Microsoft. If you think that all we need now is Romeo, strangely enough, there is a file system by that name! It was developed by Adaptec, but, unfortunately , didn t become widespread and passed away quite soon. Joliet, therefore, will remain alone.
Enough of romance, let s get back to business. Generally, it isn t necessary to worry about synchronization of the two file systems, because Windows sees only Joliet and ignores ISO-9660 , while MS-DOS does exactly the opposite . Therefore, if we increase the file length in Joliet, but forget about doing the same in ISO-9660 (this is the particular trick that some developers of protection mechanisms play), Windows will never even have a shadow of suspicion that some deception is taking place. However, the question is different with hackers! The original length of files left without changes in ISO-9660 will considerably simplify the task of the cracker. Consequently, it isn t recommended to leave them as they are! Besides this, there are several drivers that allow you to manually choose, which of the two file systems you wish to mount. Don t be lazy, therefore, and correct both values simultaneously by changing the two most significant bytes from 36 00 to FF 66 (you may, of course, prefer another value). When doing this, pay special attention to the double word 00 36 CD 63 . This also is the file length, written, however, in the inverse order, which is unnatural for IBM PC. Here, the least significant byte is located at the higher address. The address of the starting sector of the file is also written in two variants. Such a scheme of information representation has obviously been chosen on the basis of considerations of compatibility. Every platform is free to choose the byte order that is natural for it. There is no guarantee, however, that Windows will choose the less significant byte by lower address variant. Everything depends on the file system driver, which, in turn , depending on the specific features of its implementation, can work with any of these two fields. Therefore, both fields must always be coordinated.
Now the modified (I mean, invalidated) ISO image can be burnt onto a CD-R/CD-RW or mounted to a virtual CD drive (for this purpose, you ll need Alcohol 120% or any similar program). Issue the dir command, and you ll see the following:
| |
> dir N:\Depeche Mode Volume in drive N has label 030706_2038 Volume serial number is 61A1-A7EE Directory of N:\Depeche Mode 06.07.2003 21:56 <DIR> . 06.07.2003 21:56 <DIR> .. 01.01.1601 04:00 1 728 040 291 01 - Personal Jesus.mp3 30.06.2003 00:11 3 574 805 02 - See You.mp3 30.06.2003 00:12 3 472 405 03 - Strangerlove.mp3 30.06.2003 00:12 3 718 165 04 - Enjoy The Silence.mp3 30.06.2003 00:13 2 956 643 05 - The Meaning Of Love.mp3 30.06.2003 00:14 3 820 565 06 - Master and Servant.mp3 30.06.2003 00:15 3 066 149 07 - Never Let Me Down Again.mp3 30.06.2003 00:16 3 806 772 08 - Its Called a Heart.mp3 30.06.2003 00:16 3 813 460 09 - Little 15.mp3 30.06.2003 00:17 3 574 805 10 - Everything Counts.mp3 30.06.2003 00:18 3 687 236 11 - People Are People.mp3 30.06.2003 00:19 4 916 036 12 - The Thing You Said.mpS 30.06.2003 00:20 4 182 100 13 - Agent Orange.mp3 30.06.2003 00:21 4 585 012 14 - World in my Eyes.mpS 30.06.2003 00:22 3 646 276 15 - Behind The Wheel.mp3 30.06.2003 00:22 3 049 012 16 - Black Celebration (live).mp3 30.06.2003 00:23 3 800 085 17 - Nothing.mp3 30.06.2003 00:25 7 151 700 18 - Bonus (unnamed).mp3 18 files 1 794 861 517 bytes 2 folders 0 bytes free | |
Well! The file size has increased to 1,728,040,291 bytes (see the string highlighted in bold), which is more than twice the volume of the entire CD. And they have the gall to say that one part cannot be larger than the whole! Naturally, any attempt to copy this file to the hard disk will fail. Therefore, we must look for a way to bypass this. Let s focus on the fact that files on the CD are placed sequentially, which means that the last sector of the current file is directly followed by the starting sector of the next file. Because we know the starting sectors of all files, determining the position of the terminating sectors, except for the last, shouldn t present any problem.
Let s copy the ISO image of the protected disc into a file and consider its directory once again:
| |
| |
The smallest number of the file s starting sector, after sector 0191h , is 086Bh . Thus, the 01 ”Personal Jesus.mp3 file cannot contain more than 086Bh ˆ’ 0191h == 6DAh sectors or 1754 * 2048 == 3,592,192 bytes. Naturally, this is a somewhat excessive value, and the actual file is 1.5 K shorter. This difference, however, is already of no importance. Most multimedia files will be processed correctly, even with the presence of a certain amount of irrelevant garbage at the tail. Having corrected the file image, let s write it to the disc or simply shorten the file to the required length using any available program, such as Pinch of file.
What should you do if you are not satisfied with such a low level of reliability from this protection? There is, in fact, something that can be done. For example, it is possible to reduce the numbers of starting sectors of several files, which allows you to kill two birds with one stone. First, the file with an incorrectly specified sector definitely won t be processed correctly by an associated application (which isn t surprising, since after this kind of manipulation, the actual starting point of the file will be somewhere in its middle). Second, the algorithm used to determine original file lengths from the difference of the neighboring starting sector addresses is sure to produce an incorrect result, according to which the restored file will be cut off.
A protection mechanism that knows the actual offset of the file s starting sector in relation to its real starting point must either shift the file pointer by means of calling the SetFilePointer function or swallow the garbage data using the ReadFile function. Both methods are equally effective, and each of them has its strong and weak points. SetFilePointer operates considerably faster. However, it is easily recognizable ( especially to hackers). When encountering the ReadFile call, on the contrary, it is necessary to find out what kind of data it actually reads ”useful information or simply garbage.
Let s study how the cracking process appears in practice. Writing a fully functional MP3 player just for the sake of illustration isn t a rational approach (besides which, it would take a lot of space). Therefore, all of the data processing in this demo example consists of displaying the original file contents on the screen. Before starting this program the first time, the starting sector number of the protected file must be decreased by the _NSEC_ value, and the size must be increased by at least 2048*_NSEC_ bytes. There is no limitation on the maximum length (which means that you can use all 32 bits of the length field).
| |
/*--------------------------------------------------------------------------- * * crack me 27AF7A2D * ================= * * A demo example illustrating the processing of files with an intentionally * decreased number for the starting sector and an increased length; positioning of the file * pointer is carried out by a call to the fseek function, therefore this crackme * is very easy to crack. * * Build 0x001 @ 02.07.2003 --------------------------------------------------------------------------------*/ #include <stdio.h> // Program settings // =================== // Name of the file to be opened // If protection resides on the CD, then there is no need to specify // full pathname. #define _FN_ "M: \Depeche Mode\01 - Personal Jesus. mp3" // The number of sectors by which the starting point of the file is offset #define _NSEC_ 4 // Original file size #define _FSIZ_ 3591523 // User data size #define SECTOR_SIZE 2048 // Screen width in characters (needed to display a dump) #define _SCREEN_LEN_80 // Size of the block being processed #define BLOCK_SIZE 0x666 // Finding the minimum of two numbers #define _MIN(a,b) ((a<b)?a:b) // DISPLAYING HEX DUMP //-------------------------- // src - Pointer to the data being output // n - Number of bytes displayed on the screen print_hex (unsigned char *src, int n) { int a; static p=1; for (a=1; a <= n; a++) printf ("%02x%s", src[a-1], (p++% (_SCREEN_LEN_/31)) ? " ":"\n"); } main () { int a; FILE *f; long p=_FSIZ_; char buf [BLOCK_SIZE]; // TITLE fprintf (stderr, "crackme 27af7a2d by Kris Kaspersky\n"); // Trying to open the file if ((f = fopen(_FN_, "rb")) == 0) { fprintf (stderr, "-ERR: can not open %s\n",_FN_); return -1; } // Skipping _NSEC_ extra sectors in the beginning of the file fseek (f, _NSEC_*SECTOR_SIZE, SEEK_SET); // Reading file by blocks, taking care that we dont go // beyond the limits of its original size while(p) { // Attention: Dont use the fgetc function for processing files with an // incorrect size, since in most of implementations // this function processes files in blocks instead of bytes. // Block size isnt known beforehand. This means that // the fgetc function carries out transparent input buffering, // based on the specified file size as a reference. // If this value is incorrect, there is no guarantee // that the fgetc function will remain within the disc size limits. // The consequences of the function's going beyond these limits // are unpredictable (this is particularly probable // if the file being processed is the last file on the CD) . // Therefore, use fread, or better still, ReadFile, // which certainly won't end up running ahead of the hounds. // Reading the next block fread(buf, 1, a = _MIN(p,BLOCK_SIZE), f); print_hex (buf,a); p= a // Displaying it on the screen } } | |
Having discovered that the main file attributes are incorrect (which means that this file is unreadable), the hacker will certainly want to determine the offset of the first actual byte and original file size.
| |
:bpx CreateFileA ; Set the breakpoint to CreateFileA :x ; Exit the Ice Break due to BPX KERNEL32!CreateFileA (ET=3.37 seconds) ; The debugger pops up, which means that someone has called the CreateFileA function. ; But who ? Lets try to determine this by the name of the opened file. :d esp->4 ; Viewing the first argument passed to the function 0010:00407060 4D 3A 5C 44 65 70 65 6368 65 20 4D 6F 64 65 5C M:\Depeche Mode\ 0010:00407070 30 31 20 2D 20 50 65 7273 6F 6E 61 6C 20 4A 65 01 - Personal Je 0010:00407080 73 75 73 2E 6D 70 33 004D 3A 5C 44 65 70 65 63 sus.mp3. M:\Depec ; Thats it! It is exactly what we need! :p ret ; Exiting the function :? eax ; Viewing the value of the file descriptor 00000030 0000000048 "0" ; The descriptor is 0x30 (or 48 in decimal notation). :bpx SetFilePointer if (esp->4 == 0x30); :bpx ReadFile if (esp->4 == 0x30) ; Setting the breakpoints to the main file functions, SetFilePointer and ReadFile, ; thus making the debugger show up only when "our" descriptor is passed to these ; functions (special note for developers of protection mechanisms: ladies and gentlemen, ; dont let the hackers to deceive you so easily! Open the file several times ; and work with it using various descriptors, changing them from time to time, ; as this will seriously complicate the analysis) :x ; Exiting the debugger Break due to BPX KERNEL32!SetFilePointer IF ((ESP->4)==0x30) (ET=76.19 microseconds) ; This was our breakpoint set to the SetFilePointer function, now we need to view ; the offset value, by which the pointer has been shifted, ; and the originto determine, ; in relation to which part of the file the count is carried out. :? esp->8 ; Viewing the second argument of the function 00002000 0000008192 " " ; The pointer is moved 0x2000 bytes from... :? esp->0C ; Viewing the third argument of the function 00000000 0000000000 " " ; the starting point of the file (SEEK_SET) :p ret ; Exiting the debugger ; The SetFilePointer function isnt called any more. However, ; there are multiple calls to the ReadFile function. ; We wont issue the P RET command for analysis of the protection code ; (in contrast to some hacking recommendations). After all, ReadFile ; is most likely called from some library wrapper, instead of direct calls, ; and analysis of this wrapper is unlikely to produce any valuable result. ; Instead of this, let us view the calls stack :stack ; Viewing the calls stack 12F8C8 401E1C KERNEL32!ReadFile 12F8F8 4010E5 crackme!.text+0E1C 12FFC0 77E87903crackme!.text+00E5 12FFF0 0 KERNEL32!SetUnhandledExceptionFilter+005C ; Obviously, the address 55E87903h belongs to some OS internals. ; Therefore, it is of no interest to us, as well as address 401E1Ch ; (the return address from ReadFile), ; since as was already mentioned before, it is most likely that it belongs to some ; library wrapper. As relates to the address 4010E5h, it is worth investigating: : u 4010E5 001B:00401072 mov edi, 36CD63 ; EDI := 36CD63 001B:004010C8 cmp edi, 00000666 ; \ (1) 001B:004010CE mov esi, edi ; + ESI := _min(0x666, EDI) 001B:004010D0 j1 004010D7 ; + 001B:004010D2 mov esi, 00000666 ; / 001B:004010D7 push ebx ; 001B:004010D8 push esi ; Number of elements being read 001B:004010D9 lea eax, [esp+14] ; Getting the pointer to a buffer 001B:004010DD push 01 ; Size of a single element 001B:004010DF push eax ; Passing the pointer to buffer 001B:004010E0 call 00401141 ; This function calls ReadFile 001B:004010E5 lea ecx, [esp+1C] ; Getting the pointer to the buffer 001B:004010E9 push esi ; 001B:004010EA push ecx ; 001B:004010EB call 00401000 ; Processing the data that has been read 001B:004010F0 add esp, 18 ; Removing unneeded arguments from the stack 001B:004010F3 sub edi, esi ; EDI := EDI _min(0x666, EDI) 001B:004010F5 jnz 004010C8 ; Looping, until there is anything to process 001B:004010F7 pop esi ; ... ; Studying the environment of the 4010E5 address allows us ; to restore the file processing algorithm in a matter of seconds. ; The file is being read in 0x666-byte blocks ; until there are exactly 0x36CD63 (or 3,591,523 in decimal notation)
| |
Thus, after the file is opened, its pointer is moved 0x2000 bytes (4 sectors) forward, then 3,591,523 data bytes are read, after which its processing stops. Consequently, it is possible to restore the protected file as follows
Try to play it using any available MP3 player. If everything was done correctly, you ll enjoy the Depeche Mode no longer spoiled by any protection mechanism! By the way, this music is especially suitable as background music to make the work of improving protection mechanisms more pleasant. In fact, there are a lot of things that need improvement!
Cunning processing of protected files assumes the use of at least three descriptors for each file: two are actually used for data processing, while the third descriptor dances wildly over the entire file, reading senseless garbage. This garbage is passed to a bulky and horribly complicated procedure that carries out sophisticated computations , which are never used in practice. Feeding this procedure by the first _NSEC_ sectors of the protected file, we ll create a false impression that file processing begins from the start of the file (well, practically from the start, because protection developers can easily move the pointer to whatever position he or she likes).
Descriptors that are actually used must be opened after returning a false one, since most crackers trace only the first call to CreateFileA , which opens the specified file, ignoring all further calls to that function. Actually, most crackers don t even guess that the same file can be opened more than once.
For positioning on the first byte of the useful data, it is better to read the garbage and imitate its processing instead of calling the SetFilePointer function. In a welldesigned protection mechanism, it is very difficult to determine where the garbage ends and the actual data begins. However, the implementation of such a protection is very difficult (and remember that along with implementing the code, you ll have to debug it). Therefore, for simplicity s sake, it is possible to limit the protection by ensuring that the starting point of useful data coincides with the first byte of the next block being read.
It is extremely undesirable to store the original file length in the form of a constant, because all constants are immediately revealed in the course of analysis. In fact, the required value can quickly be found by using the brute force approach. This is because in most programs, there aren t too many constants with values comparable with the lengths of files being processed. Therefore, instead of file length, it is recommended to store the length of its tail , i.e., the remainder from the division of the original length by the size of processed blocks. Naturally, block size and the number of blocks also must be stored somewhere, but analysis of the relationship between three constants is much more difficult than finding a single constant!
Taking into account all of the above-mentioned considerations, we can improve our protection mechanism significantly. One of the possible variants of its implementation could appear as follows:
| |
// Size of the "tail" of the last block #define TAIL_SIZE (_FSIZ_ % BLOCK_SIZE) // Number of whole blocks #define N_BLOCKS (_FSIZ_ / BLOCK_SIZE /2) // FALSE DATA PROCESSING // ------------------------ // It is best to make this function as bulky and complicated // as possible, so that its activities (thrashing, in fact) // wont be self-evident. thrashing (unsigned char *src, int n) { int a, sum = 0;for (a = 0; a< n; a++) sum += src[a]; return sum; } main () { int a = 0; long p = _FSIZ_; FILE *f_even, *f_uneven, *f_thrashing; char buf [BLOCK_SIZE + (_NSEC_*SECTOR_SIZE)]; // TITLE fprintf (stderr, "crackme 27af7a2d by Kris Kaspersky\n"); // Trying to open the file // The best practice is to open f_thrashing first, because // the first call to CreateFileA encountered by a cracker // must return a "false" descriptor. if (((f_thrashing = fopen(_FN_, "rb")) == 0) ((f_even = fopen(_FN_, "rb")) ==0) ((f_uneven= fopen(_FN_, rb)) == 0)) {fprintf (stderr, "-ERR: cannot open %s\n",_FN_); return -1;} // Setting f_even fread (buf, 1, _NSEC_*SECTOR_SIZE, f_even); // Imitating the skipping of NSEC*SECOR_SIZE/2 bytes // (hoping that this will deceive the cracker) // Actually, all NSEC*SECTOR_SIZE starting bytes of // the file go to dev/null thrashing (buf + _NSEC_*SECTOR_SIZE/2,_NSEC_*SECTOR_SIZE/2); // Setting f_uneven fread (buf, 1, _NSEC_*SECTOR_SIZE+BLOCK_SIZE, f_uneven); // Imitating the skipping of NSEC*SECOR_SIZE/3 bytes thrashing (buf + _NSEC_*SECTOR_SIZE/3, 2*_NSEC_*SECTOR_SIZE/3+BLOCK_SIZE); // Setting thrashing, thus directing the cracker by false trace fseek (f_thrashing,_NSEC_*SECTOR_SIZE/4, SEEK_SET); // Reading the file in blocks, making sure that we do not go // beyond the limits of its original size for (a=0; a < N_BLOCKS; a++) { // Reading trash data fread (buf, 1, BLOCK_SIZE, f_thrashing); threshing (buf, BLOCK_SIZE); // Reading the even block with actual data fread (buf, 1, BLOCK_SIZE, f_even); print_hex (buf,BLOCK_SIZE); // Skipping uneven block for f_even descriptor fread (buf, 1, BLOCK_SIZE, f_even); threshing (buf,BLOCK_SIZE); // Reading uneven block of actual data fread (buf, 1, BLOCK_SIZE, f _uneven); print_hex (buf, BLOCK_SIZE); // Skipping the even block for f_uneneven descriptor fread (buf, 1, BLOCK_SIZE, f_uneven); threshing (buf,BLOCK_SIZE); } // Reading the tail fread (buf, 1, TAIL_SIZE, f_even); print_hex (buf, TAIL_SIZE); } | |
Try to crack this protection. Did you succeed? An attempt at tracing calls to SetFilePoiner and ReadFile functions doesn t produce any result, because the manner of data read is highly non-linear, and there is no efficient method to distinguish trash from useful data quickly. These protection mechanisms shouldn t be cracked using only a debugger. In this case, you ll require a disassembler. Not even this, however, will guarantee that you ll succeed quickly. The complexity and intricacies of the data processing algorithm considerably complicate program analysis. With regard to determining the actual boundaries of the protected file, even professionals might end up spending several hours (or sometimes even days ). Because of the space limitations, disassembled listings and a description of the cracking process won t be provided in this book. They don t, in fact, contain anything interesting ”just routine operations. The only clue in this case is the thrashing function that imitates the data processing. As soon as the hacker understands that the results of its operation are not used by the program in any way, he or she will have made a considerable advance in cracking activities. Breakpoints set to memory read/write operations will allow him or her to quickly and elegantly determine if specified memory cells are actually accessed. In other words, there are no secrets that cannot be revealed using Soft-Ice and IDA
[i] No, this is not a joke or misprint. Such diskettes actually existed before even the earliest 8 diskettes designed by IBM in 1971. They were so large that not every door was wide enough to let the programmer carrying such a diskette easily go through it. I cannot exactly recall their capacity, but this was something about several tens of Kilobytes. The most interesting fact about it is that they already contained a file system, although the concept of files was non-existent by that time
EAN: 2147483647
Pages: 60