How to force a Blue Screen Of Death

[Rex]

Couldnt you just get past the date check by setting your computers date back.....

<{POST_SNAPBACK}>

You could, but if put in a start date and a end date so you have to finde the right date to set back your computer's date.

I know that an expire date newer will be 100% sure on a cd, becorse of the +r attrib. But if the cd only works for 14 days, and you first get your hands on in after a month it could be hard to finde the correct date, to get it to work

[/dev/null]

Rex,

I have a new idea for you. Create a secret algorithm that calculates, based on the date, a 512 Byte string. So, whenever someone wants to run your application, you just display your phone number and tell the user to call you up to get a valid key for today. This will eliminate your problem with expire dates, as you can decide if you want to hand over another key for that user

Cheers

Kurt

[Rex]

Rex,

I have a new idea for you. Create a secret algorithm that calculates, based on the date, a 512 Byte string. So, whenever someone wants to run your application, you just display your phone number and tell the user to call you up to get a valid key for today. This will eliminate your problem with expire dates, as you can decide if you want to hand over another key for that user     

Cheers

Kurt

<{POST_SNAPBACK}>

That's would not be nessary, course normaly thoes who have a disk are allowed to use it and can always ask me for a new, the only reason i want ti "expire" them is to prevent that the disk falls into the wrong hands, if the disk gets lost, forgoten or somthing like that....

[Danny35d]

Another idea will be when you burn your BARTPE iso do not close where ever cd free space you have left. Then when the expiration date is reach use the same tools as BART (cdrecord.exe) and burn a TXT file on the cd.

Now you have something permanent that your script can look for it on the cd at this point doesn't make a different if the person change the date or not.

Note: I know not all computers have cd burner but, eventually they will use the cd with a computer that have cd burner.

[Rex]

Another idea will be when you burn your BARTPE iso do not close where ever cd free space you have left.  Then when the expiration date is reach use the same tools as BART (cdrecord.exe) and burn a TXT file on the cd.

Now you have something permanent that your script can look for it on the cd at this point doesn't make a different if the person change the date or not.

Note: I know not all computers have cd burner but, eventually they will use the cd with a computer that have cd burner.

<{POST_SNAPBACK}>

Normaly i never se the cd again when i distribute them to my staff

[Danny35d]

Normaly i never se the cd again when i distribute them to my staff 

<{POST_SNAPBACK}>

What a mean is the script that check date is between the 14 days, if pass the 14 days used cdrecord.exe (command line) and add a txt to the cd.

For example you boot bartpe and your script see INVALIDCD.txt on the root directory stop the boot process....

sorry for my spelling but english is my second language

[Rex]

What a mean is the script that check date is between the 14 days, if pass the 14 days used cdrecord.exe  (command line) and add a txt to the cd.

For example you boot bartpe and your script see INVALIDCD.txt on the root directory stop the boot process....

sorry for my spelling but english is my second language

<{POST_SNAPBACK}>

That way will only work if the disk comes back to me when is's expired, and that happens almost, hmm let me see never My staff's instruction is to throw away the disk when ever the gets a new one, and the normaly get's a new one twise a month.

What my script now do is that it checks the sam file on the computer, if the sam file is older then the disk creations date, it checks the system date to validate if the disk is expired or not.

There is there for no need for me to burn a file to the cd after it's has expired cource the disk should be destroyed when out of date

[/dev/null]

I'm a bit curious now. What kind of application do you ship every 2 weeks??

Cheers

Kurt

[seandisanti]

ok, i have a few issues... i see that you've decided against the bsod approach, but still want to say i'm kind of shocked that anyone even humored that idea for a second. with a BSOD the system is stopped at a point when data has not necessarily been saved, and the operating system has not done it's normal cleaning up etc for shutdown. almost invariably there is data loss or corruption that can affect the entire system, not just the little program you think you can make unpirateable. I mean, what if someone has permission to use your program, but they're setting their clock a few years ahead before installing another shareware program to make sure that it never expires (because it compares current date to install date to check the difference every time it runs) and then your program blue screens them? Granted, they're doing something that isn't legal or whatever, but it has nothing to do with your program, and you're not authorized to enforce protection for any other program but your own right?</rant> sorry just had to say that, i was reading the thread just now waiting for someone to say something about that and was just like WTF when it never came. Ok, now on to the constructive part of my post. Few things to look at... 1) there is no unbeatable protection. NONE. there are lots of ways to make it difficult but nothing, even with a bsod on fail, is insurmountable. one thing you could do, is just have it check the date, and if it is past a certain date, eject the cd... nothing too special but it's going to stop the execution of the program from the cd. or you can make it so that a script is created and executed by your script, which is saved to and run from the hd. that script could 1) make a registry key that is checked when you program starts that can conditionally halt your program just by being there. 2) eject the cd. 3) msgbox an error that they are not authorized to use the cd further 4) delete itself.

