guys i've been looking over a program code and tried different ways to patch it, i kill main crc check ..no problem.. but there's something hide inside.. after playing a music CD after about 2 hours strange noise is been heared on the background while the music is been played . like it was an oldy music disc ...well i tried different ways to patch this..also with loaders... and the crc message isn't displayed but still got the noise after 2 hours .. don't know if it's detecting it's been launched it with a loader .. but remain silently working ..or it's just a hidden license check? .. without loader and running as trial never happend any noise

does anyone knows which API could be using to produce this kind of noise? or which API could be using to silently detect i'm using a loader to launch it?

sample mp3 so you could listen the background noise,like an electrical noise, the program did on this sound..: _http://www.damnfm.nl/ots.mp3

i tried to break using killtimer.. looks it's not using this API to finalize good work ..because never break before starting the noise , neither i saw the APIS: timeEndPeriod...timeBeginPeriod...timeGetTime which WinMM.dll use

if someone is interested to look at it here it's:LINK DELETED

finally here are some different bytes i used to launch it while playing.. (Process patcher project):

#Process Patcher Configuration File

PatchAuthor=CRK
PatchContactInformation=inside the bytes

DisplayName=OtsLabs
Filename=Otsdj.exe
Filesize=1069056
SupportedPlatforms=All
StealthMode=True
;ShowDos=False

<snip>

#End of Configuration File

another info.. is that this app. uses a driver file: ots_lla.vxd located in the system directory.. don't know if this has something to do with this protection.. i opened before with IDa but didn't find anything interesting there..

any comments or ideas??

My best Regards

Aww c'mon cRk, you've been here long enough to know we can't risk allowing a link to a shareware app+crack, or the list of patch bytes you included. Anything labelled ".full.incl.crack-tsrh.zip" is just asking for trouble, suddenly we've got people complaining to the ISP that we're supplying cracks (whether it's true or not), blah, blah, etc. So I did my dirty duty and deleted the link...

Unfortunately this sounds really interesting Is there some other way of describing or discussing this that might determine if this is something the app is really doing? Or maybe your speakers are just pooched?

Regards,
Kayaker

thanks for editing.. uppffs .. this app. is making me mad.. i have to wait long time for test... if someone is interested . Private message me for the link...sorry for my mistake... had hard days without sleeping well while trying to modify this tricky stuff. LOL .. this isn't the speaker problem or windows related....kayaker.. want to try it?? :P

Yeah, sorry too, but gotta draw the line somewhere.. trying not to squash relevant/interesting topics totally though.

...maybe...

Hi cRK. Some wild suggestions:
1. You say it takes a long time to do the tests, 2 hours until the nag noise comes in. . .
What happens when you advance the computer clock? 1 hour and 58 mins?

is it keeping track of the time from reading the system time somewhat or by an internal device. what about Fast Forwarding Does it start the nag noise?

