[xehqter]

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/...showtopic=71016

Attached File(s)

•  oemscan_v1.4.1.zip (23.43K)
  Number of downloads: 6813

This post has been edited by xehqter: 03 February 2007 - 10:46 PM

[vpn-user]

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.

Or make it open-source

[xehqter]

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.

[xehqter]

new version bump..

[SammyDawn]

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.

This post has been edited by SammyDawn: 17 September 2006 - 10:42 PM

[xehqter]

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.

[severach]

xehqter, on Sep 18 2006, 09:58 PM, said:

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.

This post has been edited by severach: 19 September 2006 - 04:15 PM

[xehqter]

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…

[Siginet]

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.

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
;

This post has been edited by Siginet: 20 September 2006 - 02:19 AM

[Randy Rhoads]

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.micro....com/kb/328874/

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

This post has been edited by Randy Rhoads: 20 September 2006 - 11:45 AM

[xehqter]

@ 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.

[FreeStyler]

@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

This post has been edited by FreeStyler: 20 September 2006 - 11:09 AM

[Randy Rhoads]

Quote

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.

Quote

or run a vbscript via CMD at t13

I thought svcpack was executed at the T13 stage.

[xehqter]

Randy Rhoads, on Sep 20 2006, 01:24 PM, said:

Quote

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.

Quote

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.

[Siginet]

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.

[Randy Rhoads]

Quote

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.

This post has been edited by Randy Rhoads: 20 September 2006 - 01:43 PM

[xehqter]

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.

This post has been edited by xehqter: 30 September 2006 - 10:24 PM

[severach]

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.

[xehqter]

@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.

This post has been edited by xehqter: 20 September 2006 - 05:01 PM

[Randy Rhoads]

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:

Quote

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