This way, even if they are debugging your program, looking for the check in the asm code, they're not going to find the instructions that are actually causing the fail. i mean they could find where the registry is being checked, and tweak that check possibly, but depending on how you code that, that could be difficult for them too. but they couldn't change the code on your original program to force it to work unless they bypassed that registry check. also, i'm assuming you have checks in place to check if the program is being executed from the cd rom, to avoid them just copying to the hd and having their way with it...

[Rex]

I'm a bit curious now. What kind of application do you ship every 2 weeks??

Cheers

Kurt

<{POST_SNAPBACK}>

It's not applications, it's a "system bootcd" with some recovery tools including Antivirus, ad-ware/spyware, and this i update ca. every 2.

So it's the same "build" but with updated defs., but due to the recovery programs on the disk, i have to do what i can to prevent that some one outh site my staff uses it. Thats why i'm trying to da a expiredate thing.

[/dev/null]

So it's the same "build" but with updated defs., but due to the recovery programs on the disk, i have to do what i can to prevent that some one outh site my staff uses it. Thats why i'm trying to da a expiredate thing.

Ah O.K. So, what will prevent those users from just copying the files you want to protect off the cdrom ?

Cheers

Kurt

[Rex]

ok, i have a few issues...  ------

<{POST_SNAPBACK}>

with a BSOD the system is stopped at a point when data has not necessarily been saved, and the operating system has not done it's normal cleaning up etc for shutdown.

1. When you use a BartPE cd/dvd or a WinPE you dont boot, the computers system but a system on the cd, so if you get's a BSOD it normaly don't have eny thing to with the computer's system, but an error in the cd's system.

almost invariably there is data loss or corruption that can affect the entire system, not just the little program you think you can make unpirateable.

2. I'm not trying to antipirate... my cd.

there is no unbeatable protection. NONE

3. I know that no anti some thing works 100%, there will always be some one that makes some thing to do that some thing wornable

The only thing i'm trying to do is an atempt to prevent the wrong persons to use my cd.

And as you sayed i abandoned the BSOD.

[Rex]

Ah O.K. So, what will prevent those users from just copying the files you want to protect off the cdrom ?

Cheers

Kurt

<{POST_SNAPBACK}>

LOL Good Q.

I have packed all thoes apps with encryption. When then the use executes the app thru the shortcut, a script runs, and checks for.. well a lot of things if then all is ok it decrypts the app and extract it to the ramdrive.

And yes i know that if some on get there hands on the cd before is't expire the can extract the app from the ramdrive... Again nothing is 100% secure, but this way i makes it a little harder for some on to extract data from the cd...

(just to be fast the decryption script can only run from with in the cd, and only when the sys is fully booted)

[/dev/null]

The only thing i'm trying to do is an atempt to prevent the wrong persons to use my cd.

you don't want to stop regular users to use the cd after some time, but rather prevent "irregular use" of the cdrom? If so, why don't you encrypt some essential parts of the cdrom with a new "master key" every two weeks. Your users will then have to know the master key to start the cdrom. If they throw away the disk after two weeks, nobody can use it without the key. Checking the date of the computer could be done as you described it. However, if you don't want to protect the cdrom from your regular users, just tell them to throw away the cdrom after two weeks and use the fresh one you're going to send them.

Cheers

Kurt

[Rex]

@All

After upgrading to XPE 1.0.4 i can now password protect the cd on sys level, so there is rearly need for an expire date

[seandisanti]

1. When you use a BartPE cd/dvd or a WinPE you dont boot, the computers system but a system on the cd, so if you get's a BSOD it normaly don't have eny thing to with the computer's system, but an error in the cd's system.

