Jump to content

A batch file can do wonder!


Recommended Posts

To All the Fellow Members,

What i need is a special type of batch file or a script file; the only purpose of the batch or script is to check for one or two particular strings in an already present report file generated by some program. The moment it finds string(s)in the reference file, it compares the string value with a value pre-embedded in the needed batch itself or the same value located in some other file. Based upon this cross-checking, the batch will take system-critical actions as its next task. If, the values compared are same, the batch will simply terminate itself. But, if the values mismatch, batch will act as a Frankenstein; it will terminate itself as well as any future operation scheduled after it.

The whole idea is linked to unattended installation CD, and my main goal is to implement some serious machine authentication standards. Yes, my need is related to protection of our UACD Projects from unauthorised copy, distribution and, even sale by those who get their hand into it only because of our generosity. After putting so much efforts, it hurts, severely.

I've the report file generated by a particular program; this is the standard. If anybody is ready to help me, i'll provide the report file to him. Microsoft, in collaboration with some OEMs, has implemented SLP(System Linked Pre- Installation) in their Windows XP CD, which entangles Installation from the CD to the System BIOS or Mainboard. If Mainboard is changed or the BIOS is updated, that Windows XP CD is gone! SLP is such a severe stopper against

copying.

Our protection method, as i imagined, is close to SLP type protection method implemented by Microsoft.

If anybody is ready to help me out, all effort by him will be self-rewarding, as his own UACD Project is protected thereby. For him, this much i can say and, Secure. For Sure.

Thanks, for such a long reading.. :)

Edited by MOONLIGHT SONATA
Link to comment
Share on other sites


Quit expecting other people to do your work for you. If you're interested in implementing something like this, you should have done at least some research on it instead of just trying to take the easy way out. The information for the script you want to create could be found in even the most basic of guides. Google around for some help, or use the built-in .chm file, and there are plenty of command files on this webpage to use as examples (BTS' integration cmd files are nicely written and would make interesting browsing for you).

Link to comment
Share on other sites

@maxxpsoft,

Thanks, for your link. Hope, i can do some thing with it.

P.S. Today joined your forum! Nice Place for me to channelize bandwidth. Not posted anything today. Only downloaded your hard work. Busy with your Set up scheme. Lovely executable to execute.

Promise you to actively participate. Keep up your good job. Thanks.

Link to comment
Share on other sites

@MOONLIGHT SONATA

Ask me anything over there and I'll answer more freely. I'm not that good at batch but do know it from the early day's. Using that help file does help though, although a few things are not right with it and those things you have to discover on your own. Like upper case lower case makes a difference occasionally. /F /f

Link to comment
Share on other sites

Did a little research on this a while ago. It's an interesting technology. Anyway, the short answer is that short of you being a large scale system builder, you're not gonna pull this off. The whole process looks something like this.....

1) System Builder creates a file that points to a specific BIOS location and matches a text string in that location.

2) The system Builder then signs this file with a verisign digital certificate.

3) Send file to Microsoft OEM System builder group who do some manipulatoin turning it into a 10+Meg file.

4) Microsoft countersigns the file with theit digital certificate and returns it to the system builder.

5) From this point it appears to be a little unclear, but it looks like you simply place the file in the $OEM$ structure which gets read as part of the install process assuming you are using the OEM build of the product. Corporate and Retail builds DO NOT look for the file.

There are a couple of caveats to using this tech. First, you can not install via winnt32.exe or setup because it implies an environment is alreayd in place and the tech only work in clean installs. to me this means if you do any pre-install steps, you're out of luck. It also doesn't ask for a product key because its been integrated into the file somehow by Microsoft. Personally this isn't a big deal to me since there is functionality to encrypt the key in the build process.

Most of this info comes from the OEM documentation and the MS System Builder newsgroups.

(Duh, hit reply too soon:P) The method is interesting but I'm not sure how you will via script or batch prevent breaking. Also most of the installation is subject to in-process manipulation via a keystroke that will open a CMD shell whcih allows you direct acccess to the installation.

Edited by mockranger
Link to comment
Share on other sites

Not really.

the technology is targeted towards OEMs not home enthusiasts. most OEMs use a taileored BIOS for their systems and have embedded their own text strings. I know this is the case with Gateway, Dell, and HP. When the OEM builds the BIOS they just leave the key string in the table at the same position.

Link to comment
Share on other sites

@mockranger

Very very serious observations posted by you. Priceless, infact.

in this context, i've someyhing to say further.

Microsoft takes the view that if the computer has a system-locked OEM version and you upgrade the computer's motherboard, you have a new computer and you are required to buy a new licence for Windows XP.

There is an area of dispute if the computer's original motherboard gives up the ghost. If it is replaced with one that is as similar as possible to the original board (is of the same make and model), the user should be all right.

The position depends on how the OEM copy of Windows XP was originally activated...

Many OEM copies installed by the major manufacturers (Dell, HP, Packard Bell, etc.) use a system called System Locked Pre-Installation (SLP) that doesn't match any hardware on start-up. It looks for a special signature in the BIOS setup program instead.

If the OEM computer's installation Windows XP has a file called oembios.bin, then it has SLP-activated OEM copy. Microsoft is unclear on what happens if the user has to replace the motherboard in this case, but it seems as if a new Product Activation will be granted if the replacement motherboard is made by the same manufacturer,and is preferably the same model.

Having said that couldn't we start with little labour with respect to what is within any OEMs' oembios.bin? just an idea. Hope you think and respond.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...