Multi Manufacturer Pre-Activation

[Bezalel]

I found an old Dell Dimension that doesn't preactivate for me. I have tried with the old method and the new method I put together with the same results.

Manufacturer: Dell Computer Corporation	  
   Model: L433c						  
   44656C6C 20436F6D 70757465 7220436F 72706F72 6174696F 6E202020 202020

SLP=Dell Computer

Debug.exe:

-S F000:0000 FFFF "Dell Computer"
F000:0EDF
F000:0FE0

With my new method it ends up finding a match and copying over the B6F0EEFD oembios.* set. Which is supposed to be correct right?

Every Socket 423 (P4) or later Dell activated for me. I've had mixed results on Socket 370 (P3) based Dells. (I never got a Dimension L Series to preavtivate.)

[Bezalel]

OK cool. As long as it wasn't our scripts that was the issue. That was my main concern. Thanks for the info.

Another question...

Is the Gateway fileset A04597C6 still needed? Since now we have a Gateway/Emachines fileset.

My question is... if A04597C6 is still needed we may need to find the best way to have it implemented since both filesets look for the string "Gateway". Is there a different area of the bios it searches for the string then the emachines fileset?

Yes it is still needed because of the ranges they look in. Each of those filesets have 23 entries, 21 of the entries are in both sets but there are 2 unique entries in each of the sets.

[Siginet]

OK... so as I understand it we need to have our scripts look in specific ranges to be able to differentiate which Gateway fileset to use? Do we have some sort of record of the areas that are specific?

I don't have any Gateway computers to test with at the moment.

Should I add a way for the user to specify a range in the ini file for specific strings?

It shouldn't be too hard.

It looks as if Gateway is the only fileset so far that has this issue?

[FreeStyler]

New SLP BIOS Strings added to post #202

• ACER TRAVELMATE (OEMBIOS CRC=700A8481)
  
• ELITEGROUP (OEMBIOS CRC=8EE1223C)
  
• SYSTEMAX (OEMBIOS CRC=9509CAD5) thx, Randy
  
• LG (OEMBIOS CRC=8D3A3465) thx, nadav
  
• AMOI (OEMBIOS CRC=3A887CB8)
  
• FUJITSU (OEMBIOS CRC=BACB9A77)
  
• FUJITSU SIEMENS (OEMBIOS CRC=10045CFA)
  
• GREATWALL (OEMBIOS CRC=47E62C15)
  
• Matsus***a (OEMBIOS CRC=89799F58)
  
• Legend (OEMBIOS CRC=AA3E00F6)
  

Edited September 26, 2006 by FreeStyler

[Randy Rhoads]

Systemax

Manufacturer: SYX

Model: snc302eeh

535958

[xehqter]

New version of my OEMSCAN utility.

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

Thanks for telling me about the KeyUpdateTool severach. The new version passes WinTrust. Per request it now supports per-oem commands so you can write a script to copy over oem specific files (ie:oembios.bmp) . You can also use OEMSCAN to run scripts for a specific OEM without copying over the OEMBIOS files.

All kinds of fun stuff.

[nadav]

Manufacturer: LG Electronics

Model: K1-323EE

4C472045 6C656374 726F6E69 6373

whom do I send the OEMBIOS.* files to? (and how?)

[vpn-user]

OK We have bezalel' s rapidshare repository and Freestyler' s list of Strings (and missing files therefore). Could we establish a place where we can get everything together? I mean the files (including oemlogos), SLP Strings and Product-Keys? That would be great. Since bezalel is already a rapidshare user it would make sense to just complete his repository.

What do you think?

I also have another question: Why are there so many comma separated, same entries in the SLP Strings list? I mean, why is it 'Gateway,Gateway,Gateway...etc'? Or why 'AcerSystem ,AcerSystem' (whitespace)?

OEMSCAN does only need one of these, nor? At least in the example ini.

Edited September 17, 2006 by vpn-user

[Siginet]

I'm not positive why there are multiple instances of the same bios string... But I think it means that is how many times that string is found in different areas of the bios. Like on one gateway the string may be found in one area where in another gateway it may be found somewhere else. I think eventually we may need to make our tools search in specific areas of the bios for a string. We have two seperate Gateway filesets. Which means some gateway computers will not preactivate when using only the Gateway/EMachines fileset.

If you have a gateway that doesn't preactivate.... please use the debug commands here and post your details. If we know the exact area in the bios to look we can add that to our projects.

In a later release of my "OEM ACT" I plan on giving the option to specify an exact location in the bios to find a string. I also am going to give the option to use multiple manufacturer files and windows keys... so on a dell system a dell OEM Key is used and Dell specific files are added to the system. xehqter beat me to some of that. But it was on my list of things to do. My idea is to allow a user to have an *.ini file in the directory with each oembios.* fileset that is used for manufacturer specific stuff.

Edited September 18, 2006 by Siginet

[Bezalel]

OK We have bezalel' s rapidshare repository and Freestyler' s list of Strings (and missing files therefore). Could we establish a place where we can get everything together? I mean the files (including oemlogos), SLP Strings and Product-Keys? That would be great. Since bezalel is already a rapidshare user it would make sense to just complete his repository.

What do you think?

I also have another question: Why are there so many comma separated, same entries in the SLP Strings list? I mean, why is it 'Gateway,Gateway,Gateway...etc'? Or why 'AcerSystem ,AcerSystem' (whitespace)?

