Siginet

With xehqter's permission I created some OEMScan Integrator addons for the members here. http://siginet.ryanvm.net/forum/viewtopic.php?t=61 Enjoy! And please help by shareing some more OEMScan Addons by studying how I made these. They are very simple to create.

Hey xehqter... Do you mind if I post some Integrator addons on my forum using your oemscan tool? It will make it much easier for people to use your tool. I think oemscan has pretty much made my tool, ("The OEM ACT") obsolete. Honestly I think oemscan is pretty much perfect the way it is now. @discountpc I think the script TheUni is making will be exactly what you want. At least that is what it sounds like to me.

Each pack specifically asks for a $OEM$ folder. You can use as many different $OEM$ folders as you want.

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.

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 ;

Yeah that is very cool!

I think it would be a good idea for us to team up and put our ideas together. So the wintrust... this will actually make it so the files are protected by WFP? @Everyone can someone with the ability to read chinese grab that OEM XP tool and begin recording the areas of the bios that we need for each manufacturer? Then maybe post your findings somewhere to help us out? BTW Why would someone want to wait for vista before releasing something like this? Were you kidding FreeStyler? Or are you serious? lol. We need a tool like this asap. My job is so much easier now that I don't have to activate over the phone so much.

Yeah I think that both Gateway filesets will activate most gateway machines. But it is my understanding that each set contains at least 2 specific instances of Gateway that are found in a different section of the bios which is specific to each fileset. We need to find out what Gateway computers are specific to that area and make sure that our tools know to look in those specific areas for those specific filesets. That's why I think the Gateway/EMACHINES fileset should be the one we use for now... until we come across a Gateway that does not activate and we record the area of the bios it is found in.

Hmmm... that's odd. Can you try the version I just released. I fixed a couple small bugs I found after release. Maybe that fixes your issue too. Make sure you delete the GetSystem.ini as well. It's possible I messed up the code. I don't have many computers to test this on. It should search for these 2 strings on your computer: MEDIONPC,MEDIONNB Thanks Edit: actually I am pretty positive it was one of the bugs I fixed. Please try the new one. Edit2: Grrr... I made another small bug in the last release as well. Sorry... Please download agian. lol. I accidentally made it put too much info in the log file. It gets all the needed info but it also throws a bunch of crap into the log. This version seems to work right. Edit3: I have also updated my OEMBIOS.EXE v0.3 tool. It is now possible to specify an exact area to search the bios for a string.

OK I finished creating a tool to allow someone to easily scan their system and collect any locations of bios strings. I recommend having this tool placed at the top of this thread so others can easily find it and use it. It will help us gather much needed info so we can better our tools. GetSystem.exe Edit: I just made a few changes dealing with spaces as the first or last characters of the string. So if you just downloaded this within the first 30 mins of release please redownload.

I think that is what everyones problem is. That's why we all have to work as a team. We don't all have access to every computer so we need everyones help. I think I'll put together a new tool that will help output some vital info that we need. Since the project has significantly changed in the way it finds the system info. For the most part the project will work fine. It is mainly the Gateway filesets I am concerned about. It is not very possible for us to use both filesets right now because we have no way to differentiate them when checking the system. So I would recommend everyone use the Gateway-Emachines fileset to give you the best so far. But if you have a Gateway System that fails we need you to get the debug info. That also goes for any computer that fails when you feel like you are using the correct filesets. It is possible that some of these filesets are very specific to where they search for the strings. I want to make a tool that not only finds the correct manufacturer of a system but also will scan the computer for the debug info we need. That way when people post info here we will have a better outlook on what we should actually be searching for in the bios.

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.

As far as I know there usually isn't an issue when using both together. But I would use nLite last when removing things. If you think about it, it sounds logical. Cause you can't remove what hasn't been integrated yet. But what you do is up to you. Trial and error. Whatever works best for you. Once you have a working method then stick to it. Good luck.

