What if you burn your image? Same difference?
And what if you change the eax value to the one returned by the original cd?
Is it working then?

I never tried to trace the code with burned cd because it showed me the same error msg about not original CD so i made an image and then start working on the image.. i will check and trace the code with a burned CD and will show my results of debugging.

if i patch the eax value the application crash.

Hi all

I have just found out that some one in my contry has cracked the CD protection of a newer version of the application i'm trying to crack
i don't know if this new version is like my version that comes with 2 CDs
maybe this version came with 1 DVD.

he added a file that he called : appName.emu
and it's a binary file with this header :

well i check and there is an application that create a CD copy called GEAR SOFTWARE but i don't see anything spcial about this app.

the Cracker also patch the application so it will read from file .emu data when trying to boot from CD

does any one knows about this kind of CD protection that need to be cracked like so ?

and i don't understand how did he make this dump file and make the application read this when needed... (i don't have the original exe file of this new version so i can't compare it)

i have added the emu file that was added to crack this newer app

regards,
LaBBa.

Hi ALL
i got it now ... :D

when i load the original CD after it uses the DeviceIoControl API it read the section of the data it need for password of the DB files.
the section of that data was created with Gear Software and from some reason can't be copy by any of the applications that i used.

so i run the original CD and when i saw that it read the data from the section i have make a dump and saw the section data like the emu file had...

now all i needed to do is make a dump with olly as a binary copy and now i have my own emu file like in the new version that was cracked ...

all i need to do is to make a load to the binary file in run time and thats it.. i belive that the CD will be hacked soon..

tnx for the help..

PS:
the only question left is why any of the software i have used with all kind of profiles coudn't copy the password section that was created with GEAR SOFTWARE ????

because, as i told you in the other forum where you got help... the gear software only made the image, the image was adjusted after this when the glass mastering / mass production was done....

sort of like you have a door with a lock, and a key, i then replace the lock... so the key you have is useless... clear?

loud and clear i understand now how it work ...

i just wanted to know if the application that runs from the original CD can read the Locked/Key data why can't any of the image makers (alcohol,BlindWrite,CloneCD) create an image that will contains the data that the application needs ?
i also have a good CD Burners Plextor and LiteOn so i can't be blamed that i'm using lame hardware to make CD images.. :)

I had a similar experience with a Video CD sometime back : I could play it on the computer AND on VCD players but I couldn't copy it...I tried to image it using various tools like Alcohol,Blindwrite etc but the images or the burnt CDs never worked. There was no special protection either immediately apparent by reading the directory on the CD etc.
Finally I found out that it was installing a driver in the background on the first run when played back on the computer, and this driver was extracting the relevant bytes from the .dat file and sending it to the media player, thus allowing the movie to play but not to allow copying directly.
The VCD players (set-top) merely ignored the irrelevant data in the .dat file and played the movie seamlessly.
Finally I could copy the movie by extracting using IsoBuster with the option "Extract but filter only M2F2 mpeg frames" , and then by re-burning it to another cd.

I would like to add a comment on this statement by evlncrn8:
I would like to think i slightly different way... You have a room whose door is locked by a lock and you have the key...But this particular locked room is behind another door locked by a lock but whose key you don't have...Unless you open BOTH the locks you can't enter the room...I can liken the outer lock to the security measures put onto the CD Media at the time of mass production, sometimes on an individual basis...
Our imagers are able to see and read upto the level of the inner lock but can't emulate the outer lock or open it...The running application is probably programmed to look for the outer lock and then open it first...
I know the analogy is not exact but it fits to a certain extent I think...

I disagree with you. Running application has not more powerfull than Blinread, Alcohol, etc..., very very specialized burning soft a lot of years ago. If that app reads it, burning soft reads it too... Like I said in first post, take a view hidden rootkit,etc... Search original dump data in master cd and take note physical position. Edit ISO file and change bytes. IF you take this way, please send me where are data.
BTW: Gear soft has professional software for mastering machines & of course for burning home made.
Regards,

I realy want to do what you say but :
with what apps ?

again.. how do i search for the dump data that i have in the original CD so i will know it's position ??

sorry that i'm asking many questions but your requests are too general...

I agree with this but I want to mention that many cd drives and even some software incorporate Error Correction and sometimes ECC ( Error Correction Codes) with some redundant data (maybe in the form of PURPOSELY made unreadable sectors etc). So, sometimes the data may ALL be recoverable or an image can be made but the SECTOR TO SECTOR mapping may not be possible.
So its a VERY simple case wherein a prog can check whether a particular unreadable sector (of REDUNDANT data) is present on the CD or not. IF it is present, the prog runs. Else it exits or crashes. The Mass Burnt CDs can incorporate it. But our CD image, though it has ALL the data (and hence even the md5 checksum also maybe same in some cases), it still can't have the unreadable sectors etc ( I remember that alcohol etc can emulate bad sectors and sub-channel data, but still it sometimes fails...)

I believe that WinHex 11 and above can do the direct sector reading and dumping quite well (though I haven't used it for quite some time)

Also I believe you can download and use the Rootkit Unhooker from this site:

http://www.antirootkit.com/software/RootKit-Unhooker.htm

to search for any suspicious processes and remove any hidden toolkits.

TechLord has made my work... :D :D