Anfrage an die Fuhrparkverwaltung
Heute erhielt ich folgende eMail von der Firma europesalon:
An Firma: SWE Sven knight
Betreff: Ihr FuhrparkSehr geehrte Damen und Herren,
stets suchen wir nach gebrauchten Dienstfahrzeugen. Sollten bei Ihnen Fahrzeuge (PKW´s sowie LKW´s) zum Verkauf anstehen, würden wir uns über ein Angebot freuen.
Ihr Angebot können Sie schnell und bequem über unseres Webformular unter http://www.europesalon.be abgeben, oder Sie rufen unseren Herrn Thomas unter 0178 77 xx xxx.
Für Ihr entgegengebrachtes Vertrauen bedanken wir uns im Voraus und verbleiben,
mit freundlichen Grüssen
Ihr ES TeamP.S.
Auf Ihr Unternehmen sind wir über Ihre Homepage http://www.squeez.de/ aumerksam geworden, und hoffen auf eine erfolgreiche Zusammenarbeit.
Leider besteht mein gesamter Fuhrpark nur aus einem einzigen Auto, von welchem ich mich in nächster Zeit auch nicht trennen werde. Es sei denn, jemand würde mir bei eBay ein vielfaches des Wertes bieten.
fsc.exe und die angebliche Fernwartung
Es gibt gewisse Anwendergruppen, welche kommerzielle Software gerne ohne Bezahlung nutzen. Diese treffen sich dann unter anderem im Forum des Community Leaders Founders Cosmo Connor und diskutieren darüber, wie man mit den Tücken der Software zurechtkommt, die sich gegen eine unberechtigte Nutzung zur Wehr setzt.
So schreibt Elektrospeedy dort zum Beispiel:
Hi, ich möchte Euch aber ans Herz legen, die Datei fsc.exe vor der Installation von SC umzubenennen oder zu löschen. Die Installation funktioniert trotzdem und auch SC selber greift nicht direkt darauf zu. Googelt aber mal nach fsc.exe. und Ihr werdet verstehen, warum man mistrauisch sein sollte. Irgendwie arbeitet es auch mit Netframework zusammen und verbindet sich mit einem Sever im Internet. Ich bin damals beim SC10 stutzig geworden, als bei installiertem Netframework plötzlich fsc.exe ins Netz wollte (die Firewall hat es aber unterbunden).
Wenn man dann in Google einmal nach „fsc.exe“ sucht, dann gibt es in der Tat interessante Ergebnise. Über den ersten Beitrag findet man zur Seite Pflege von Webseiten und Verzeichnissen mit dem „FileServer Commander“ und hier heißt es:
Der Fileserver Commander FSC.EXE ist das ultimative Werkzeug zur Fernwartung eines Fileservers von Clients aus, die sich im Netz befinden, deshalb wurde für diese Software die Kurzbezeichnung „Fileserver Commander“ gewählt.
Einige Einträge später kommt dann auch das .NET-Framework mit ins Spiel. fsc.exe ist nämlich zufällig auch die Abkürzung für den F#-Compiler:
The compiler fsc.exe is a traditional command line compiler with a set of command line switches similar to both the OCaml compiler and the C# compiler.
Elektrospeedy zieht daraus nun folgende Schlussfolgerungen:
Ich denke mal, das hing auch mit diesem KG zusammen und der basierte ja auf Netframework. Der sucht sich auf der HD diese Datei und versucht sie zu nutzen.
Aber bitte, mal einige Schlagzeilen aus Google:
Der Fileserver Commander FSC.EXE ist das ultimative WerkzeugNET framework – not inculded the zip; Requires F#/AbsIL – not inculded the zip; Requires the Fsc.exe and csc.exe compilers to be on the path
utils/winnt: (among other things). rtpudpsvc.exe – rtp server; fsc.exe – Field Setup Controller; nci.exe – Network Control Interface
ive been infected by a bloody trojan or the like….help! – Tech … – [ Diese Seite übersetzen ]… O4 – HKLM..Run: [Kec] C:\WINDOWS\System32\Fsc.exe O4 – HKLM..Run: [Gvv] C:\WINDOWS\System32\Urm.exe O4 – HKLM..Run: [Rqh] C:\WINDOWS\System32\Qsr.
File: c:\windows\fsc.exe Positive identification: TrojanClicker.Win32.Spywad.a File: c:\windows\rmp.exe Positive identification: TrojanClicker.Win32. …
Ich habe die Links zwar nicht im weiteren Verfolgt, doch das mahnt schon zur Vorsicht, zumal fsc.exe im Hintergrund ohne sichtliche Meldungen abzulaufen vermag. Wie schon gesagt, durch deaktivierung habe ich noch kein Fehlverhalten des SC feststellen können.
Ich kann Elektrospeedy aber beruhigen. SpeedCommander und natürlich auch alle anderen von mir veröffentlichten Anwendungen enthalten keinerlei Funktionen, um remote (ohne Wissen des Anwenders) auf andere Rechner zuzugreifen und sie senden auch keine Informationen „nach Hause“. Die Datei „fsc.exe“ heißt so, weil fsc einfach nur die Abkürzung für FileSync Command Line ist. Durch das Löschen dieser Datei wird SpeedCommander nur um die Programmfunktion zum Synchronisieren von Ordnern via Kommandozeile beraubt, nicht mehr und nicht weniger.
Wiener Schnitzel-Diskettenlaufwerk
Microsoft bietet für einige Artikel in der Knowlegde Base auch eine maschinelle Übersetzung für Anwender an, die der englischen Sprache nicht mächtig sind, damit sie den Inhalt der Artikel in Grundzügen verstehen können. Allerdings frage ich mich bei diesem Artikel, was denn um Himmels Willen ein Wiener Schnitzel-Diskettenlaufwerk ist.
Auf External Drive in MS-DOS Wiener Schnitzel nicht werden zugegriffen kann
Nach Aktualisierung zu MS-DOS können Sie nicht auf ein externes Wiener Schnitzel-Diskettenlaufwerk auf einem IBM PS/2 Computer zugreifen kann. Pacific Rim Systems hat bestätigt, dass keine Abhilfe zu diesem Zeitpunkt verfügbar ist.
Im Übersetzungssystem von Microsoft muss es irgendeine feste Verbindung zwischen Pacific Rim und einem Wiener Schnitzel geben. Wenn man die Knowledge Base mal nach einem Schnitzel durchsucht, dann bekommt man drei weitere Artikel, in denen es sich eigentlich eher um die Firma Pacific Rim bzw. um pazifische Randgebiete handelt als um ein Wiener Schnitzel.
Visual Studio 2005 (Beta 2) verfügbar
Gestern abend hat Microsoft still und heimlich die Beta 2 vom Visual Studio 2005 für MSDN-Mitglieder freigebeben. Die Installation verlief ohne Probleme und im Vergleich zu früheren Versionen auch deutlich flotter. Die Projekte von früheren Versionen lassen sich übernehmen, allerdings hat Microsoft die Bezeichnung für die AMD64-Buildkonfiguration von Win64 (AMD64) auf x64 geändert. Man sollte also vorher manuell mit einem Editor die alte Konfigurationsbezeichnung durch die neue ersetzen und dann auch in den jeweiligen Solutions die Anpassung vornehmen, wenn man mit den bisherigen Projekten weiterarbeiten möchte. Ansonsten wundert man sich, dass der Build-Befehl für 64bit-Projekte keine Funktion hat.
Die Beta 2 ist bis jetzt deutlich stabiler als die CTP vom Februar, die IDE selbst agiert bei Änderungen an den Projekten auch nicht mehr so schwerfällig. Weitere Erfahrungsberichte gibt es sicher in den nächsten Wochen.
Debug-Fix für Visual Studio 2005 (Beta)
Visual Studio 2005 ist eine 32bit-Anwendung und läuft im WoW64-Layer (Windows on Windows). Damit man nun auch 64bit-Anwendungen debuggen kann, benutzt VS2005 den Remote Debugger. Dies geschieht für den Entwickler völlig transparent, man merkt davon nichts.
Nach der Installation von VS 2005 (CTP vom Februar) auf der finalen Version von Windows x64 funktioniert leider das Debuggen von 64bit-Anwendungen nicht mehr, obwohl der Remote Debugger für Windows x64 korrekt installiert wurde. VS2005 zeigt die Meldung
Remote debugging components are not registered, but are required for debugging. On a 64-bit machine, these components are not installed with Visual Studio.
Mit der finalen Version von Windows x64 gab es noch einige kleine Änderungen bzgl. der 64bit-Registrierungsschlüssel. Damit man den Debugger auch hier zum Laufen bekommt, muss man im Ordner „C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\x64“ den Befehl „msvsmon /regautolaunch“ eingeben. Danach funktioniert der Debugger wieder wie gewünscht.
Nun kann ich WinDbg, den ich die letzten vier Tage benutzen musste, endlich deinstallieren und stattdessen wieder den gewohnten und komfortablen VS-Debugger benutzen. Vielen Dank an Ken Bayer von Microsoft, der mir dieses mitteilte.
Abenteuer x64
In den letzten Tagen habe ich mich damit beschäftigt, die Packer-Bibliotheken auf 64 Bit anzupassen. Das Kompilieren unter x64 geschah recht problemlos, allerdings stürzten einige der Bibliotheken (insbesondere die LZ77-Abkömmlinge) beim Komprimieren bzw. beim Entpacken ab.
Die Hauptursache war hier der Umgang mit Zeigern. Das Zeigermanagement kann sich unter x64 zu einer kniffligen Sache entwickeln, wenn man Zeigerarithmetik mit vorzeichenlosen Zahlen betreibt. Unter x32 gibt es hiermit keine Probleme, da es bei einem eventuellen Überlauf automatisch zu einer negativen Zahl kommt. Bei einer Erweiterung der Zeiger auf 64 Bit gibt es aber bei Operationen mit 32 Bit-Datentypen keinen Überlauf mehr, stattdessen wird das niedrigste Bit in den oberen 32 Bit gesetzt.
An einem Beispiel lässt sich das sehr gut demonstrieren. Der Ausgangspunkt ist ein kleines Stück C++-Code, der ein dynamisches Array erstellt und innerhalb dieses Arrays mit Zeigern arbeitet.
BYTE* pMem1 = NULL; BYTE* pMem2 = NULL; pMem1 = new BYTE[10]; UINT nTest = (UINT) -1; // pMem zeigt auf 0x01814a28 for (int iTemp = 0; iTemp < 10; iTemp++) { pMem1[iTemp] = (BYTE) iTemp; } pMem2 = pMem1 + 5; // pMem2 ist danach 0x01814a2d pMem2 = pMem2 + nTest; // pMem2 ist danach 0x01814a2c
In den Kommentaren habe ich die Werte für die Zeiger angegeben, die beim Durchlauf auf meinem System entstanden sind. In Zeile 9 wird pMem2 auf den 6. Index (der Index ist 0-basiert) innerhalb des Arrays gesetzt. In Zeile 10 wird pMem2 um 0xFFFFFFFF verschoben, durch den entstehenden Überlauf ist das mit einer Subtraktion von -1 vergleichbar. pMem2 zeigt nun auf das 5. Element im Array.
Unter x64 lässt sich der Code problemlos kompilieren, auch eine explizite Prüfung auf 64bit-Probleme (Schalter /Wp64) meldet keine Probleme. Spätestens aber beim Versuch, mit pMem2 auf das 5. Element im Array zuzugreifen, funkt Windows mit einer Speicherschutzverletzung dazwischen. Wenn man sich den Inhalt von pMem2 genauer anschaut, dann ist der Grund dafür auch ersichtlich. Anstatt wie erhofft auf 0x00000000:00373d84 zeigt pMem2 plötzlich auf 0x00000001:00373d84, was definitiv nicht zum Speicher des Arrays gehört.
BYTE* pMem1 = NULL; BYTE* pMem2 = NULL; pMem1 = new BYTE[10]; UINT nTest = (UINT) -1; // pMem zeigt auf 0x00000000:00373d80 for (int iTemp = 0; iTemp < 10; iTemp++) { pMem1[iTemp] = (BYTE) iTemp; } pMem2 = pMem1 + 5; // pMem2 ist danach 0x00000000:00373d85 pMem2 = pMem2 + nTest; // pMem2 ist danach 0x00000001:00373d84
Genau wie unter x32 wird auch unter x64 pMem2 um 0xFFFFFFFF verschoben. Da der Wertebereich der 64bit-Zeiger aber nicht bei 0xFFFFFFFF endet, findet hier kein Überlauf statt und pMem2 zeigt auf eine ungültige Adresse.
Ein kleiner Typecast bei Zeigeroperationen hilft hier weiter. Der einzige Unterschied im folgenden Code zum vorherigen liegt in der letzten Zeile. Wird nTest explizit zu einem vorzeichenbehafteten Typ gecastet, dann zeigt pMem2 nach der Zeigerarithmetik auch auf die gewünschte Stelle.
BYTE* pMem1 = NULL; BYTE* pMem2 = NULL; pMem1 = new BYTE[10]; UINT nTest = (UINT) -1; // pMem zeigt auf 0x00000000:00373d80 for (int iTemp = 0; iTemp < 10; iTemp++) { pMem1[iTemp] = (BYTE) iTemp; } pMem2 = pMem1 + 5; // pMem2 ist danach 0x00000000:00373d85 pMem2 = pMem2 + (int) nTest; // pMem2 ist danach 0x00000000:00373d84
Alternativ kann man natürlich auch alle vorzeichenlosen Datentypen, die im Zusammenhang mit der Zeigerarithmetik verwendet werden, zu vorzeichenbehafteten umdefinieren. Das ist aber leider auch eine Menge Arbeit und es besteht die Gefahr, dass sich ohne große Not Fehler in bereits getesteten Code einschleichen.
Interessierten Lesern kann ich auch noch ein MSDN-Video von Kang Su Gatlin empfehlen. Hier wird nochmals auf einige Sachen in Bezug auf mögliche Probleme bei der Portierung auf 64bit eingegangen.
TaskSwitchXP
Fast jeder kennt das TaskSwitch-Fenster, mit dessen Hilfe man über Alt+Tab schnell zwischen den geöffneten Anwendungen hin- und herschalten kann.
Unter den Microsoft PowerToys für Windows XP gibt es einen grafisch aufgepeppten Ersatz, allerdings ist dieser schrecklich langsam. TaskSwitchXP dagegen ist ein schicke, flinke und sparsam mit dem Speicher umgehende Alternative mit unheimlich vielen Anpassungsmöglichkeiten, der Quellcode steht ebenfalls zur Verfügung.
GUIDs auf die Schnelle
Ab und zu kommt man mal in die Verlegenheit und braucht schnell eine GUID. Für diese Fälle hat Uwe Keim eine neue Website zur Generierung von GUIDs programmiert.
Wenig bekannt ist aber leider, dass Microsoft mit Windows 2000 eine kleine Änderung bei der Generierung einer GUID durch die Funktion UuidCreate vorgenommen hat. Bis Windows 2000 war eine mit UuidCreate erstellte GUID garantiert immer eindeutig in Raum und Zeit, sofern der Rechner, auf dem sie erstellt wurde, eine Netzwerkkarte besaß. Da man durch die in der GUID enthaltene MAC-Adresse aber Rückschlüsse auf die Netzwerkkennungen in einer Firma schließen kann, hat Microsoft diese Funktion aus Sicherheitsgründen geändert. Der große Nachteil ist nun, dass die generierten GUIDs nicht mehr zwingend eindeutig sind.
Ab Windows 2000 muss man zur Generierung einer globalen eindeutigen GUID daher die Funktion UuidCreateSequential verwenden, andernfalls kann lediglich garantiert werden, dass die GUID nur auf dem Rechner eindeutig ist, auf dem sie erstellt wurde. Gerade für COM-Komponenten ist es aber wichtig, dass die verwendeten GUIDs auch wirklich einzigartig sind. Im schlechtesten Fall kann es sonst passieren, dass zwei verschiedene Komponenten von verschiedenen Entwicklern zufällig eine gleiche GUID benutzen und sich so ziemlich in die Quere kommen.
Dass die bei Uwe generierten GUIDs nicht global eindeutig sind, erkennt man am letzten Block. Dieser stellt die MAC-Adresse dar, global eindeutige GUIDs von einem Rechner haben hier immer den gleichen Wert.
Bei Uwe erzeugte GUIDs:
- 1ab9096f-2101-4d6a-9a77-4b0be04d6b0a
- 2e27197f-4c53-45f1-8f83-0f9f89456962
- cc09efd4-967c-4eb1-8c4b-3023d9c85c1c
- e0297aad-cee3-4005-a4db-172af5fa8295
- ea0bc131-97fd-4c15-8007-2d79995c39e2
Mit uuidgen.exe erzeugte global eindeutige GUIDs (uuidgen.exe -x -n5):
- f225f880-a5a2-11d9-8512-000c6e33eb97
- f225f881-a5a2-11d9-8512-000c6e33eb97
- f225f882-a5a2-11d9-8512-000c6e33eb97
- f225f883-a5a2-11d9-8512-000c6e33eb97
- f225f884-a5a2-11d9-8512-000c6e33eb97
So wie ich Uwe kenne, wird er seine Seite aber ziemlich bald aktualisieren, so dass man bei Bedarf auch global eindeutige GUIDs erhält. 🙂
www.intelli(nerv)txt.com
In letzter Zeit ist mir aufgefallen, dass bei immer mehr Internetseiten nervende grüne Links auftauchen, die beim Überfahren mit der Maus erstaunlich wichtige Informationen anzeigen. Als Beispiel führe ich hier einmal einen Link zum Test von SpeedCommander 10 in der PC-Welt an.
Im Browser sieht es folgendermaßen aus:
Bewegt man nun den Mauszeiger über einen grün angemalten Begriff, dann erscheint folgende Information:
Alle diese Seiten enthalten eine Javascript-Funktion, welche anscheinend (ich kein JS-Experte) das nachträgliche Einfärben und Verlinken der Begriffe übernimmt.
<script language="javascript" > <!-- function switchIntelliTxt (state) { document.location.href="http://pcwelt.de.intellitxt.com/intellitxt/switch.asp?ipid=1589&state="+state+"&url="+encodeURIComponent(document.location.href); } //--> </script>
Da ich kein Freund von blinkenden Bildern und bunten Anzeigen bin, läuft bei mir schon seit Jahren der WebWasher im Hintergrund. Mit dem WebWasher kann man das Internet größtenteils recht werbefrei genießen. Da auch diese grünen unterstrichenen Texte mein ästhetisches Empfinden arg stören, filtere ich ab sofort auch alles von *.intellitxt.com/*.
Der Browser bekommt vom WebWasher jetzt eine leere Javascript-Funktion
<script language="javascript" > <!-- function switchIntelliTxt (state) {} //--> </script>
und die Seiten sehen ohne grüne Links wieder viel angenehmer aus:
Windows XP Profession x64 Edition
Auf der MSDN-Seite steht seit gestern die finale Version von Windows XP Professional x64 Edition zum Download bereit. MSDN-Subscribers können sie hier herunterladen.
Und nun warten wir gespannt auf die Beta 2 von Visual Studio 2005. SpeedCommander selbst ist übrigens schon auf 64bit portiert, die Archiver und die Such-/Syncroutinen müssen noch angepasst werden.