Heute noch ein kleiner Beitrag zu dem Problem, Programme unter Windows 10 als System [NT-Autorität\System] auszuführen. Wie ich festgestellt habe, ist dies gar nicht so leicht.
Anzeige
Ein paar Hintergrundinformationen
Man kann zwar Programme über Als Administrator ausführen starten und diese über die Benutzerkontensteuerung administrative Berechtigungen zuweisen. Aber dies ermöglicht nicht alle Operationen, denn Windows verweigert den Zugriff auf bestimmte Elemente (Registrierungsschlüssel, ggf. Dateien), da diese dem System vorbehalten sind.
Die Lösung besteht darin, Programme unter dem Systemkonto oder unter dem Trusted Installer auszuführen. Dann können ggf. Registrierungsschlüssel etc. gelöscht werden. Im Blog-Beitrag Programme als System oder TrustedInstaller ausführen hatte ich im Oktober 2016 zwei kleines Tools vorgestellt, mit denen man Programme wie regedit.exe als System oder Trusted Installer ausführen kann.
Im Rahmen eines Buchprojekts wollte ich mir jetzt nochmals das Tool PowerRun unter Windows 10 vornehmen. Dabei musste ich leider feststellen, dass Microsoft das Tool im SmartScreen-Filter sowie im Windows Defender geblockt hat. Ich konnte es weder unter Windows 10 noch unter Windows 7 (mit MSE als Virenschutz) herunterladen. Keine Ahnung, was da passiert ist – die Lösung mit PowerRun ist aber unter dieser Prämisse für mich faktisch tot.
Mein Versuch, weitere Programme für diesen Zweck aufzutreiben, verlief ebenfalls im Sande. Bei der Suche ausgeworfene Tools, entwickelt vor 2013, waren entweder aus dem Web verschwunden bzw. wurden auch vom Defender/MSE geblockt (z.B. hier). Oder diese wurden von Windows 10 als nicht kompatibel gemeldet (z.B. RunAsSystem und RunFromToken) bzw. die Lösung (z.B. RunAsSystem) funktionierte nicht. Am Ende des Tages habe ich aber eine Lösung gefunden.
Anzeige
Ergänzung: Da natürlich sofort die Keule kam "Wenn man schon daran scheitert, Software am SmartScreen-Filter …" lest einfach meine ergänzenden Kommentare weiter unten.
Process Hacker mit Plugins, das hilft weiter
Der Ansatz, der aktuell noch zu funktionieren scheint (ohne dass Defender/MSE dazwischen grätschen), ist in diesem Process Hacker-Forenthread von 2015 mit beschrieben. Der regulären Blog-Lesern möglicherweise bekannte MagicAndre1981 fragt nach, wie man die Eingabeaufforderung als TrustedInstaller ausführen könne. In der Antwort werden einige Brocken hingeworfen, die ich einfach etwas sortieren möchte.
- Benötigt werden das Tool Process Hacker (gibt es auf SourceForge.net) – man kann auch die portable Fassung von hier verwenden (das Archiv einfach in einen lokalen Ordner entpacken lassen).
- Gebraucht werden auch die TrustedInstallerPlugins, die in diesem Forenthread genannt werden. Einfach die Inhalte der ZIP-Archive entpacken und die .dll-Dateien in die jeweils für 32/64 Bit passenden plugin-Unterverzeichnisse kopieren.
Nach diesen Vorbereitungen ist man bereits am Ziel. Um eine Anwendung mit den gewünschten Rechten auszuführen, geht man in folgenden Schritten vor.
1. Einfach das Tool ProcessHacker über Als Administrator ausführen mit administrativen Berechtigungen starten.
2. Anschließend wählt man im Fenster des ProcessHacker das Menü Hacker und dann den Befehl Run as trusted installer an.
3. In einem Dialogfeld Run as trusted installer kann man über Browse eine beliebige .exe-Datei als auszuführenden Prozess auswählen und dann über OK bestätigen.
Der ProcessHacker startet dann den TrustedInstaller als Dienst und übergibt diesem den neu zu startenden Prozess. Dieser wird dann unter der Autorität [NT-Autorität\System] ausgeführt.
Ich habe dies versuchsweise mit dem Process Explorer aus den Sysinternals Tools probiert. In dessen Titelleiste (siehe obiger Screenshot) wird angezeigt, unter welcher Autorität er läuft. Dort ist [NT-Autorität\System] angegeben.
Den gleichen Ansatz kann man z.B. mit dem Registrierungs-Editor regedit.exe oder portablen Dateimanagern versuchen. Diese sollten dann Zugriff auf alle Objekte erhalten, die im Besitz des Systems sind. Vielleicht hilft es dem einen oder anderen Nutzer, falls er mal so etwas braucht.
Ähnliche Artikel:
VMLite/VirtualBox und der USB-Support
Windows 10: Eingabeaufforderung als Administrator öffnen
Sysinternals-Tools: Januar-Update und weitere Details
Explorer als Administrator ausführen
Windows: Ordner mit Schloss markiert und unlöschbar
Programme als System oder TrustedInstaller ausführen
Tool-Tipp: Process Lasso Taskmanager
Anzeige
Hm. Wenn man schon daran scheitert, Software am SmartScreen-Filter (der gar nicht smart ist) vorbei herunterzuladen – bzw. sich überhaupt von diesem erst bevormunden lässt…
Bei mir tut "PowerRun" klaglos seinen Dienst.
Und daneben gibt es noch "RunAsTrustedInstaller" – das kombiniert die erwähnten Tools "RunAsSystem" und "RunFromToken" in einem, lässt sich einfach verwenden und funktioniert (bei mir) unter Windows 10 klaglos:
https://github.com/jschicht/RunAsTI
Das ist jedenfalls deutlich einfacher als die aufwändige Lösung oben.
Ich habe gestern einige Sachen in einer VM (32-Bit) unter Windows 1607 ausprobiert. Ernüchterndes Ergebnis nach mehrstündigem Testen:
– Manche Tools, die ein Kontextmenü zum Aufruf erzeugen, funktionierten nicht. Deinstallation Fehlanzeige – ich musste die Registrierung manuell bereinigen, um den Kontextmenüeintrag zu entfernen.
– RunAsSystem und RunFromToken hatte ich separat heruntergeladen und eingerichtet – wurden mir als nicht kompatibel zu Windows 10 gemeldet (habe ich in der Eingabeaufforderung angezeigt bekommen – mag aber mit 32-Bit zu tun gehabt haben).
– den RunAsTI habe ich eben nochmals angefasst (Doku ist ja nahe Null) -> Die ZIP-Datei wird hier (wie PowerRun) geblockt, siehe unten.
Die Blockade erfolgt übrigens sowohl unter W7 mit MSE als unter Win 10 mit Defender. Es wird ein Trojan:Win32/Rundas!plock und ein Trojan:Win32/Spursint.Ftcl gemeldet (Win 7 SP1, 64 Bit, MSE).
Selbstverständlich tun sowohl PowerRun als auch RunAsTI das, was sie sollen, wenn ich den Echtzeitschutz abschalte. Das mit dem Anschlagen des MSE/Defender mag ein Fehlalarm sein – aber unter diesen Prämissen werde ich mich hüten, solche Tools in einem Blog-Beitrag oder in einem Buch (was ggf. noch in 2 – 3 Jahren kreist) vorzustellen.
Die oben skizzierte Lösung mag dir vielleicht nicht so elegant vorkommen – sie funktioniert hier (bisher ohne Alarm) – und mit dem Portable-Ansatz muss nichts installiert werden. Das zählt – und der Blog kann mit seinen Beiträgen eh nur ein Angebot machen "funktioniert auf diesem Weg". Einfach mal bedenken – selbstverständlich steht es euch frei, PowerRun oder RunAsTI zu verwenden.
Weitere Erkenntnisse für mich
Erste interessante Erkenntnis meines heutigen Tests: Schalte ich in Windows 7 den Echtzeitschutz des MSE aus, kann ich die ZIP entpacken und den entpackten Ordner über das Netzwerk in einer 32-Bit-Windows 10 V1607 Virtual Maschine ziehen/kopieren. Der Windows Defender der VM (Echtzeitschutz ist da aktiv) schlägt nur bei der 32-Bit-RunAsTI.exe an, kopiert aber die 64-Bit-RunAsTI64.exe. Vermutlich, weil sich die 64-Bit-Anwendung nicht unter dem 32-Bit-Windows 10 ausführen lässt – hätte ich so nicht erwartet, sondern ging davon aus, dass auch diese Datei bemängelt wird.
Zweite Erkenntnis: Die Verwaltung der Windows Defender-Einstellungen ist in der mir vorliegenden Win 10 V1607 nur noch unter einem Administratorkonto möglich. Hintergrund: Geht man im Defender-Fenster auf die Einstellungen, öffnet sich die Seite der Einstellungen-App. Und dort ist unter einem Standard-Konto alles gesperrt.
Naja, wenn man solche Tools runterläd, darf man sich nicht wundern, dass ein Virenscanner oder der SmartScreen Filter anschlagen. Aus deren Sicht sind das potentiell gefährlich Tools, weil sie die Sicherheit von Windows aushebeln.
Wenn man aber genau das vorhat, muss man diese Hinweise vom SmartScreen Filter eben ignorieren.
Nils: Es reicht eben nicht den SmartScreen-Filter zu ignorieren. Wenn mir kein Fehler unterlaufen ist, muss der Echtzeitschutz des Defender deaktiviert werden und man muss die Warnungen des SmartScreen-Filters ignorieren.
Es ist natürlich klar: Wer solche Tools einsetzt, sollte wissen, was er tut. Aber der Teufel ist ein Eichhörnchen – und schnell ist vergessen, dass man dieses oder jenes auf die Schnelle geändert hat – mit den bekannten Folgen ;-).
"Es ist natürlich klar: Wer solche Tools einsetzt, sollte wissen, was er tut.
Aber der Teufel ist ein Eichhörnchen – und schnell ist vergessen, dass man dieses oder jenes auf die Schnelle geändert hat – mit den bekannten Folgen ;-).
Ein immer wieder aufschlußreiches Thema. Danke. :-)
Anfangs nutzte ich auch die hier beschriebene Möglichkeit via Registerkarte> Sicherheit< ect pp. (WIN8.1)
Nachdem ich einen Ordner in Besitz genommen und Veränderungen vorgenommen hatte, gab ich jedoch auf umgekehrtem Wege die Rechte auch immer wieder gleich zurück.
Eine zugegeben, ziemlich zeitaufwendige Zeremonie.
Irgendwann stieß ich beim Surfen zufällig auf:
"Winaero.com".
Die boten diese beiden Tools als Lösung an:
"RegOwnershipEx" und "TakeOwnershipEx".
Alle beide funzen einwandfrei:
Mit je zwei Mausklicks erhält man alle Rechte und gibt sie auch gleich wieder zurück.
Wobei lediglich "TakeOwnershipEx" installiert werden muß.
"RegOwnershipEx" ist portable ausführbar.
Ob die allerdings auch noch unter WIN10 funktionieren, entzieht sich, wegen Totalverweigerung, meiner ungeschätzten Kenntnis. :-)
Ein Blue Screen-freies Wochenende ;-)
Zitat: "… die Lösung mit PowerRun ist aber unter dieser Prämisse für mich faktisch tot."
Meine heutige Erfahrung unter folgenden Prämissen:
Windows 10 Home (x64) Version 1607 (build 14393.693)
Windows Defender deaktiviert, externes AV sowie externe Firewall aktiv –
Herunterladen von PowerRun 1.1 von der Seite sordum.org lief problemlos, wie auch das Entpacken und Starten.
Hab gerade mit Firefox nach PowerRun gesucht und z.B. bei sordum or ghacks Version 1.1 gefunden.
Lässt sich unter meinem Win10_64 problemlos starten und startet auch den regedit oder process explorer ohne Murren als NT-AUTORITÄT
Sollte das nicht auch funktionieren, wenn man Programme wie Regedit unter einem als Administrator gestartetem Explorer++ (z.B. PortableApps) aufruft?
Da griffen die verbastelten MS extra "Schutzfunktionen" eigentlich nicht.
Oder derartige Programme im originalen Administrator Konto aufrufen, oder von dort, z.B. via Aufgabenplanung starten lassen?
Den SmartScreen-Filter kann man sich eigentlich schenken, weil MS damit willkürlich und unlogisch sperrt, was denen nicht gefällt. Während z.B. die eigenen Sysinternals Tools alle ohne Warnungen laufen, werden "Fremdanbieter" mit aus der gleichen System Tools Ecke kommend geblockt. Das ist reine Microsoft Logik, aber nicht ihrem Sinn nach laufende Funktion. Dann gibt es wieder Cheat-Tools für Spieler die im Speicher werkeln, wo auch nix passiert… da warnt nicht mal der Defender…
Sicher gibt es auch ernsthaftes, wo das bei einem unerfahrenem Anwender Sinn macht, aber ansonsten… Überflüssig, vor allem wenn man Edge und IE nicht benutzt. Alle anderen bekannteren Browser schauen gefühlt eh in Googles Malware Listen, die theoretisch den gleichen Job genauso gut, oder schlecht erledigen.
Gefährliche Software zu erkennen ist eigentlich auch Aufgabe des gewählten Virenschutzes…
Zu Sollte das nicht auch funktionieren, wenn man Programme wie Regedit unter einem als Administrator gestartetem Explorer++ (z.B. PortableApps) aufruft?
Ich kann nur die Erfahrung beisteuern, dass ich mir mal die Zähne an einem Registrierungseintrag von Virtualbox ausgebissen habe. Der hat mir die USB-Funktionalität geschreddert (siehe VMLite/VirtualBox und der USB-Support). Der Registrierungseditor lief mit administrativen Rechten, der Schlüssel war nicht manipulierbar. Ob es mit dem Build-In Konto Administrator gegangen wäre? Keine Ahnung, ich vermute nein – wenn ich allen Benutzern die Zugriffsrechte zum Ändern entziehe, sind die draußen. Ich habe dann psexec aus den Sysinternals Tools verwendet, um regedit.exe unter System auszuführen. Dann ging es.
Ansonsten gebe ich dir mit deinen Überlegungen Recht – ist aber nicht Gegenstand des obigen Blog-Beitrags. Und hier kann auch Chrome die ZIP-Archive nicht herunterladen, weil der MSE dazwischen grätscht (alles getestet). Nur wer auf einer anderen AV-Lösung sitzt, hat ggf. keine Warnung. Aber dazu sind die Blog-Beiträge ja auch da, um solche Haken aufzudecken. Was nützt es mir, wenn zig Sites die Tools loben, ein Anwender das Tool kurz braucht und auf das Problem stößt, dass Defender/MSE die Dateien blocken. Da heißt es dann "forsche und evaluiere". Und es wäre ja nicht das erste Mal, wo ein Tool irgendwann mit PUPs "nachgebessert" wurde, so dass die Warnungen der AV-Scanner berechtigt wären.
Ach dieses blöde Windows… das müsste mal jemand alles aufschreiben, in nem Buch oder so… ;)
Da werde ich mich hüten, mir an so was die Finger zu verbrennen – speziell zu Windows 10. Du siehst ja hier schon, welche Diskussionen kreisen ;-).
Und bei einem Buch konservierst Du einen Schnappschuss zum Zeitpunkt X – bekommst aber noch 10 Jahre nach Veröffentlichung Nackenschläge, weil plötzlich was nicht geht. Glaube mir, nach ca. 300 Titeln weiß ich, wovon ich rede bzw. schreibe ;-).
…Windows 10 braucht keine 10 Jahre bis ein Buch veraltet wäre… Das wäre kaum auf dem Markt und schon Altpapier… oder sehr simpel und einfach gehalten.
Was man von Nackenschlägen und schlägen an den Hinterkopf so im Volksmund sagt, ist doch ein kleiner trost an der Sache…
"Der Registrierungseditor lief mit administrativen Rechten, der Schlüssel war nicht manipulierbar."
Ich meinte nur, das es tatsächlich einen Unterschied macht, ob ich Regedit als Admin starte, oder aus dem Explorer der mit Adminrechten läuft heraus, sogar wenn dieser aus einer Eingabeaufforderung mit Adminrechten gestertet wurde,
oder
einem z.B Explorer++ heraus, der Adminrechte besitzt. Regedit hat merkwürdigerweise mehr freigegeben, bzw ließ sich ein Eintrag erst so überhaupt ändern.
Ob in jedem Fall weiß ich nicht, aber mir hat diese Lösung schon geholfen und ich diese seit dem im Hinterkopf.
Interessant – muss ich mir mal merken – obwohl ich von der Theorie her keine Erklärung hätte. Eine administrative Eingabeaufforderung über "Als Administrator ausführen" geöffnet und regedit.exe gestartet sollte die gleichen Credentials übergeben wie regedit.exe aus einem mit administrativen Rechten laufenden Explorer++ – imho. Aber vielleicht ist da mal wieder etwas unbekanntes im Spiel.
Zu den Ausführungen "Ich meinte nur, das es tatsächlich einen Unterschied macht, ob ich Regedit als Admin starte, oder aus dem Explorer der mit Adminrechten läuft heraus, sogar wenn dieser aus einer Eingabeaufforderung mit Adminrechten gestartet wurde,": Da ist mir nicht klar, ob Du den Windows Explorer (explorer.exe) meinst. Wenn ja, wäre das erklärbar, denn der explorer.exe kann nicht mit administrativen Rechten laufen – ich habe das Thema 2013 im Beitrag Explorer als Administrator ausführen behandelt.
"Wenn ja, wäre das erklärbar, denn der explorer.exe kann nicht mit administrativen Rechten laufen"
Erklären kann ich den Fall auch nicht… aber es funktionierte. Ich komm nur nicht mehr darauf was es genau gewesen ist. Vielleicht fällt es mir ja nochmal ein.
Es hatte aber genau damit zu tun, das MS den Explorer eben beschnitten, oder begrenzt hat und eigentlich auch alle anderen Tools, wie eben auch Regedit, egal ob man es nun als Admin startet, oder nicht.
Wenn ich mich recht entsinne war die letzte Alternative damals, zumindest in meinem Fall, der abgesicherte Modus um dort die Änderungen durchzuführen.
> Ich meinte nur, das es tatsächlich einen Unterschied
> macht, ob ich Regedit als Admin starte, oder aus dem
> Explorer der mit Adminrechten läuft heraus, sogar
> wenn dieser aus einer Eingabeaufforderung mit
> Adminrechten gestertet wurde
Trugschluss. Der Explorer lässt sich nicht mit Adminrechten starten, schon seit Win 7 nicht mehr. Das klappt also gar nicht, wenn man ihn aus einer Admin-Eingabeaufforderung heraus startet. Er hat dann trotzdem nur Standardrechte. Wenn ein Schlüssel in den Rechten so eingestellt ist, dass Admins z.B. nur Leserechte haben, haben sie eben nur solche.
Wenn nur System Löschrechte hat, kann auch nur System löschen, bei Trusted Installer ebenso. Wer was darf, ist ja genau festgesetzt. Einfach in die Rechte reinschauen.
doch das geht. Hatte ich vor Jahren mal ausgetüftelt:
http://www.msfn.org/board/index.php?showtopic=144776
André:
> doch das geht. Hatte ich vor Jahren mal
> ausgetüftelt
Hallo André,
ja, nach besagter Reg-Änderung geht das auch in Win 10 noch problemlos – man hat dann halt ggf. ne hübsche Menge an Explorer-Instanzen offen. Ich lasse den Schlüssel lieber unverändert und nehme einen alternativen Dateimanager.
Man muss bei der Sache auch bedenken, dass "Administrator" nicht gleichbedeutend mit "Adminrechte" ist. Wenn für ein Objekt nur Administrator Vollzugriff hat, kann man es mit Adminrechten der Gruppe "Administratoren" nicht bearbeiten, sondern eben nur als "Administrator" selbst.
(Unter deiner Antwort war kein Button "Antworten" zu sehen)
Gruß, hpm
@hpm: Der fehlende "Antworten"-Link ist klar – ich lasse max. 5 Verschachtelungsstufen im Blog für Kommentare zu (ist das Maximum).
Kurze Nebenbemerkungen zur Diskussion hier zum Beitrag – die auf den Smartscreen-Filter abhebt (aber vom Echtzeitschutz der MS Scan Engine beeinflusst wird).
Meine generelle Erkenntnis (unabhängig vom AV-Thema): Wir sollten uns vor der vermeintlichen Erkenntnis hüten "das ist so, muss man so und so deaktivieren – und dem Nutzer fehlt einfach das notwendige Wissen" – auch ich tappe immer wieder in diese Denkfalle.
Aktuell stehen wir vor dem Problem, dass die Bedrohungen durch Malware immer ausgefeilter werden – und die AV-Lösungen rüsten mit allerlei Tricks nach. Was oft in Blogs begeistert "tolle Neuerung von AV-Lösung xyz" gefeiert wird, hat leider zur Folge, dass manches, was man zu wissen glaubt, plötzlich nicht mehr stimmt. Und dann knallt es irgendwann an allen Ecken und Enden, weil ein Virenscanner unvermittelt Kollateralschäden verursacht.
Ich bin auch nicht optimistisch, dass das besser wird. Ich erlebe zur Zeit eigentlich zwei Entwicklungen.
a) Die Sachen werden immer komplexer und kaum noch zu durchdringen. Spiegelt sich auch an manchen Blog-Beiträgen zum Troubleshooting, wo um drei Ecken gedacht werden muss, um die Ursache für ein Problem zu finden. Ich verweise aktuell auf den Nachtrag zum Artikel hier, wo die Erzeugung einer Windows PE-Umgebung nicht mehr ging. Derjenige, der das untersucht hat, kann schon wesentlich tiefer graben, als ich das üblicherweise mache – und ist bei der Interpretation der Ergebnisse erst einmal reingefallen.
b) Andererseits versuchen die Hersteller die Entwicklung in Richtung "wir regeln das alles automatisch, Du musst als Anwender nichts mehr an Details wissen oder schrauben" zu drehen.
Ergo: Der Hinweis "wenn der Anwender das Wissen nicht hat" ist kaum noch zielführend, da dieses Wissen momentan gezielt "wegoptimiert" wird – und wenn noch vorhanden, eine Halbwertzeit von wenigen Wochen haben kann. Nicht wirklich erbauend – imho.
"Ergo: Der Hinweis „wenn der Anwender das Wissen nicht hat" ist kaum noch zielführend, da dieses Wissen momentan gezielt „wegoptimiert" wird – und wenn noch vorhanden, eine Halbwertzeit von wenigen Wochen haben kann. Nicht wirklich erbauend – imho."
Heißt das nun übersetzt: Problemfindung einstellen, Microsoft macht das schon?
Dann gute Nacht, gerade in Gedanken dazu, was ich gerade zu Computer in Schulen geschrieben habe… In dem Fall fallen Computerunterrichte an Schulen, in denen Lehrer als Hobbyprojekt das ganze am Leben halten, weg.
Heißt erst einmal nix – nur eine reine Feststellung – und nicht nur auf MS bezogen (Apple und Google etc. sind nicht besser). Das große Problem ist doch, dass sich alle paar Tage was ändert und Dokumentation kaum noch geliefert wird (bzw. diese oft eine Halbwertzeit von Wochen hat). Aber möglicherweise trügt mein persönlicher Eindruck.
Was spricht denn eigentlich gegen PsExec aus der SysinternalsSuite? Ist schließlich auch ein Microsoft Produkt inzwischen…
Mit dem Parameter -s kann man einen Prozess oder eine Anwendung im Local System Kontext laufen lassen… das funktioniert auch unter W10…
Setze ich hier auch bevorzugt ein. War aber der Meinung, dass das Teil nicht alle Berechtigungen des Trusted Installer erteilen kann – mag mich aber irren.
So was kann man nur austesten, wenn man konkret einen Fall vorliegen hat, wo ein Objekt vom Trusted Installer verwaltet wird.
> Was spricht denn eigentlich gegen PsExec aus der SysinternalsSuite?
Nützt nichts, denn System hat nicht auf alle Objekte Vollzugriff.
Für den Normal User sind der Smartscreen-Filter, das Automatische Upgrade und Treiber Installation auch ein Segen wenn es denn Richtig Funktioniert!
Für den Professionelle Anwender und Administrator ist das alles ein Fluch, selbst die ganzen netten Tools von Nirsoft zb. Mail PassView werden vom Smartscreen Filter als Potenziell gefährliche Software eingestuft und geblockt die ganzen Tools Funktionieren natürlich noch einwandfrei.
"Für den Normal User sind der Smartscreen-Filter, das Automatische Upgrade und Treiber Installation auch ein Segen wenn es denn Richtig Funktioniert!"
Und wenn der Smartscreen-Filter "richtig" funktioniert:
"Einige Informationen zu den Dateien und Apps, die auf den PC ausgeführt werden, werden an Microsoft gesendet."
Des einen Segen des anderen Fluch(en) ;-)
(Furto die) Dati et Orbi:
Il fratello grande, L'uomo potente da Redmondo, padre Nadelli a tutti i fedeli presenti e a quelli che ricevono la sua benedizione, a mezzo della radio, della televisione e delle nuove tecnologie di comunicazione, concede l'indulgenza perdita di dati nella forma stabilita Microsofti.
In nome dell'amministratore, dell'utente e la mente di sofferenza. AMEN
Datenklau und Erdkreis:
Der Große Bruder, der Mächtige Mann aus Redmond, Vater Nadella, gewährt allen hier versammelten Gläubigen und jenen, die seinen Segen durch das Radio, durch das Fernsehen und durch die neuen Kommunikationsmittel empfangen, einen vollkommenen Datenverlust nach den von Microsoft vorgeschriebenen Regeln.
Im Namen des Admins des Users und des leidenden Geistes. AMEN :-D