Patch EVE Online legt Windows XP plat

De op 5 december verschenen patch voor EVE Online bevat een regel code die het boot.ini-bestand van Windows XP verwijdert. De pc kan hierdoor niet meer opstarten waarna een bootdisk nodig is om het systeem te herstellen.

De patch voor het spel moest de vier jaar oude grafische motor vervangen door een nieuwe en de game zo voorzien van meer grafische mogelijkheden. Spelers hebben de keuze of ze de oude of nieuwe engine willen gebruiken. Gamers die de patch installeerden om de nieuwe engine te gebruiken, werden echter onaangenaam verrast.

Ontwikkelaar CCP bevestigt de fout op het officiële forum van het spel. 'Herstart de computer niet voordat je dit hebt gelezen', waarschuwt ontwikkelaar Pete Thacker in een posting, waarin hij linkt naar een supportpagina van Microsoft waar wordt uitgelegd hoe boot.ini weer hersteld kan worden. Gamers die direct de nieuwste versie van het spel hebben gedownload, zonder gebruik te maken van de updatefunctie, omzeilen het probleem, aldus Thacker.

CCP heeft de corrupte patch inmiddels verwijderd van zijn servers. Thacker geeft aan dat de studio werkt aan een oplossing en biedt zijn verontschuldigingen aan namens de ontwikkelaar.

Reacties (153)

[ReLexEd]

Iemand er al aan gedacht dat het misschien geen fluit te maken heeft met de daadwerkelijke patch, maar met de installatie hiervan?

Dus dat niet de programmeur hier volkomen onterecht virtueel gestenigd wordt, maar dat die kiezels eigenlijk richting de packager zouden moeten vliegen?

Er zijn bedrijven waar de programmeur geen r##t te maken heeft met de uiteindelijke installatie-routine van zijn/haar product...

[Verwijderd]

Dit is toch degelijk wel een syntax fout. Gewoon een .je vergeten en bam, daar gaat je boot.ini.

Heel lullige fout en ook niet iets wat je snel zal vinden tijdens het testen van zo'n patch, want dan wordt meestal gewoon gekeken of het spel nog draait en niet of de pc daarna nog reboot.
Ik denk overigens wel dat ze bij CCP vanaf nu af aan alle test machines rebooten voordat ze het als "ok" afstempelen.

[kmf]

De vraag moet meer zijn: hoe kan het zijn dat een patch een belangrijk bestand KAN verwijderen uit een OS?

[Oguz286]

Precies. Maar er bestaan ook zoiets als rechten, als ik als gewone user op linux iets aan het systeem probeer te veranderen dan lukt dat niet totdat ik super user wordt. Hetzelfde heeft windows ook, alleen als je het als administrator gebruikt, dan vraag je er ook een beetje om.

Nu weet ik niet of je boot.ini als gewone gebruiker kunt aanpassen (nooit geprobeerd), maar als je dat niet kan is het eigenlijk ook deels de fout van de gebruiker zelf.

[Deikke]

Leuk dat linux die beveiliging heeft, maar helaas zul je wel admin/root moeten worden om een patch te installeren (lees in de programma map iets te kunnen wijizgen), linux is net zo vatbaar voor zo'n simpele fout als windows.

Ik gebruik ook linux, en ook vul root (of sudo) wachtwoord in om updates te installeren.

[Hadron]

Vaak (in Gentoo iig wel) worden updates eerst in een sandbox gezet, en dan pas in je echte omgeving.. daar kan je heel mooi detectie toepassen.
Daarnaast kan je ervoor kiezen om /boot standaard niet te mounten.

Het blijft te omzeilen als je sudo/root-toegang hebt, maar het is toch net weer dat stukje lastiger en 't is weer net wat extra beveiliging tegen stomme fouten

[Bobco]

Gebruikersvriendelijkheid boot.ini zou natuurlijk alleen mogen worden aangepast door een administrator, maar we weten allemaal hoe de gemiddelde gebruiker XP gebruikt. Ik heb hier net op XP Pro even geprobeerd of ik zonder admin rechten boot.ini kon overschrijven, maar dat lukte niet. Wellicht zit er ook nog een verschil tussen FAT en NTFS installaties...

