• Announcements

    • xper

      MSFN Sponsorship and AdBlockers!   07/10/2016

      Dear members, MSFN is made available via subscriptions, donations and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, become a site sponsor and ads will be disabled automatically and by subscribing you get other sponsor benefits.
xehqter

OEMScan - Automated Multi Manufacture Pre-Activation Utility

354 posts in this topic

OEMScan v1.4.1

OEMScan automates multi-manufacture installation Windows XP/2003 CD's by

scanning the bios (0xE0000-0xFFFFF) for a Royalty OEM's SLP string

and copying over the appropriate OEMBIOS files for windows XP activation.

Features:

1. Scans BIOS Memory for a specific string within a customizable range.

2. Validates the OEMBIOS file set by checking the BIN/SIG/DAT hashes against the CAT file.

3. Can run a program/script and pass a custom argument for each OEM allowing you to further customize the installation.

4. OEMBIOS files pass Microsoft’s WinTrust Validation when copied over.

New/Fixed in 1.4.1

Added more descriptive error messages (File Missing) & Dry Run Warning message

Changed Copy/Import order, Imports CAT first, copies second.

Fixed Bug CMD would still run if OEMBIOS files are corrupt

Fixed Bug Dry Run would copy files.

New in 1.4.0

Windows 2003 support

For OEMBIOS files and SLP ID's check out Bazalel's OEMBIOS repository:

http://www.oembios.net

For Multi-Manufacture Activation Discussion

http://www.msfn.org/board/index.php?showtopic=71016

oemscan_v1.4.1.zip

Edited by xehqter
1

Share this post


Link to post
Share on other sites

GREAT Tool, really!

Could you make it so that one can add additional files to the specific ini entry? For example for the oemlogo.bmp etc.

Also would be nice if the program could reply with return codes and a parameter for "do nothing but return code". This way one would know, if there has been a match and matched to what but don' t copy anything for the moment. :w00t:

Or make it open-source :thumbup

0

Share this post


Link to post
Share on other sites

I’ll work on it over the weekend. Currently the copied OEMBIOS files fail WinTrust. I’ll add a parameter to run a program/script for each OEM. That way you can copy/run whatever OEM specific files over that you want.

I plan on open sourcing it since I have no intention of maintaining it once all the bugs are worked out.

If I remember correctly it returns a value of -1 if there is no match and 1 on a match.

0

Share this post


Link to post
Share on other sites

So does this software means all your computers that are legally licensed but if one computer goes rebel (you know replacing messed up Bioses) you don't have to activate each reinstall.

Yeah I hate that when you have to reactivate each time you reinstall because if you get viruses or attacks constantly Microsoft will think you're giving it to tons of people. They thought I did that and I think they started attacking my computer as revenge against the pirates game they play.

I search, and try all these tricks to try to fix my computer to where I don't have to keep activating.

Why can't I just activate once and then it locks a file onto the Bios and when you reinstall your retail XP you just reinsert that file in your retail copy and it will know you already activated and your done. No Microsoft Hacking your computers, No activating constantly, and No constant activation.

Edited by SammyDawn
0

Share this post


Link to post
Share on other sites

No, it means if your motherboard is from a Royalty OEM (Dell, Gateway, HP, IBM, etc) and you acquire the correct OEMBIOS files with a Royalty OEM CD Key (not the one on the side of your case) it will convert your OEM copy to a Royalty OEM copy bypassing the need for activation. As-If you had used the Royalty OEM’s recovery cd to install windows XP.

The idea is IT guys & Repair Shops which handle multiple brands of computers don’t have to spend 6minutes on the phone to activate windows if they’re installing on a Royalty OEM’s system.

Think of it as a System Restore CD for multiple brands of computers.

0

Share this post


Link to post
Share on other sites
The idea is IT guys & Repair Shops which handle multiple brands of computers don’t have to spend 6minutes on the phone to activate windows if they’re installing on a Royalty OEM’s system.