2. I'm not trying to antipirate... my cd.

3. I know that no anti some thing works 100%, there will always be some one that makes some thing to do that some thing wornable 

The only thing i'm trying to do is an atempt to prevent the wrong persons to use my cd.

And as you sayed i abandoned the BSOD.

<{POST_SNAPBACK}>

1) thanks for the elaboration on booting from cd and how bsod wouldn't affect computer's file system, hadn't thought of that.

2) i meant no offense the way i worded that, i meant you were trying to prevent the use of one program, and i thought you were potentially risking system integrity for the sake of that protection, but as #1 cleared that up, i'll just consider this a wording issue.

3) did you read beyond the line you quoted for #3? i suggested a possible solution for you that i think would provide atleast a moderate lvl of protection...

[Danny35d]

@All

After upgrading to XPE 1.0.4 i can now password protect the cd on sys level, so there is rearly need for an expire date

<{POST_SNAPBACK}>

I didn't know that you were looking for password protect the cd. In my work cd I used viceroy's Secure Screen allow me to create several user, differents password and also set and expiration date to any of the users.

http://viceroy25.tripod.com/

He also supplies the source code....

[Rex]

1) thanks for the elaboration on booting from cd and how bsod wouldn't affect computer's file system, hadn't thought of that.

2) i meant no offense the way i worded that, i meant you were trying to prevent the use of one program, and i thought you were potentially risking system integrity for the sake of that protection, but as #1 cleared that up, i'll just consider this a wording issue.

3) did you read beyond the line you quoted for #3? i suggested a possible solution for you that i think would provide atleast a moderate lvl of protection...

<{POST_SNAPBACK}>

Sorry if i'd sounded ruf, it was not my intend

Yes i'd read beyond the line, but sins you boot from a WinPE cd, the access to the hd's registry is limide.

And deleting files from a cd, is in this writing hour not possible *SS*

I do check the date, due to my ExpireDate script and it was from that point this tropic spown, course i would use my date checker to do a BSOD if the cd was expired.....

/Rex

[seandisanti]

Sorry if i'd sounded ruf, it was not my intend 

Yes i'd read beyond the line, but sins you boot from a WinPE cd, the access to the hd's registry is limide.

And deleting files from a cd, is in this writing hour not possible  *SS*

I do check the date, due to my ExpireDate script and it was from that point this tropic spown, course i would use my date checker to do a BSOD if the cd was expired.....

/Rex

<{POST_SNAPBACK}>

didn't mean for the script to delete from the cd...

make it so that a script is created and executed by your script, which is saved to and run from the hd. that script could 1) make a registry key that is checked when you program starts that can conditionally halt your program just by being there. 2) eject the cd. 3) msgbox an error that they are not authorized to use the cd further 4) delete itself.

if registry editing is not possible with that type of a boot, then why not make an obscure ini that is looked for by your program, same concept, there is a control check that your software could look for at startup, and if found, your program knows it should be disabled. that could be one trigger to create and execute the script mentioned above, which places (or overwrites if it already exists) the registry entry/ini file and ejects the cd...

***edit*** messed up on my bold tag...

Edited August 11, 2005 by cameronsdad

[Rex]

you don't want to stop regular users to use the cd after some time, but rather prevent "irregular use" of the cdrom? If so, why don't you encrypt some essential parts of the cdrom with a new "master key" every two weeks. Your users will then have to know the master key to start the cdrom. If they throw away the disk after two weeks, nobody can use it without the key. Checking the date of the computer could be done as you described it. However, if you don't want to protect the cdrom from your regular users, just tell them to throw away the cdrom after two weeks and use the fresh one you're going to send them.

Cheers

Kurt

<{POST_SNAPBACK}>

I can't encrypt ½ the cd course of the way the cd works

My staff throw away the cd's (atleast thats wat the tell me (ind i trust them))

But as we all know sometimes peapol forgets things, when the go home or are in a hurry and thats why i'm trying to limmited the dammage by expire the cd.

And so far i'w been using the nice ExpireDate from John925, but then i discovered AutoIT and an came into my minde after been using AutoIT for some time and i had lernd the basic functions of it... I could do my own Expire Date script costumized to my own use. And then i started this tropic