[XIU]

En jij wult als gewone gebruiker ook eens Office ofzo gaan installeren zeker?

[martijnve]

ja, alhoewel dit natuurlijk echt niet kan vanuit ccp vindt ik het wel vreemd dat dit zomaar kan in windows?

En ook raar dat windows dan niet standaard een boot.ini terug kan zetten als het dan weg is

[Verwijderd]

Idd, en Microsoft maar telkens zeggen dat Windows XP zo lekker veilig is, met een simpele JPG waar een batch in zit kun je de boot.ini verwijderen, en niemand zal er zo 1.2.3 achter komen wat de fout is geweest.

[Verwijderd]

Hoe kan het dat je boot.ini moet wijzigen voor zoiets? Het lijkt me dat hier een heel slechte programmeur aan het werk is geweest.

Ik kan me echt niets bedenken wat de opstart configuratie met de grafische engine van een spel te maken heeft.

[TERW_DAN]

Het heeft niets te maken met de boot.ini van windows, maar de game gebruikt ook een bestand dat boot.ini heet. Door een fout in de installer wordt niet de boot.ini in de gamedir weggegooid, maar op de root van de disk.

Sowieso slecht dat ze de naam boot.ini gebruiken, ik zou als programmeur altijd zorgen dat ik niet m'n bestanden net zo noem als de systemfiles van windows

[Verwijderd]

In de categorie "meest rampzalige bug aller tijden " scoort deze hoog. Zo'n blunder maak je zelden mee.

[Verwijderd]