OEMSCAN does only need one of these, nor? At least in the example ini.

I try to keep my RapidShare folder complete but some of the less common files are getting dropped by RapidShare.

There are actually 23 seperate memory locations searched for for Gateway and the Acer string has whitespace in it.

[xehqter]

I inserted the following strings into the bios to and used MGADiag to see if they pass, here are the results.

CRC32: E161F004

SLP: " FUJITSU SIEMENS, FSC SYSTEM, FSC SERVER, FUJITSU SIEMENS"

Test 1: "FUJITSU SIEMENS" - FAILED

Test 2: "FUJITSU FUJITSU" - FAILED

Test 3: "FSC FUJITSU" - FAILED

Test 4: "FSC SERVER" - Genuine

Test 5: "FSC SYSTEM" - Genuine

Test 6: "FUJITSU SIEMENS FUJITSU SIEMENS" - Genuine

Test 7: "FUJITSU FUJITSU SIEMENS SIEMENS" - Genuine

Test 9: "FUJITSUSIEMENS fujitsu siemens" - Genuine

Test 8: "FUJITSUSIEMENSfujitsusiemens" - FAILED

Test 9: "FUJITSUSIEMENS fujitsusiemens" - FAILED

FUJITSU SIEMENS x 2 Works

FSC SYSTEM x 1 Works

FSC SERVER x 1 Works

Interesting results

BTW: E161F004 is listed with the wrong SLP

<SLPBIOS> FUJITSU SIEMENS, FSC SYSTEM, FSC SERVER, FUJITSU SIEMENS</SLPBIOS>

Edited September 18, 2006 by xehqter

[xehqter]

Hmm, the SLP from MGADiag with A04597C6 is 'Gateway, Gateway, Gateway, Gateway' but putting it in the bios 4 times doesn't pass activation..

Edited September 18, 2006 by xehqter

[SammyDawn]

Can I PM you my COMPAQ Information.

All my Computers are licensed but one is stubburn with activation.

So I need to preactivate that one computer.

[Randy Rhoads]

Hmm, the SLP from MGADiag with A04597C6 is 'Gateway, Gateway, Gateway, Gateway' but putting it in the bios 4 times doesn't pass activation..

This was addressed earlier. MGADiag only shows the 1st 4 entries and the Gateways have around 23 in specfic areas. Testing with Dell's will give you simular results. Testing would require all the entries in the same areas that the manufacture uses.

You could debug a real Gateway bios that you know the files work on and then edit them into the areas, but who knows where area "E004" or simular are located. Is this a hexadecimal address, and if so, is the address located from an entire bios dump, or the value from just the dmi area of the bios?

** Edit, after thinking about it i believe i remember someone saying that these debug results are related to memory locations**

If it is memory locations, how does one determine what exact area of the bios this relates to if you had the Virtual Machine dmi loaded up in a hex editor?

Edited September 18, 2006 by Randy Rhoads

[severach]

>Thanks for telling me about the KeyUpdateTool severach.

SIGVERIF.EXE does the same thing but is slower and harder to use.

>Could we establish a place where we can get everything together. Product-Keys

Most forums have had to ban product key distribution. This includes illegal keys that don't even work like F C K G W, OEM SLP keys that are all the same, and anything else that looks like a key. We want Bezalel's repository to stay public.

>Why are there so many comma separated, same entries in the SLP Strings list? I mean, why is it 'Gateway,Gateway,Gateway...etc'

I couldn't get Dell or Gateway to preactivate with a DMI string. Many other companies with less SLP dups preactivate just fine with a DMI string. I figured it was because the companies with many SLP strings have very specific areas the strings must occur that I can't hit.

>But I think it means that is how many times that string is found in different areas of the bios.

>putting it in the bios 4 times doesn't pass activation

All strings can't be part of the requirements. Out of the shown SLP strings, my Dell has Dell System twice and Dell Computer 7 times. Dell System occurs one too few times and Dell Inc never occurs. Requiring all strings would fail both 87870F5A and 63875D1F. It pre-activates on either just fine.

>Test 1: "FUJITSU SIEMENS" - FAILED

>Test 7: "FUJITSU FUJITSU SIEMENS SIEMENS" - Genuine

>Test 9: "FUJITSUSIEMENS fujitsu siemens" - Genuine

I don't see how Test 1 could fail and Tests 7 & 9 could succeed. Ignoring the superflous data which confuses the humans but not the computer, in all these cases a specified string occurs exactly once. Test 9 has a less desirable case though case doesn't seem to matter.

>FUJITSU SIEMENS x 2 Works

According to Tests 7 & 9, FUJITSU SIEMENS x 1 Works too. Don't let your eyes fool you into thinking that the extra text has meaning.

>then edit them into the areas

You need to author your own BIOS or contract with a company that does to be able to control the position where a string shows up, something big companies can do that you can't. Unless you have that control, chances are that any address you would want to pick has something in it you can't overwrite.

>but who knows where area "E004" or simular are located? Is this a hexadecimal address, and if so, is the address located from an entire bios dump, or the value from just the dmi area of the bios

Google "NtLockRegistryKey Inside the WPA-CALL"

You'll need to read it out of the Google cache unless you can find the current AntiWPA site.