xehqter

Yes, I'm still alive, sorry for being AFK for so long. It looks like there is still activity for this project so I thought I'd ask, any new Feature Requests or Bug Fixes needed?

v1.4.1 is correct The corresponding decrypted lines in A04597C6 ("Gateway") are: BIOS18=F000,32F0,20,Gateway BIOS21=F000,3110,20,Gateway

OEMScan won’t work on Windows Vista. It uses a different method for SLP OEM Activation. I probably won’t have a working version for 6+months due to the lack supported OEM systems for me to test on. This is what I’ve gleamed from reading poorly translated Chinese pages. Please note there may be inaccuracies. In order for Vista OEM SLP activation to work the bios must have an SLP 2.0 ACPI structure which contains a public key that is signed by Microsoft. That public key is then used to decrypt the tokens.dat file. Each OEM will have a different tokens.dat for each version of OEM Vista. You must use a Vista OEM SLP key and it “may” be tied into the tokens.dat file (ie: Dell CD Key may be required for Dell Systems). I don’t know how large the tokens.dat file or what it contains.

In mgadiag.exe make sure Windows License Type is OEM SLP

ROFLMAO, FreeStyler you read my mind. Sounds like you have a few issues. 1. Within minutes of starting the OS it will start to harass you to activate, you should have investigated the issue then, not when the customer brought it back. Use MGADIAG if you want to be sure the system activated correctly. 2. If a system fails activation with SLP it doesn’t say, “This copy of Windows is already activated” it tells you that you have a bogus key and to use the key off the side of your case. It sounds like someone tried to crack their copy of Windows XP and it didn’t work. 3. As far as OEM SLP Activation goes, some dell laptops only activate with 87870F5A (Dell Quanta) and make sure your using the latest Toshiba fileset (A16F9D62).

The only time I’ve seen “A problem is preventing windows from accurately checking the license for this computer” in context to OEMScan is when I replaced the OEMBIOS files on a Volume License version of XP.

XP HOME/PRO/Media Center OEM editions all use the same OEMBIOS files. You can download oembios files from http://www.oembios.net

Windows XP and Windows 2003 OEMBIOS files use a different key to encrypt the data, file sets aren’t compatible. I assume Vista will be the same. If you want to do it I have no problem. You could write an oemscan.ini file with all the SLP Strings which executes an app w/ the CRC32 and generates an oemscan.ini file. Ie: [HEDYCOMPUTER] CMD=genini.exe 162C7931 Which then scans a directory tree for the CRC32 and generates a OEMSCAN.INI file [sM] PATH=".\162C7931\" I don’t think it’s worth the effort writing it. Essentially it’s for someone who knows what oembios files they need but are to dense / lazy to modify (or add) two lines in the oemscan.ini file. I think a well written guide would be more effective then writing an app to make things easy-ist-er. If you’re already distributing the oembios files and generating the oemscan.ini files on the fly with RVM Integrator what’s the point.

@Skawg I don’t think anyone has done that (bandwidth I assume), you can add multiple OEMBIOS RVM addon’s together to create that effect or download OEMScan and populate the directories with files from http://www.oembios.net @ZaForD No, we don’t need computer reports anymore. They don’t yield any relevant information since OEMBIOS files aren’t linked to DMI information, but rather memory ranges in the BIOS. If you come across any OEMBIOS file sets not listed on www.oembios.net you can submit them. With OEMScan & Siginet’s OEMScan RVM Integrator Addon’s the problem has been solved. I don’t think much has been done with Vista yet because to my knowledge no Royalty OEM’s have released Vista.

Just so I’m clear Are you: 1. using the same SLP CD Key for each OEM? 2. using a different SLP CD Key for each OEM? 3. #1 and #2 (IE: Use the same key for unknown OEM’s) At what point do you know Windows XP rejected the key? Does Windows XP prompt for activation? Where are you specifying CD Keys? (winnt.sif, setkey.cmd) At what point in the install are you running oemscan? OEMBIOS files have nothing todo with Windows XP accepting a CD Key. So standard rules apply. Either it’s a problem with the CD Key, the method you’re using to change the key, or the application changing the keys.

I doubt it but do me a fav and give me a dump with 1.4.1.