2. I heard the Nag noise MP3. it is a quite regular interference with the music playback. If you played a completely flat wav. file or CD (You can make a flat wav file by just filling the info part with the byte 127 (ox7F) for an 8 bit wav mono file.
you can analyze the interfered output using one of several graphic sound analysis softwares.

You will probably see that the nag noise is a disturbance that happens at very regular intervals my guess 10 times per second. I would guess that an infinite looping call is being added the sound output. or startling the normal flow of the sound output

3. Perhaps the nag noise may not be intentional but a malfunction of the loader code which is in the same memory space of your app. . .

i'm sure is either a hidden license check or it's detecting i'm using a loader to launch it.. it has some limits .. that's why i'm tryng to change some things.. i tested with a loader leaving registration scheme intact and launching killings part of the nag and still gave me these strange noise ... without using any launcher or modified bytes nothing will happend.. i tried fordwarding songs/skipping tracks and nothing happends , neither forwarding the system clock.. i tried with a 60 minutes and 34 seconds CD (15 sounds) .. after it has been played completed the app. has an option like an automatic DJ and will start the CD since the beggining .. will play 13 sounds again since first sound and ... while this song set almost finish .. while playing the 13 sound it will start the noise.. so by that time has passed more than 1 hour, almost 2 hours if i'm not mistaken..

track 13 has 3:48 track 14: 3:28 track 15: 4:22

My Best Regards

Have you tried to break on read the instruction where you kill the nag? If it happens when you just kill it, you can discover quickly where it checks the code integrity.

this is not a cra_ck request.. would like to gain experiencie/knowledge with this beast ..i will suggest you guys try yourself and if you got the answer to this wrote some lines explaining what's going on here..

for mAximus this app. checks all bytes not just the nag part ..i was trying to discover if still checks the integrity but maybe is not the integrity.. it could be checking the loader .. if the integrity is broken it will tell you with some message about it. so could be just checking the loader.. and remains with silence with a time bomb for the music

My regards

One other trick is it could be using RDTSC... find any of those in your code?

RDTSC

what's it ?

rdtsc is basically used as a timer function in some protections use to see if they are being debugged. You can use 2 rdtsc commands, one at the beginning of the section of code and one at the end, to get the amount of time it took to run that specific section of code. Since a debugged program will run slower than the OS it can be assumed if the resulting difference between the rdtsc values is out of a specific range then it can be assumed the program is being debugged.
neitsa wrote a nice little program to make rdtsc a privilege instruction. This way an exception will be thrown when rdtsc is called, and you can intercept the exception in your debugger to find and modify rdtsc returns.
http://www.woodmann.com/forum/showthread.php?t=7122&highlight=rdtsc

Howdy,

I have had such things happen to me in the past.
In an effort to figure out what was causing this, I found that it is a freak situation that sometimes occurs.

For example;
I burn a CD and play it back on my comp. It sounds like shit with all that background noise. I try it 3 or 4 times and get the same result.
Am I pissed off mad ? Oh yeah. Ready to smash shit.

I take one of the disks and put it into the other comp next to me and it sounds fine. Put it back into my comp and it still sounds like shit.

Put it into the cd player in the other room and all is fine.

The moral to this story ? I have no idea why this happens.
All I know is that if it sounds like crap on my rig, it sounds fine on the cd player in the other room.

Thank you and glad to be of no help .

Woodmann

LOL

gabriel .. sounds interesting.. on which OS does that tool works ??

my Regards

Heh, I see we're on the same wavelength, pardon the pun. I was more interested in analyzing the noise than reversing the app. After some trial and error I applied a 4000-8000 Hz Bandpass filter to the mp3 signal in a spectrum analyzer and was able to pull out a regular interference roughly every 0.023 sec. If you look at the attached jpg you can see the results.

The image on the Top Left is a section of the signal at time index 10-11.6 sec. The image on the Top Right is after applying the 4000-8000 Hz Bandpass filter. You can start to pick out a regular spike that is the background noise. The 4 large beats at the end of the spectrum is a recognizable part of the music (what are those, maracas?)

The section highlighted in yellow is expanded in the image on the Bottom Left, and you can really pick out the noise spikes. The image Bottom Right is the same, but as a spectrogram view of a time based FFT Fourier Transform, just another way of representing the data which highlights the added noise as blocks of color.

So, if you're lucky you might be able to pull out a repeating pattern of bytes in the affected mp3 file itself, comparing it with the original if possible. The exact pattern of bytes which encode the "noise" block might not be identical, because of the addition of signal from the music itself at any particular point in time. But you might detect some other pattern indicating the regular "time" signal, either in the mp3 file or the code itself.



If there is a call being made for every 0.023 sec of running time it must be detectable by some form of call analysis, IDA? Olly?

Kayaker

(EDIT: Sigint, I wrote .23s at first, I meant .023s. Fairly accurate center to center measurement and consistent but I may have introduced errors by filtering)

Verrrry interesting Kayaker, and an approach that I would probably would not have taken even though it's the first thing that comes to mind, I guess it's a matter of "the curiousity factor", what puzzles me is the noise appears to be non uniform and doesn't appear to be digital in nature, but that could be the DSP in the sound card, I vote for .255 secs 255 milliseconds, simply because that would be represented by 0x000000FF more likely a value that a programmer would choose anyway over 0x000000E6, so i imagine searching for a loop with a delay in that range would be the approach.

SiGiNT

Hey Woodmann, maybe this have you tried before, but...

Have you checked in the music player of the computer that sounds bad that it is using digital performance instead of analogic one?

Sometimes this little things are doing us becoming crazy...

Cheers

Nacho_dj

You tha man!

That was the idea I was cooking, but I was to drunk to express it.
Just as the text and the window class of a screen nag can be used to zero in a protection, the time signatures of a sound nag may clue crk into the protection inner workings. . .

you guys have gives many ideas and jokes about what could be doing this.. but i need to find where is the code for this on the program, using Sotfice what should i do..? what breakpoints to use? , how to find the loop ?.. i had to wait almost 2 hours before this strange noise appear . i will private message you the target to some of you so you could check this .. play your favorite CD and leave it playing.. you will note the surprise ..for my system and cd i'm trying i had to wait almost 2 hours, maybe could be less on other system like 80 minutes.

i was checking the resources with ExeScope and saw there 2 suspicious hardcode?/encrypted stuff in the BINARY part... resources 192 and 248 don't know exactly what they could do.. but for some reason author decided to encrypt them.

if your logical analisys is right Kayaker .. what's the code for the program to done this.. using mov or push to some address or.. ?? to make the noise appear after 230 miliseconds .. i searched for possibly miliseconds strings.. attached image. for 255 there are too many strings .. of course most of them are not the ones we could be searching for.

apreciate the attention you have put on this.

My Regards

well i found something interesting while still don't giving up on this.. but still don't know how the program control this... if i'm not wrong it has something to do with the QueryPerformanceCounter API ... this interesting place: 0044ED5E ... if i make it always jump i start getting noise almost instantly while playing a CD but if i nop it, also i got noise and skip tracks .like voice interruption .. so it most be needed somehow .. this is not all .. if i nop at 0044EED0 without touching at 0044ED5E the noise increased .. like a high distortion.. almost can't listen anything ... will make always jump at 0044EED0 and let it play to see how things goes.

at 0044EF1E calls some other interesting place (00419430) where a little down you will see a suspicious mov (0041A461)

the sound process start at 00419430 ..if i change 55 for C3 at 00419430 not sound will start to be heared

things are getting cleared now.. but still don't know how exactly this protection scheme works and what to do.. i'm a little lost in all this code..

any ideas/clues will be welcome

My Regards.

Good... you found it!

Inspect the area around those two calls more carefully. You're almost there. This is how it's getting the elapsed time. Track the value that QueryPerformanceCounter sets (64-bit int) and see how it's being used in the code. The value returned from QueryPerformanceFrequency should also be used somewhere in there.

QueryPerformanceFrequency is present too... but still haven't get the point for all this.. guess i'm some kind of lost between all this code.. still i got the noise at the end i'm trying some other bytes...i will report any good news if any .. here start playing.. when you hit play file.. at 0041ADB6 ..

My Regards

Hi cRk.

Think about this:

What is Digital sound?
What is digital sound reproduction?

Ultimately, digital sound is a looooong stream of (Signed)numbers, 1 byte long for 8 bit sound, 3 bytes long for 24 bit sound that get read at an extremely precise rate, typically ~42.000 times a second. The value of these numbers, when plotted against time in a 2D graph, mirror the analog sound wave that generated the sound. Sound cards turn those numbers into voltages (-5V to +5V) that drive the speakers.
A digital recorder, will take the signal from a microphone, which is nothing else than a voltage varying in time, and read it 42000 times per second (Called the sampling rate) and generate a loooong stream of (Signed) numbers, representing those voltage readings. If you have Stereo, you have two independent streams of numbers, if you have a multichannel 5.1 dolby for instance, you get 6 streams of numbers. Clear? OK

Needless to say, the time keeping, the rate at which those streams are read and played back are critical for the quality of digital sound. The computer clock or the cpu cycles, while several million times higher than the sampling rate, typically 1~3000.000.000 (Gigahertz) clock ticks per second is not a relayable device to play back digital sound. Depending on cpu usage, the interval between two stream reads can be too short or too long, worse yet, highly variable between read and read.
That is why those high precision 64 bit time keeping API are needed in digital sound (and video) recording and play back. if you mess with them, the playback sound appears distorted.

The distortions of your play back sound are highly, regularly timed.

I hope this makes sense. . .

Indeed. What I'd like to see is the distortions against a perfectly flat baseline, like Naides suggested "You can make a flat wav file by just filling the info part with the byte 127 (0x7F) for an 8 bit wav mono file." (very cool

If you expand the distortions in the spectrum analyzer they definitely look sinusoidal, and may actually be groupings of 2 or 3 sine waves. Against a flat baseline you might be able to accurately measure the period (sec) and amplitude (Hz), as well as the timing between them. There may even be a harmonic envelope overlying them (there seems to be a regular rise and fall of the amplitudes).

I wouldn't take ANY measurement as exact without a flat baseline, and maybe even then, but the period of a single sine wave of the "noise" seems to be in the order of 1e-4 sec (.0001 sec). The time between pulses is as I mentioned *roughly* 2.3e-2 sec (.023 sec). IF you can make a few measurements that you are confident of (>90%?), you might be able to recognize a few constant values that the program uses.

Trying to guess or calculate the equations the program uses to generate the noise signal might not be a viable strategy, but it is a strategy nonetheless. The program does use many high precision constants, including Pi, and it may be like looking for a needle in a haystack, but you never know..

There are many ways to generate a sine wave in software, the simplest is probably the floating point fsin instruction, which this program uses several times. It's *possible* that following uses of this instruction *might* lead you to a relevant loop or call which generates the noise, especially if it cross references with other clues you find.

For other ways of generating sine waves see for example
http://www.dattalo.com/technical/theory/sinewave.html


As for QueryPerformanceCounter, it can be used for detection purposes of a sort, if interested I gave an example of using QueryPerformanceCounter for detecting a debugger here:

OllyTest
http://woodmann.net/forum/showthread.php?p=39672#post39672

In this case however it may only be being used for digital timing as Naides mentioned.

Kayaker

I stand corrected on my assumption that the interval would probably be .255, as cRk has found the smoking gun - but I question are we approaching this correctly? I can't help but think back to the original complaint of this occuring after 80-120 mins - wouldn't it be easier to focus on eliminating that timing, (and an odd one at that!, why not after 10 mins?), or extending it to an infinite value or an acceptable value like 24 Hrs.? Granted it's a blast playing around with spectrum analyzers, but there may be a simpler solution.

Just a thought.

SiGiNT

Or, thinking along the same lines, just keygen it so that the binary itself is left untouched. I have a feeling it's detecting the patch (even after the initial check) and then "silently" waiting for some time before injecting the noise.

You are not fun!
The simplest, cheapest and most universal crack is buying the bloody program.
Where is the challenge?

AH!

But the best solution is the most elegant, no need shooting beer cans with M1 tanks!, Of course then again it also occurs to me you might be able to eliminate the noise by simultaneously triggering a noise of equal frequency but opposite polarity, (noise canceling), now that would be fun!

Actually a technique I used when designing an early cable TV descrambler, sync was inverted so I injected a sync signal of opposite polarity at 2X the amplitude.

SiGiNT

some friend shared with me a serial for this but needs online activation.. already i believe is blacklisted so can't full activated.. it gives 7 days as Temp machine license .. for private use i will PM to some of you the license so you can full load the app. without touching the exe this could be used for analisys..i'm still looking on it.. finally i'm not interested to use this program at all, i'm not interested to full activate this app. i'm JUST interested to learn what's involved on this kind of trick and how to kill it..that's all.

My best Regards to all

Count me in ? I'm always willing to help ... erm, learn ...