Daz, My last post was in response to Apokrif. I didn't see your post until after I posted, that's why I added the "EDIT". I saw the link you posted about five minutes after I read the first post in this thread. The first thing I did was Google it. You're right, it would probably take less than 5 minutes to remove that from a BIOS and reflash. I also found guides to disable it without even touching the BIOS. And I really don't have any problem with someone doing that for themself, It doesn't affect me one way or the other. I just know thieves tend to be lazy and won't take the time to learn to do it for themselves, if they can convince someone here to do it for them. I just like screwing with them to see if they are telling the truth about being the legitimate owner because they usually are not. I've had similar discussions a few times over the years and I have Never had anyone that actually owned the laptop legally ask this type of question.
I agree 110% with everything you wrote ! To Daz: thanks for the link too, I didn't know it was that easy (never need to disable it actually)
*** EDIT: *** The Post by fakerAOL that I was replying to has since been deleted. ^ Still attempting to Justify the fact that you steal laptops, I see. PS One Excellent reason to add SLIC 2.1 to a BIOS is that many OEM's do NOT have SLIC 2.1 in their Bios updates. Therefore when a user updates the Bios on a Legally purchased PC with Pre-installed Legally Activated OEM copy of Win 7, their copy of Win 7 will become un-activated. A SLIC 2.1 BIOS mod quickly and easily remedies that. You really should get your facts straight before attempting to enter into a debate. But as I have learned over the years, the average criminal is usually lazy and not very intelligent. And you are only helping to prove that this is still true.
Never stop fighting BTW: You (your posts here) are the only reason I didn't "release to public" simplified version of Dell BIOS modules manipulation tool
ok, back to topic: old versions of ibm/lenovo-phoenix-bios is simple to patch. all described by yen in this forum. new structure has no chaining, no jumpadress, only module after module and some gaps between. ich have changed Code: F8 00 8B 00 18 54 00 01 5F 4A 30 30 00 00 00 00 FF 00 00 00 00 00 00 00 to Code: F8 00 A4 00 18 54 00 F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 and filled with FF also Code: F8 00 42 03 B4 00 00 01 5F 4A 30 31 00 00 00 00 FF 00 00 00 00 00 00 00 changed to Code: F8 00 43 03 B4 00 00 01 5F 4A 30 30 00 00 00 00 FF 00 00 00 00 00 00 00 is this necessary? does it belong to the first one and should be removed too? and the two most important questions: pbe will not list the new gap, is that a problem? will the mod work this way or should i further investigate? (all infos found in this forum) another question: i have used the 8Mb X301 Bios from "5866-LENOVO-(IBM)-Bioses-especially-Thinkpad.". pbe 2.2.1.3 throws 31 errors about "duplicate property definition" and stops. is this related to the pbe-version or the file? EDIT regarding the old structure: why will offset 00172403 be shown as 0324F7FF instead of 03241700 ? something like realmode (im not familar with this) )
jumpadresses in old structure headers are first four bytes, little endian (reversed), thats simple to fix. on new structure bios i have filled the module-body of computrace (_J00) with FF, changed header to gap-header and fixed checksum. following module (_J01) renamed "_J00" and fixed checksum. andyP's tool will find the new gap in my hexedited biosfile, but will (in orginal bios file) not change module-header of emptyed (FF) module to gap. and pbe does not find the new gap, thus leading me to the question, if there is something additional to fix, or if i'm completely wrong with this way. and for knowledge only i'd like to know, why offset as little endian is written the way, it is. (if someone would explain.) if i did a big mistake with my ugly english, do'nt hessitate to tell me. Edit: your linked post i have already saved to disk ;-)
yen, there is something mixed up in your linked post: checksum1 is header-checksum and checksum2 is module-checksum right? but module-checksum with, or without(no) header? without, because else you have to recalculate booth checksums over and over, because one affects the other, right?
got it! # pseudocode # $physicalAdress[1=>0xFFF00000,2=>0xFFE00000,4=>0xFFC00000] $jumpAdress=littleEndian($offset + $physicalAdress[Round(fileSize($file,'Mb'))]) EDIT: is there any further knowledge about the old structure header? Code: 6F89F2FF 003131 00 4A 1B00 00000000 00540000 00540000 00600000 55AA 2AEB15 436F6D70755472616365 meaning of grouped bytes: (1 to 9 = header, 10 to 12 modulebody) 1 jumpadress (pointer) to next module + physicalAdress , littleendian (reverse order) 2 static code 003131 (format of header) 3 module number 4 ? (modulename? 4A => MOD_4A00.ROM ? ) 5 1B00 seams to be static value 6 ? (always zero in my case) 7 possibly size of module? (littleendian, matches exact in my case) 8 possibly size of module? (again? always equal to 7) 9 ? (most times equal 7 and 8, but not on computrace-module) 10 startbytes of modulebody 11 ? 12 string "CompuTrace" 4 to 9 and 11 are unknown. any explanations?
Not mixed up, but confusing... Simplified structure: F8h, 00h, sum1, sum2, partial header, module body. Offset 0, 1, 2, 3, partial header, module body. Both checksums are independent to each other. When you append two sections which both sum to zero, the entire block (module) will sum to zero as well. Yes, checksumbyte 2 has to be set that the moduleBODY (no header) sums to zero. It is dependent on the module body only. And: checksum2 IS equal to the (result) of the 8 byte checksum of the header without byte1 and byte2 (F800), means byte 3 to 18h, also byte2 to 18 since the zero byte at offset 1 doesn't change the result. (do not confuse the description of the byte and its ways to calculate.) Checksumbyte 1 has to be set that the ENTIRE module (with header) sums to F8h or without the F8h byte that it sums to zero. Means has to be set that the sum of the partial header sums to zero. It is dependent on the partial header only. Checksumbyte 2 together with the moduleBODY already sums to zero. checksumbyte1 can be calculated: -8 bit checksum from offset 4 to 17h (byte5 to end of header, partial header), operate NOT plus 1 or as described already: -8 bit checksum from offset 3 (checksum2 included) to end of module, operate NOT plus 1 (set that the entire module sums to zero..entire because the zero byte at offset 1 does not change the sum.) Regarding removing of modules (new structure): I don't know if you have to insert a gap instead of, also I don't know if you have to change the module index of the following module, I guess it should be remained. What I know is that if you replace a original module with one that is smaller in compressed size after its modifications, you just can pad the excess of space with FFh bytes... I know when inserting a new module into a gap, the gap has to be corrected since its size has decreased. I could imagine it would work by just removing (replacing with FFh bytes) of the module.. Can you recover your bios? Alternatively try: Use PBE to decompose the bios, delete the computrace module from the temp dir of PBE module and edit ROM.SCR with notepad (remove the line of the module). Change something unimportant at PBE and re-set it to make you able to let PBE rebuild the bios. Check the rebuilt bios for analysis...... btw: No problem to PM me about, but I'm very busy and it is a long time ago since I have analyzed phoenix bioses.....
with pbe only works on 4mb files, with the 8bm rebuilding wo'nt work: a.t.m. i own only a thinkpad x60s (old structure bios). i continue resarch ..
the rom.log shows no free space between end- and startadresses of the decomposed biosparts, witch follow each other. and biosparts with only FFh are the Gap*-files and the Hole11.ROM only. so all "free" (FFh) space in new structure seams to be filled with gap-modules. maybe they are registered like the romholes in the old structure.
Did you ever succeed in removing computrace? because i have a similar problem. I installed Windows 7 on my Compaq NC6400 notebook and sometimes my display driver will stop working and my mouse doesn't work like 75% of the time. I have to use an external mouse and pray for the graphics driver to work otherwise i get a really low resolution messed up looking desktop.
on dell inspiron 9400 and e1505 there was a bios bug in computrace with xp.. the svchost got corrupted by the "rootkit" of computrace rom .. worked fine in vista. symptoms were internet explorer crashing on fresh brand new 5 minutes used xp. confirmed by NOT disabling computrace in bios and reinstall xp and reoccurred. disabled computrace and reinstalled xp= didnt happen again. (multiple computers.. i was the one that brought it to attention to engineering when i worked there) dell released a bios 2 days later to fix " battery charge algorythm" or something.. the real reason was computrace and xp.
I recently purchased a nice Lenovo tablet laptop on ebay. I installed my own hard drive and installed updates and everything but I noticed Computrace was hiding in the BIOS. It creates files called 'rpcnet' and runs them with the Remote Procedure Call Service without your knowledge or authorization. I have stopped the service and deleted the files only to have them come back again and again. There appears to be no way to remove it from the bios, as they persist even after doing all the above and flashing the BIOS and re-doing in various different orders. The rpcnet program is identified by many antivirus softwares as a trojan. A trojan alert popped up when I first booted it with the original HDD in it and I disregarded the message because I thought it was just infected and I was installing my own HDD anyway so no big deal. Contrary to the misguided belief of the useless posts in this thread from NoJuan999, I did NOT steal this laptop. I've asked the seller if he can provide a receipt and am awaiting his response. I just bought it on ebay because it's a really nice convertible tablet model that I've had my eyes on for a while. I had no way of knowing it had Computrace embedded. I want to eliminate Computrace and have been searching all over to find out some way to accomplish this. Can anyone point me in the right direction at least? Like a BIOS editor or something? I bought the laptop used based on its capabilities and having something like this on it makes me very frustrated.
For those of you attempting to downplay the legitimate concerns by those of us who do not wish to have this software on our second-hand pc's, please see this article: zdnet.com/blog/security/researchers-find-insecure-bios-rootkit-pre-loaded-in-laptops/3828 The following article explicitly shows how the vulnerability is exploited. corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=publication&name=Deactivate_the_Rootkit I will try to find time to go through the various methods and if I am successful I will post back here.
have already done it on IBM x100e using allservice programmer interface, 24rf08 tools and Ibmpass wich is the hex editor. for this compter to didable computrace you have to read the eeprom (l08) that is similar to 24ps08 and mod the bin file by empty the line 0x310 with 0 binary.
I also found this on my new Toshiba. The easiest way to disable it is: find rpcnetp.exe in the system32, properties, security, change the system permissions to all deny. It won't run after that.