Personally I would use the DP Base to integrate the drivers. In my opinion the integrator is better at integrating things to your disk than nLite... but that is my opinion. Whereas nLite is much more superior when it comes to removing things. But as far as the DPs go... the DP Base is the way to go. In the integrator you can use the advanced tab to call the dp base after you finish an integration. Just search my forums for driverpacks. http://siginet.ryanvm.net You can still use nLite as the last step if there is something else you need to remove. I'm going to try to release a new Windows XP PowerPacker soon to fix a few minor bugs. But nothing much to worry about yet. Just make sure PowerPacker is copying your IDENT files to each Pack and to the root. In certain cases the current powerpacker is forgetting to do that. P.S. Fans of PowerPacker love the fact that it easily chains together with the integrator as well.

If you delete the LANG folder and the WINNTUPG folders you will save a lot of space. If your file size is over a gig something is wrong. What method of DPs are you using? You should use Method 2... especially for multiboot disks. I have made planty of multiboot cds with the DPs. If you still can't fit them then you should use less DPs... but they all should fit fine. Maybe remove the third party DPs? I'm not sure why your driver.cab is different. Maybe nLite modifys something in driver.cab for each disk? I am not really good at troubleshooting nLite. Are all of your disks integrated in the exact same way? Same ServicePacks etc?

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?

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?

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?

I got it working now. I used the stdout trick. Works well too. I am doing some tests now. I should have another release soon. Edit 09-15-06: I just released v0.2. I now have the program searching for the bios strings instead. I have successfully tested it on A new Dell Dimension, an old dell dimension, A new Compaq Presario, an old Compaq Presario, an Emachine, a Gateway, and an HP. all with success! Much thanks to Bezalel and FreeStyler!

That is what I was going to try next. I wanted to see if there was a simpler way though. Thanks for the input.

hey is it possible to use debug in one line of code instead of just opening debug and getting to the - prompt... then typeing S F000:0000 FFFF "Pavilion" I want to do something like: Debug S F000:0000 FFFF "Pavilion" It doesn't seem to work that way though. I want to implement this into the oembios.exe I made. BTW is it possible to use Debug within detached program?

OK... as promised. I finished creating some RVM Integrator addons using my version of this project. Please feel free to check it out here: http://siginet.ryanvm.net/forum/viewtopic.php?t=52 I decided to call it: Siginet's OEM ACT OEM Activation Control Technology Sounds cool I think! LOL! The tool will be changed as better methods are thought of. But the way I coded it so far seems to work pretty well and leaves room for users to customize and make their own addons to share for others. This project is very confusing for most people... so I think these addons will help others get a chance to use it and help them understand how it actually works. thanks again Bezalel! BTW... please discuss my version of this project in the thread I just posted to keep Bezalel's thread clean. And keep the System info coming folks! This project will only get better with more system info posted.

My version is based off of his initial release.... so it would probably have the same issues. But it will still be a work in progress... So if a workaround is found... then it will get implemented. I do not want to bombard this thread with my version of this project though (as requested by Bezalel)... so let's keep the questions about it to a minimum for the time being. Once I release it I will post a link to my thread about it. I will also post a small tutorial on how people can make more Pre-Activation Addons.

Bezalel just gave me the ok to release a version of this project that I put together based on his ideas here. Thx Bezalel! It shouldn't be much longer and I will have something put together. It is almost finished... but I have a little more tweaking to do on it. The method I will be working on will be fully functional with the integrator. I will be releasing integrator addons that will set up your disks with the manufacturer oembios files.

The next version will be 8.3 compliant, the files will be in directories named according to the CRC32 hash of the CAT file at the same level as the program file. If I ever deside to make archive files of the directories I'd use CAB because it's the easiest format to implement. I can understand the choice to use cab files. It's not like 7zip or rar will be able to compress much more on these files anyways. In the mean time do you mind if I put something together for people to use? vbs is much smaller in file size... but I am not very good coding in vbs. I also have managed to make some RVM Integrator addons that simplify the process of adding some of the manufacturer oembios files. I'll try to release a couple of them soon... it should give others a clearer idea on how this all works. Edit: Bezalel has asked me not to release any modified code. So I respect his wishes and I will not. Impatiently waiting for your next release Bezalel.