Good catch, forgot to remove that.. fixed and reuploaded. Yeah, odd, at some point I commented out the check for dry-run when copying files. doh.. coding while tired, bad idea.

Perhaps windows can't validate against .CAT files @ T39??Released a new version, nothing special, its a minor update

The hashes are correct, do you have the expanded oembios.* files in the GatewayC (or what ever directory its assigned to) directory?

Seems to work pretty well, no more errors due to Windows Server 2003 \Device\PhysicalMemory permissions On a fresh Windows Server 2003 R2 Standard installation "Windows File Protection" kicks in once when runing oemscan for the first time (just after replacing COA oemfiles with vendor specific server 2003 oembios files) When clicking "Cancel" and keeping the new files after reboot all seems to be ok. I could even run SFC /Scannow without the original files being restored, so that looks good as well UPDATE: When running oemscan on a fresh install of Windows Server 2003 Enterprise Edition with SP1 i didn't get the "Windows File Protection" dialog...(maybe something went bad the first time) I was worried the method I use to disable SFC in XP wouldn’t work in W2K3 however when I tested it with W2K3 R2 Standard Edition Service Pack 2 (Volume) it passed with flying colors. The method I use disables SFC for exactly 1 minute on specific files. Is it possible more then 1 minute elapsed between copying over the files and importing the .CAT file? Could you test it on more systems and get back to me if you run into SFC errors? Perhaps I should import the .CAT file first.

@Bezalel 'AMOI Electronics CO.,Ltd' requires the complete string. The comma doesn’t affect it. @All New official version, v1.4.0, I added Windows 2003 support. The same method should work with Vista, but that’s untested.

@FreeStyler Empty 3e value? If size is missing it defaults to 0x100 (hex) bytes, and yes it activates just fine.

by modifying the VPC Bios I found leading spaces in OEMBIOS.DAT are ignored. ie: ", FUJITSU" & ",FUJITSU" are treated the same.

Looks good, if your trying to save space I’d remove BACB9A77 (FUJITSU-PC) since it’s covered by D2D64C41 (FUJITSU). Well, almost covered, 0xE0000 – 0xEFFFF isn’t scanned but its very likely FUJITSU would be in 0xF0000 – 0xFFFFF either in the DMI tables or as a BIOS string. I’d also consider using 9CF90CA8 (FUJITSU-PC) over BACB9A77 (FUJITSU-PC) for no other reason then it’s available on oembios.net and not a private site. Both files are functionally identical. You shouldn't be concerned with leading or trailing spaces.

It’s because the file is formatted incorrectly. Each subsequent entry in the file starts with BIOS rather then BIOS0, BIOS1, BIOS2, etc. BIOS=f000,0000,ffff, FUJITSU BIOS=f000,0000,ffff, SIEMENS BIOS=f000,0000,ffff, PRIMERGY … It should be BIOS=f000,0000,ffff, FUJITSU BIOS0=f000,0000,ffff, SIEMENS BIOS1=f000,0000,ffff, PRIMERGY … I wonder how these files are generated because of the number of inconsistencies between vendors. I also noticed line returns for the OEMBIOS section are CR-CR-LF instead of CR-LF while the HashTable section uses CR-LF.

The OEMBIOS.DAT file contains a list of strings and memory addresses to check against in the BIOS. If any of them match then Windows knows it’s a legitimate royalty OEM motherboard. In your example there 18 different memory addresses that windows checks for the string “SNC302EEH”. You only need to list it once in your oemscan.ini file.

HP 00A1EECB ("Hewlett-Packard") is obsolete HPQ CD4E1902 ("Compaq", "Hewlett") replaced it. I removed it from latest version (1.3.2). http://www.oembios.net has all the current files (obsolete files have a line threw them)

Simple buffer overrun, if it matched a character at the end of the bios it would read the next character (overrun) and crash. When I get home from work I’ll make this the new official version. Thanks for your help. Edit: Official Version is up

Thanks for the crash dump. I think I found the bug, try this new version (1.3.2) out and tell me if it still crashes. If its fixed i'll make it the new official release. Edit: Official Version is updated to 1.3.2 download it from 1st post

what is the crash address? is it a sysprep image? are there any pre-installed programs? does it happen repeatedly on the same machine?