Ik heb wel eens een bug gemaakt in een opstartdsikette die per ongeluk de hele hd formatteerde. (Dat was zo'n 13 jaar geleden)

[CaineTanathos]

door een \ ipv een .\ in de code te plaatsen
wel raar idd, dat ze zelf dit niet hebben voor gehad. waarschijnlijk bij een laatste aanpassing gebeurd ofzo. Het kan snel opgelost worden, dus het is geen totale ramp.

[Reactie gewijzigd door CaineTanathos op 24 juli 2024 05:02]

[comecme]

Het kan snel opgelost worden? Valt nogal tegen als je niet meer kan booten lijkt me!

[Verwijderd]

Windows CD erin.
Recovery mode opstarten en dan bootcfg uitvoeren.

[Verwijderd]

Misschien alleen onder vista gestest?

Wel vreemd natuurlijk dat je niet onder het meest gebruikte OS test.
Misschien hebben ze een beveiliging draaien die boot.ini beschermt en niks meldt.

[SPee]

Als je op servers test, die (bijna) nooit herstart worden, merk je dat niet.
Alleen dat ze dat niet met de final nog een keer handmatig hebben getest (op de eigen machine ofzo)

Hoeveel tijd zat er tussen voordat ze de patch hadden verwijderd? Ik neem aan dat het binnen een paar uur opgemerkt is en dus actie op ondernomen is.

[Verwijderd]

De client software wordt niet op de servers gedraaid.
Ik kan me goed voorstellen hoe deze fout ontstaan is. Dom maar helaas menselijk.

Na 2 uur is de foute patch verwijdert. Helaas zullen juist in die tijd veel mensen de grafische update hebben willen proberen.

[Calamor]

Je heb er geen last van als de client niet op die parties staat heb je er geen last van.
En ik denk wel dat er best veel dat hebben.
Zelf heb ik ook nooit een spel op c of op windows staan.

@ SPee
Als je niet reboot werkt alles gewoon nog.
Pas als je reboot zoek windows weer naar boot.ini.

[Reactie gewijzigd door Calamor op 24 juli 2024 05:02]

[Jamoru]

Dit is geloof ik wel eerder gebeurt, maar dan met de Test Drive Unlimited Beta. Dit was dan wel niet via een patch, maar via een uninstaller. Wel heel dom natuurlijk en het vreemde is; Waarom worden zulke dingen niet getest?

Linkje: http://forums.eu.atari.com/archive/index.php/t-48964.html

[Verwijderd]

Klopt inderdaad, als je de TDU beta weer verwijderde, dan werd ook je c:\ leeggemaakt. Zeer irritant, maar gelukkig niet al te lastig te herstellen.

Voor de gemiddelde gebruiker natuurlijk wel vreselijk irritant.

[Morphine]

ongelofelijk... hoe kan zoiets gebeuren in een patch van een game?

[SlasZ]

Lijkt me eerder kwaad opzet. Waarom zou een game in godsnaam een boot.ini bestand verwijderen?

[AtleX]

Als je de bron leest zie je dat het spel een file "boot.ini" bevat, maar in de installer is het pad "\boot.ini". Aangezien Windows z'n boot.ini blijkbaar niet beschermt gaat dat dus behoorlijk fout. Gewoon een fout in de installer, die nooit door QA had mogen komen.

[Bosmonster]

Wel een combinatie met imho een fout in Windows dat blijkbaar zo afhankelijk is van een text-bestandje. En dat bestandje vervolgens niet beschermt.

[chaos.be]

.... Waarom zou je gans beschermingsysteem moeten opbouwen voor één bestand? Wat zeg je nu?

Doe anders even een rename van je windows folder op C:\ en kijk of je pc terug opstart. Kan je met een vlag staan waaien dat Microsoft dit maar beter hoeft te beschermen .

Dit is in mijn ogen gewoon een verschrikkelijk domme bug die er tijdens het testen niet is uitgekomen. Normaal moet je in de testomgeving ook gewoon de installer van de applicatie gebruiken. Wat je natuurlijk niet direct test is of het systeem wel terug opnieuw kan opstarten na een installatie...

[Reactie gewijzigd door chaos.be op 24 juli 2024 05:02]

[Bluefan]

.... Waarom zou je gans beschermingsysteem moeten opbouwen voor één bestand? Wat zeg je nu?
De rede wordt gegeven. Elke idioot kan je systeem platleggen

Doe anders even een rename van je windows folder op C:\ en kijk of je pc terug opstart.
Hey ja, goed idee voor een virus als iedereen dit mag doen.

Ik ben het met je eens dat het een domme bug is, maar er had best beveiliging moeten zijn. Stel je voor dat er daadwerkelijk onwetende mensen zijn die eens gezellig rondkijken en c:\windows geen mooie naam vinden...

[chaos.be]

.... Waarom zou je gans beschermingsysteem moeten opbouwen voor één bestand? Wat zeg je nu?
De rede wordt gegeven. Elke idioot kan je systeem platleggen

Doe anders even een rename van je windows folder op C:\ en kijk of je pc terug opstart.
Hey ja, goed idee voor een virus als iedereen dit mag doen.

Ik ben het met je eens dat het een domme bug is, maar er had best beveiliging moeten zijn. Stel je voor dat er daadwerkelijk onwetende mensen zijn die eens gezellig rondkijken en c:\windows geen mooie naam vinden...

De beveiligingssystemen die dit beschermen bestaan al, dat zijn anti-virus scanners. In mijn ogen is deze update een virus, ze tast namelijk je systeem aan. Dus op de reguliere manier moet jouw antivirusprogramma geupdate worden zodat jouw pc beschermd is tegen de EVE-online update.

Een bescherming inbouwen tegenover een "softwareinstallatie" is gewoon onbegonnen werk. Je hebt Click-once programma's die kunnen uitgevoerd worden door gebruikers met beperkte rechten, deze kunnen ook niet aan het file-systeem van jouw PC.

Het grote probleem is dat mensen gewoon niet beseffen dat een software-installatie veel meer om handen heeft dan het laat blijkben. Je voert onbekende programmacode uit op een systeem met Administratorrechten. Kwaadwillenden kunnen echt duizenden dingen doen waardoor je de controle over jouw systeem helemaal verliest.

[Olaf van der Spek]

Een bescherming inbouwen tegenover een "softwareinstallatie" is gewoon onbegonnen werk.

Dat klopt, maar een betere installatiemethode (iets als package mangement) zou dit soort issues wel kunnen voorkomen.

[d-snp]

Een package manager zou alsnog dit soort fouten kunnen bevatten, alle package systemen die ik ken zijn namelijk volledig scriptbaar, niet behoedt ze ervan je passwd file aan te passen ofzo

[bush]

boot.ini kan alleen door administrators gewijzigd worden, en dat moet ook want dit is de plek waar je bepaald "advanced" settings in kwijt kan

[Verwijderd]

Zoveel werk is het niet... gewoon een file stream open zetten naar de file vanuit de kernel. Hierdoor kan je dit bestand alleen aanpassen vanuit de kernel waardoor het alsnog mogelijk moet zijn boot.ini vanuit de computer eigenschappen aan te passen...

Maar het is inderdaad niks meer dan een domme bug van de programmeurs

[? ?]

De Windows map kán je niet renamen, de optie is zelfs niet aanwezig die wordt dus beschermd

[Dennizz]

valt niet tegen...via cmd pikt hij het niet eens:

C:\>rename windows test
The process cannot access the file because it is being used by another process.

[Sir.roYa]

Ja idd ik doe dit zelf ook nooit. Klein programmaatje gemaakt en als het foutloos werkt gewoon een exe ervan maken. Hier ga ik niet de hele computer eerst weer voor opstarten kijken of me systeem nog werkt. Maarja ik maak ook niet van die ingewikkelde dingen zoals dit. Maarja ik test meestal wel vaker meerdere dagen dus dan zit een reboot er automatisch in

En ja foutje kan gebeuren toch? kijk maar eens hoeveel foute updates microsoft zelf al heeft gemaakt. Zegt genoeg.

[Reactie gewijzigd door Sir.roYa op 24 juli 2024 05:02]

[Yanze]

Bestandje is wel beschermd, maar als Adminstrator kun je het zo weg gooien ... als de patch als User gedraaid had geweest was het niet gebeurd denk ik.

[Arjant2]

Dat maakt het toch nog steeds wel erg kwalijk, aangezien toch 99% van de gebruikers van XP (en Vista) gewoon als administrator zijn ingelogd om de beperkte restricties te omzeilen.

[gnimmeL_kraD]

Ik denk dat je dat nog wel zal tegenvallen. Ik denk eerder dat een beperkt groepje tweakers die beveiligingen uit zetten. Zelf heb ik bijvoorbeeld de UAC gewoon aan staan hoor. Eenmaal alles ingesteld kom je het UAC toch niet meer tegen.

[apex75]

Zelfs met UAC aan kan het toch gebeuren dat de BOOT.INI overschreven wordt!

Het problem ligt bij de installer, die heeft Admin rechten nodig om in de Registry te schrijven. Dus bij het uitvoeren van de installer geef je, zonder er over na te denken of er dan misschien een boot.ini of andere Windows-kritische files overschreven worden, een okay. Dan heeft de installer genoeg rechten om alles wat die wil om zeep te helpen.

[bush]

Vista heeft geen boot.ini & XP geen UAC, dus .... waar gaat dit over?

[SirBlade]

UAC zal in dit geval niet helpen, als die patch uitvoert krijg je automatisch een UAC-popup te zien aangezien je bestanden in program files wil gaan wijzigen. Zodra je daar op ok klikt heb je automatisch ook rechten om bestanden zoals boot.ini aan te passen.

[Kwakkel]

Het gaat hier wel over XP, niet over Vista.

[Bliksem B]

Vista gebruikt toch een heel ander opstart methode. Daardoor heb je er hier dus geen last van!!!!
Maar toch dit is wel hele extreme fout in een installer. Het zou zo door kunnen gaan voor een virus! Maar goed in repare mode en dan FIXBOOT. Doet waarschijnlijk al wonderen

[_Dune_]

@Tonyt2: Dit is dan als nog de fout van de meeste gebruikers. Microsoft geeft zelf ook altijd aan alleen administrator accounts te gebruiken wanneer dat echt nodig is en niet bij normale werkzaamheden, daarvoor hebben ze de optie "Start ass" geintroduceerd.

[Neko Koneko]

In Vista zou UAC waarschijnlijk gaan tegensputteren. Maar ja, dat schakelen al die schaapjes massaal uit eigen schuld dikke bult

edit: Vista gebruikt trouwens helemaal geen boot.ini meer

[Reactie gewijzigd door Neko Koneko op 24 juli 2024 05:02]

[johnbetonschaar]

Moet je om zo'n installer te draaien niet per definitie admin access hebben dan? Van Vista weet ik het niet, maar XP applicaties hebben er een handje van om DLL's in je windows system folder te plempen/updaten/whatever. Dan zal je toch admin access moeten hebben om de upgrade uit te voeren.

[Nordlys]

Zo'n beetje elk besturingssysteem laat het root-account in princiepe alles toe qua bestandsbeheer. Onder linux kun je als root ook gewoon erg belangrijke bestanden verwijderen. Is Windows niks anders aan, de meesten draaien in XP immers altijd als beheerder.

[Spleasure]

Precies. Toen door onbekende oorzaak op een Linux systeem PAM corrupt was geraakt was een bootdisk ook de enige optie.

[humbug]

Alsof linux niet van de textbestandjes aan elkaar hangt die je als root zo weg kan gooien.........

Altijd maar gezeik op Windows. Dit is een blunder van de softwareontwikkelaar, niet van Microsoft

[mae-t.net]

Nou, bij linux patch je een spel niet als administrator, meestal. Bij windows is het vrij gebruikelijk om alles als administrator te doen. Juist voor dit soort acties vormt Vista wel degelijk een stap vooruit, omdat het minder vaak nodig is om administrator te zijn en UAC bovendien voor een extra bescherming zorgt.

[Verwijderd]

Gewoon een fout in de installer, die nooit door QA had mogen komen.

QA is ook maar een vangnet, uiteindelijk is de programmeur verantwoordelijk voor z'n fout, waar hij blijkbaar zelf ook al niet goed op heeft gecontroleerd.

[Wim-Bart]

Windows beschermd dit bestand wel degelijk, he verwijderen moet echter wel bewust gebeuren omdat je met een simpele delete het bestand niet zomaar kan wissen vanwege het read-only attribuut.

Kwade opzet dus.

[Verwijderd]

Het gaat om de code regel "Output folder: C:\Program Files\CCP\EVE, Delete file: \boot.ini, Extract: boot.ini"

[cappie]

een typefout in de padvariable (want je zet niet alles hardcoded in je scripts) in het NSIS script van de uninstaller is zo gemaakt... heb 't zelf ook al eens meegemaakt dat ik m'n hele C:\ root had leeggegooid (de files dan, niet de directories).. behoorlijk k-lote

[Destralak]

Wat ik me dan weer afvraag is: Hoe kan een programmeur het in zijn hoofd halen om het programma juist boot.ini te laten verwijderen?
Dit bestand heeft toch totaal niets met het spel te maken?

[Blokker_1999]

Het blijkt een fout in de installatiescripts te zijn. Blijkbaar heeft het spel zelf ook een boot.ini maar word door een typfout de boot.ini uit de rootdir van de schijf verwijderd.

[Laurens-R]

Dan nog... als je als ontwikkelaar weet dat je systeem zo'n bestand bevat, ga je toch niet eenzelfde bestand in je eigen product stoppen? Al is het maar voor de duidelijkheid!

Noem het dat startup.ini ofzo.

Dat pas in rijtje: "Ik heb net een UI framework ontwikkeld voor m'n game met veelvoorkomende dialogboxes enzo... ow wacht ik noem hem Comdlg32.dll"

[Reactie gewijzigd door Laurens-R op 24 juli 2024 05:02]

[SunnieNL]

ik zou er als programmeur vanuit gaan dat het OS zichzelf in zoverre beschermd dat overschrijven of verwijderen van kritieke OS bestanden niet mogelijk is.

Was logischer geweest als het c:\boot.ini alleen beschreven mocht worden door het systemaccount zelf (het account waarin kernel/systeem executables draaien).

[mashell]

En als programmeur zou ik mijn update getest hebben, incl reboot voor ik die vrijgegeven had.

[StarLite]

het probleem trad alleen op als je je eve installatie op je c:\ drive had staan. Als de tester heb op een andere plek hebben staan, óf vista draaiden, óf als een user met beperkte rechten draaiden had de bug niet voorgekomen.

Het blijft heel erg slordig, dat zeker, maar ik vind dat CCP het best aardig netjes heeft opgelost.

[humbug]

Het idee is dat je test op verschillende configuraties die je in het wild zult tegenkomen. Dus het lijkt mij dat je in ieder geval XP test en aangezien 90% van de mensen alles op 1 schijf heeft staan probeert te installeren op C. Aangezien het installeren op een andere schijf wel een problemen geeft test je ook de installatie op de D schijf. Zo moeilijk is dat niet. Wel wat meer werk. Maar dat hoort er nu eenmaal bij.

Slecht werk van de EVE ontwikkelaars. En hoe los je zoiets aardig op? Enig idee hoeveel mensen hun computer hebben moeten herinstalleren? Nee, je kan als bedrijf niet meer doen dan het bestand vervangen en je excuses aanbieden maar dat is tegelijkertijd ook wel het minste wat je kan verwachten. Men heeft gedaan wat men moest doen om het probleem te minimaliseren, maar het zou ook wel erg zijn als men dat niet gedaan had.

[InZane]

Herinstalleren.
Dus als jouw boot.ini weg is, ga je je hele machine herinstalleren? Je hoeft geen tweaker te zijn om dat weer te repareren. Kom op zeg..

[comecme]

Als alleen de kernel het mag wijzigen, dan kan ik het als Admin toch nooit meer aanpassen? Of in ieder geval niet gewoon met Notepad?

[ReLexEd]

Heheh... dus als jij (en dat ben je niet) programmeur zou zijn, dan zorg jij ervoor dat al je bestandsnamen dusdanig uniek zijn, dat er nooit een duplicaat van KAN voorkomen....

Tsktsk....

Een readme.txt zullen we bij jouw werk dus never nooit tegenkomen!

Lachen trouwens... wie zou er dan recht hebben op het gebruik van een config.ini?

[Laurens-R]

Leuk dat jij dat concluderen allemaal (evenals het feit dat ik geen programmeur zou zijn, na deze ene reactie gelezen te hebben... lachwekkend op z'n minst), maar sorry hoor... als ik zo'n geintje flik krijg ik echt wel de wind van voren van m'n baas.... bij dergelijke namen gaat het om systeembestanden, waar dat bij readme.txt e.d. niet het geval is.

Let dus op het onderscheid: het gaat hier om systeembestanden. Nu begrijp ik dat jij als PHP programmeur (zoals dat in je profiel staat) daar niet veel mee te maken hebt.

Als jij lekker veel deploymentverwarring wilt veroorzaken moet jij dat zelf weten .

[Reactie gewijzigd door Laurens-R op 24 juli 2024 05:02]

[Verwijderd]

Om AtleX maar even te quoten:

Als je de bron leest zie je dat het spel een file "boot.ini" bevat, maar in de installer is het pad "\boot.ini". Aangezien Windows z'n boot.ini blijkbaar niet beschermt gaat dat dus behoorlijk fout. Gewoon een fout in de installer, die nooit door QA had mogen komen.

Dat was dus het probleem.

[Lourini]

Heb zonet de nieuwate client gedownload en geïnstalleerd.
Ik heb XP Pro SP2 en heb verder nergens last van... Hebn nu al 3x gereboot in de tussentijd

[Peekster]

CCP heeft de corrupte patch inmiddels verwijderd van zijn servers.

DUH?

[Smylodon]

Klopt, het probleem schijnt ontdekt te zijn rond 4:00 's ochtends (ik neem aan GMT waar Eve standaard gebruik van maakt, dus 5:00 bij ons), en de problematische patch is daarna offline gehaald. De nieuwe patch/client die zo rond 12:00 online is gezet zou geen problemen meer moeten geven.

Ook is het zo dat als je EVE op een andere drive dan C:\ geinstalleerd hebt (ik heb 'm bijv. op D:\ staan), dan is er niets aan de hand.

Zul je altijd zien, loopt de server goed, geven de clients weer problemen. De upgrade verliep ook al te goed om waar te zijn.

[ultimasnake]

Dit klinkt eerder als een ontslagen programmeur die op z'n laatste dag nog even wraak wilde nemen..... ik kan me niet voorstellen dat je "perongeluk" boot.ini verwijderd.
MITS de game zelf ook een boot.ini heeft en het pad niet goed werd aangesproken?..?