Each time you burn a key, your story needs to get better and better to get another activation code which harms the customer. Has Microsoft specifically said that the store CD and the key from the side of the case is an acceptable equivalent to the original license? I've heard that it's not, which would make the multi manufacturer CD the only way that is both legal and practical for a shop to install Windows on Royalty systems. Anyone who thinks that asking the customer for Restore CD's is practical is smokin stuff that only Bill G can afford.

Edited by severach
0

Share this post


Link to post
Share on other sites

Version Bump...

Or to wait 15 minutes on hold only to get disconnected.. arggg.. tip: use the number pad to enter your responses, do you want to activate XP, 1, are you in front of the computer, 1, enter product id, 12345…

0

Share this post


Link to post
Share on other sites

I'm testing out your project now. ;) I'll let you know how well it works for me. :) I think with your wintrust trick your tool way outdoes mine. ;) lol! I think I may discontinue my tool for now and just use yours.

Thanks. :thumbup

BTW I found a typo in your ini:

;
; Toshiba OEMBIOS Files CRC32 = E4143622
; SLP = Toshiba
;

E4143622 is obsolete. ;) It should read this now:

;
; Toshiba OEMBIOS Files CRC32 = A16F9D62
; SLP = Toshiba
;

Edited by Siginet
0

Share this post


Link to post
Share on other sites

If you have one "master" install source this should copy the correct files over, but how will the SLP keys, that match the oem files, be applied in a multi-cd setup unattended?

Can one use a generic key in the main setup winnt.sif and then use/modify this M$ key change vbs as the extra command inside oemscan.ini to apply the matching slp key once oemscan is executed?

http://support.microsoft.com/kb/328874/

Also, where in the setup process should oemscan.exe be ran? Meaning, Winnt.sif, etc

Edited by Randy Rhoads
0

Share this post


Link to post
Share on other sites

@ Siginet

Thanks for spotting the typo. I’ll add a scan range but I want to know more about OEMBios files before I do it. I don’t want to add a feature only to find out its being implemented incorrectly.

@ Randy Rhoads

I don’t see why you can’t run it anytime during the setup. Personally I’m running it via svcpack. I’ve been using the DELL Royalty OEM key and it hasn’t complained. If you think it might be an issue you should be able to run a vbscript via CMD and change the key for each OEM.

0

Share this post


Link to post
Share on other sites

@Randy Rhoads

Keys are Interchangable,

I dont think it could run anytime during the setup,as Windows Setup asks (checks) for valid key on a earlier stage then oemscan can be run, either with cmdlines or via svcpack.

You could change it afterwards using MS own KeyUpdate tool, or run a vbscript via CMD at t13

Edited by FreeStyler
0

Share this post


Link to post
Share on other sites
I’ve been using the DELL Royalty OEM key and it hasn’t complained.
Kool, i knew setup would'nt complain, but a future WGA update might.

Example: Future WGA update expects slp oem files, slp key, specific bios string/s, motherboard type, etc to match or throw a non geniune report.

or run a vbscript via CMD at t13

I thought svcpack was executed at the T13 stage.

0

Share this post


Link to post
Share on other sites
I’ve been using the DELL Royalty OEM key and it hasn’t complained.

Kool, i knew setup would'nt complain, but a future WGA update might.

Example: Future WGA update expects slp oem files, slp key, specific bios string/s, motherboard type, etc to match or throw a non geniune report.

or run a vbscript via CMD at t13
I thought svcpack was executed at the T13 stage.

True, anything’s possible.

just to clarify, when I said CMD I meant in the oemscan.ini file

[Compaq]

PATH=".\Compaq\"

CMD="%SystemRoot%\notepad.exe" <--- insert VBS script here.. or create a batch file with the VBS script and put it here.

0

Share this post


Link to post
Share on other sites

Actually Randy I was going to play around with the same thing. I think maybe xehqter could allow a special string to be specified in the cmd= key that way if his tool sees that string then it knows to send the bios string that is found to the cmd. For instance:

CMD=".\keychange.exe" @Bios

Could return:

CMD=".\keychange.exe" Compaq

Then keychange.exe could be a tool that will change your key according to the manufacturer code sent to it. ;) If a manufacturer code is not found then it can open a box asking for a valid key on first boot.

I can make the keychange.exe if needed. ;)

0

Share this post


Link to post
Share on other sites
I can make the keychange.exe if needed.

Sounds good. Here is something weird though. In my HP MCE install i was following the manual steps to change a vlk key from that link i posted and i changed a oobetimer value in the registry to de-activate windows.

Next step was to run "%systemroot%\system32\oobe\msoobe.exe /a" so you can choose to update the key. Well, the registry value change didnt de-activate Windows and still showed as activated when i ran msoobe /a command.

The magicjellybean key changer wouldnt change it ither. Is this feature only for a vlk install?

Edit: Also tried M$'s new keyupdatetool.exe and it gave a "Must be ran on a supported version" error.

Edited by Randy Rhoads
0

Share this post


Link to post
Share on other sites

ToDo list:

1. Suggest using A16F9D62 instead of E4143622 in oemscan.ini - DONE

2. Variable to pass Bios Match

Workaround: run a different copy of a script for each OEM instance via CMD in oembios.ini) - DONE

3. Change CDKey

Workaround: run a script to change the CD Key via OEMSCAN.INI

4. Dry-Run (doesn't copy files) command line argument

Scan a Specific Range

5. Add option to specify exact range to scan - DONE

6. Fix Bug: Original OEMBIOS.CAT backup file isn't deleted from %Systemdrive% - DONE

7. Delete dllcache\OEMBIOS.CAT - DONE

8. Fix Validation Bug - DONE

1, 2, and 4 should be easy.. I’ll definitely include them in next weeks release.

Edited by xehqter
0

Share this post


Link to post
Share on other sites

Jellybean uses the Microsoft script, check the help. The scripts only support VLK->VLK changes. KeyUpdateTool is the only known tool that can change anything better and so far it's QOS record is poor. KeyUpdateTool doesn't support MCE at all, which means that there are no changes to MCE that KeyUpdateTool is authorized to make. I think it's mainly a VLK -> Retail key changer.

>Well, the registry value change didnt de-activate Windows and still showed as activated when i ran msoobe /a command.

Activation is calcuated only during WinLogon. The status is maintained until another WinLogon.

0

Share this post


Link to post
Share on other sites

@severach

::confused::

I was planning to implement it with WMI in C++ (same method as SP1 VBS script). I’ve used jellybean numerous times in OEM <-> OEM, OEM->ROYALTY, ROYALTY<-OEM situations. It would be somewhat redundant to use my application on a VLK CD.

I'm not going to worry about MCE at the moment.

Edited by xehqter
0

Share this post


Link to post
Share on other sites

This method works to change the key here, verified with magicjellybean, but one would have to have a reg for each key unless someone knows how to convert the key to the digital id without changing all the kieys manually which i was gonna try but not getting anywhere. I also ran the magicjellybean on a Toshiba OEM Pro i have on Virtual PC with the same error message i got from MCE.

I'm using the latest version 1.51.

HP MCE Reg:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WPAEvents]"OOBETimer"=hex:ff,d5,71,d6,8b,6a,8d,6f,d5,33,93,fd

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion]

"CurrentBuild"="1.511.1 () (Obsolete data - do not use)"

"InstallDate"=dword:44e4d5c0

"ProductId"="76487-OEM-0011903-00803"

"DigitalProductId"=hex:a4,00,00,00,03,00,00,00,37,36,34,38,37,2d,4f,45,4d,2d,\

30,30,31,31,39,30,33,2d,30,30,38,30,33,00,2d,00,00,00,41,32,32,2d,30,30,30,\

30,31,00,00,00,00,00,00,00,c6,9d,2f,0e,00,58,a1,02,03,41,ff,5b,44,75,01,00,\

