Log in

View Full Version : sproQuery emulation


tom
October 29th, 2003, 21:28
Hi,

I'm quite new to cracking programs but i've read most of crack's tutorials and other stuff available on the net. After some time I succeded to crack most of the program but i'm having difficulties with one thing. The program is an mp3 player and we receive a new cd of mp3's every month. The mp3's are encrypted and the challenge is stored in the mp3, the response is suppose to come from the sproQuery command. The response is then used to decrypt the file. One advantage is that i haven't found any chalanges greater than 16 bits and the responses are 32bits. So it is possible to query all posibilities from the key and store them in a reasonable space (256K). I can't store this inside the program for the simple reason i dont have enough space for it. My idea is to store this data in a file and access it if necessary. I've written a routine and patched it into the program but softice and the current thread crash when OpenFileA is called. I'll attach the patch for sproQuery, note that only if 4 bytes are requested the read from disk happens, if 8 bytes are requested a constant is returned (this is the initialisation of the program).

Kayaker
October 30th, 2003, 00:21
Hi

Forgive my confusion, but I'm a little confused. You mention the program crashes when OpenFileA is called, but there is no OpenFileA in your patch, did you mean when CreateFileA (or maybe ReadFile) is called, (OpenFileA is supposedly to be used for 16 bit apps only) or is there an OpenFileA call later in the program which crashes?

There are a few dongle essays by Cyberheg etc. which discuss emulating the generic sproQuery function, you may have seen them already but they might help in setting up the query/response that is apparently the purpose of this algorithm function.

For the ReadFile, you say it seems to work when requesting 4 bytes, but with 8 bytes it returns a constant or something. lpBuffer should be large enough to hold the received byte data, and in your code is defined by [ebp+arg_10]). Is this a pointer to a larger data structure or mem location defined before the call to sproQuery or just a dword variable? The same applies to [ebp+arg_C] which seems to get 2 dwords at some point. If I'm reading your code wrong I apologize. Also check if the return value in EAX from ReadFile is zero, if so the function failed but you can get more information by then calling GetLastError.

Not sure if any of this helps. Make sure the stack position in ESP is the same before and after your sproQuery function patch as well

Cheers,
Kayaker

peterg70
October 30th, 2003, 00:43
The program is an mp3 player and we receive a new cd of mp3's every month.


Who does this sort of thing? Anymore info on the software PM me the details please.

peterg70

cyberheg
October 30th, 2003, 03:25
How about doing it the cool way?

A few years ago I got a cool idea which I just had to implement.
Since it's possible with large probability to detect all the public rnbo* functions available from their api I wrote a generic patcher which finds each of them and redirects their functionality to a dll. This was done by patching the import table to include my dll and replace the functions with jump instructions to the corresponding function offered by the dll.

After this step I built a dll which had the apropriate function prototypes and I had free hands to code my dll in whatever language (in my case C) with no restrictions on available space.

It didn't take more then a few days to make this and the nice thing is that it's generic to any app.

// CyberHeg

tom
October 30th, 2003, 05:59
Quote:
[Originally Posted by Kayaker]
Forgive my confusion, but I'm a little confused. You mention the program crashes when OpenFileA is called, but there is no OpenFileA in your patch, did you mean when CreateFileA (or maybe ReadFile) is called, (OpenFileA is supposedly to be used for 16 bit apps only) or is there an OpenFileA call later in the program which crashes?

I'm sorry for the confusion i meant CreateFileA

Quote:
[Originally Posted by Kayaker]
Not sure if any of this helps. Make sure the stack position in ESP is the same before and after your sproQuery function patch as well

When the program starts it also runs sproQuery (returning the constant) and ESP is stays thesame.

Quote:
[Originally Posted by cyberheg]
Since it's possible with large probability to detect all the public rnbo* functions available from their api I wrote a generic patcher which finds each of them and redirects their functionality to a dll. This was done by patching the import table to include my dll and replace the functions with jump instructions to the corresponding function offered by the dll.


This really sounds like a good idea, this way it also wil be far more easy to patch a new version of the program. Are you willing to share your code?

cyberheg
October 30th, 2003, 13:20
Quote:

This really sounds like a good idea, this way it also wil be far more easy to patch a new version of the program. Are you willing to share your code?


No, why would I be? Make it a exercise for yourself. If you're serious about your work then you can't expect everyone else to do the job for you.
My code was cheaply hacked together from other projects I did in past so it's not beautiful nor bugfree. I see no reason for posting it only to get people write me mails afterwards on how to use the damn thing or report bugs which I don't care about anyway.
There are more advantages about this one and I did similar projects for other protections. Most of them I never talked to anyone about because they are really too good for "avarage joe cwacker" to use and abuse.
The word of advice is that if you want something done properly you must do it yourself.

// CyberHeg

tom
October 30th, 2003, 18:19
Quote:
[Originally Posted by cyberheg]No, why would I be? Make it a exercise for yourself.


Your're right it certainly wil be a good excercise, it's kind of a hobby project anyway. I've read some things about import tables after your post and although it's not really easy it should be doable. (it just takes some time)

Zaza
November 5th, 2003, 01:13
Quote:
[Originally Posted by cyberheg]How about doing it the cool way?

A few years ago I got a cool idea which I just had to implement.
Since it's possible with large probability to detect all the public rnbo* functions available from their api I wrote a generic patcher which finds each of them and redirects their functionality to a dll. This was done by patching the import table to include my dll and replace the functions with jump instructions to the corresponding function offered by the dll.

After this step I built a dll which had the apropriate function prototypes and I had free hands to code my dll in whatever language (in my case C) with no restrictions on available space.

It didn't take more then a few days to make this and the nice thing is that it's generic to any app.

// CyberHeg


how did you search for the library functions? did you use ida's .pat files - this is the approach im thinking of using.

My only slight concern is that i have noticed some sup3rpr0 sig files getting the library identification wrong and im wondering if rainb0w has started doing clever stuff to screw up the flirt algorithm.

Zaza

p.s. does anyone know how ida identifies variable bytes?

sope
November 5th, 2003, 03:12
Hello Zaza

Well, if the sig file fails to recognise the function, binary search in ida for the world famous 7242 bytes & carry on the fantasy...

Regards Sope!

Zaza
November 5th, 2003, 08:13
Quote:
[Originally Posted by sope]Hello Zaza

Well, if the sig file fails to recognise the function, binary search in ida for the world famous 7242 bytes & carry on the fantasy...

Regards Sope!

thats how i have done it manually in the past but im hoping to automate the process. Its fairly easy to recognise the functions with a bit of zen!

cyberheg
November 5th, 2003, 15:09
Quote:
[Originally Posted by Zaza]how did you search for the library functions? did you use ida's .pat files - this is the approach im thinking of using.

My only slight concern is that i have noticed some sup3rpr0 sig files getting the library identification wrong and im wondering if rainb0w has started doing clever stuff to screw up the flirt algorithm.

Zaza

p.s. does anyone know how ida identifies variable bytes?


About how ida does it's stuff I think there is a document published on some of their methods. I know it has something to do with taking some bytes out and using crc16 for the rest.

My method for finding the functions was very easy. Just take a few bytes from the start of the function. How many bytes to search for depends on the api but Rainbow Tech has done nothing to obfuscate the functions.
Some sig files were wrong but thats only because they weren't generated in a valid way. I remember that I reported a bug about Killer3k's or whatever his nick is but it was just ignored and never updated. I released some files though for version 6.0 which has worked many times for me.

// CyberHeg