00,00,00,00,e0,9d,e4,44,60,bb,00,00,02,00,00,00,00,00,00,00,00,00,00,00,00,\

00,00,00,00,00,00,00,00,00,00,00,35,36,38,32,31,00,00,00,00,00,00,00,a0,16,\

00,00,3d,9f,1a,00,00,02,00,00,e9,17,00,00,00,00,00,00,00,00,00,00,00,00,00,\

00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,db,27,be,d6

0

Share this post


Link to post
Share on other sites
Actually Randy I was going to play around with the same thing. I think maybe xehqter could allow a special string to be specified in the cmd= key that way if his tool sees that string then it knows to send the bios string that is found to the cmd. For instance:

CMD=".\keychange.exe" @Bios

Could return:

CMD=".\keychange.exe" Compaq

Then keychange.exe could be a tool that will change your key according to the manufacturer code sent to it. ;) If a manufacturer code is not found then it can open a box asking for a valid key on first boot.

I can make the keychange.exe if needed. ;)

Sounds great to me! :)

Is there a way to add detection for what version of XP is being used? maybe another switch on that that would insert a different key that is provided depending on if it is HOME or PRO or MCE... for those of us who like to be legit? ;)

0

Share this post


Link to post
Share on other sites

>I’ve used jellybean numerous times in OEM <-> OEM, OEM->ROYALTY, ROYALTY<-OEM situations

I'm told an old version of Jellybean will change a lot more than the new one. I never tried to figure it out.

@Randy Rhoads

Have you checked your DigitalProductID tests with MGADIAG to ensure that there is no diagnostic?

>for those of us who like to be legit

??? It's not a matter of being legit. You must have a key that matches the version you're installing. For those of us who want to be super legit, we want the correct Royalty key to match the hardware. Deploying one key set to all hardware is the right way for a smacked bottom, just as the keygen'd VLK keys have turned out to be.

Edited by severach
0

Share this post


Link to post
Share on other sites
I'm not going to worry about MCE at the moment.

Should'nt have to. MCE uses the same files, just have to use a specific setuup.ini pid value, the MCE cab files directory in the source root, and a MCE slp key.

Ive tried every keychanger i can find; MagicJelly, keyupdatetool, rockxp, keyviewer, and some others and nothing will change this key. I even edited oobetimer with all values of "FF" rebooted and it was still activated. The only thing that will change my key is that reg file.

Edited by Randy Rhoads
0

Share this post


Link to post
Share on other sites

I asked siginet about this, and his board pointed me this way. Seems like this implementation might make this a little easier...

would it be possible to add support for royalty AND non-royalty oem licenses? So if it failes to identify a SLP, it defaults to the last entry. Here, you could copy the oembios files from the real XP OEM disk, and run a script that prompts for the serial on the sticker. For example:

[iBM CORPORATION]

PATH="\IBM\"

CMD=""

[TOSHIBA]

PATH=".\TOSHIBA\"

CMD=""

ELSE

PATH=".\OEM"

CMD=".\PromptForChange.exe"

on another note...

I've already created a .vbs script that changes the key that takes a file (containing a key) as an argument. it works successfully in sp2 to change my key. For example:

cscript changekey.vbs "..\dell\serial.txt"

would this work for this project?

then we could have this entry:

[DELL]

PATH=".\DELL\"

CMD="cscript changekey.vbs "..\dell\serial.txt""

Edited by TheUni
0

Share this post


Link to post
Share on other sites

Sounds nice, right now I’m busy disassembling Microsoft’s Genuine Advantage code to better understand how OEMBIOS files work, I don’t have much time to add it.

If you want a quick hacked solution.

[AMI]

CMD=".\PromptForChange.exe"

[AWARD]

CMD=".\PromptForChange.exe"

[PHOENIX]

CMD=".\PromptForChange.exe"

put at the end of the oemscan.ini file will have the same effect as ELSE :)

0

Share this post


Link to post
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.