Archiv für die Kategorie ‘.Net Framework’

Source Code von MS-DOS 2.0 veröffentlicht

25 März 2014

Yuppiee! Der erste Schritt ist gemacht. Nach über 30 Jahren wird der Source Code von MS-DOS 2.0 veröffentlicht. Bis wir den Source Code von Windows 8.1 und nachfolgend sehen werden, wird es sicherlich nicht mehr ganz so lange dauern. http://www.heise.de/newsticker/meldung/Quelltexte-von-MS-DOS-und-Word-for-Windows-veroeffentlicht-2154723.html

Hier zum Source von MS-DOS: http://www.computerhistory.org/atchm/microsoft-ms-dos-early-source-code/, falls nicht wieder die Guru Meditation wegen Überlastung kommt.

MS-DOS 2.0 das war das Betriebssystem, welches damals auf den ersten IBM-XT-PCs lief, dem Nachfolger des ersten als solches benannten Personal Computer, dem IBM PC. Da gab es auch schon Festplatten mit 10MB und so, ach und die flexiblen Scheiben, die 5 1/4 Zoll großen, ähm – ah ja – Floppy Disks! So ein PC war damals richtig schwer und heute tragen wir um 100 ja sogar 1000fach leistungsfähigere Geräte in der Hosentasche. Wer das alte Feeling nochmal erleben möchte, hier der Link zum MS-DOS 2.0 Emulator im Browser: http://jsmachines.net/configs/pc/machines/5160/cga/256kb/demo/

Warum es bei Windows 8.1 keine 30 Jahre bis zur Source Code Veröffentlichung dauern wird? Na weil das .Net Framework 4.5.1 bereits in seiner reinsten Form einsehbar ist: http://referencesource.microsoft.com/. Auch sind weite Teile von ASP.NET bereits unter Open Source verfügbar.

Schließlich wird Microsoft irgendwann gezwungen sein allen Source Code zu veröffentlichen, da keiner mehr den ganzen Müll warten will, den die da über die Jahre angehäuft haben. Denen gehen ja jetzt schon die ganzen Techniker aus, die sich mit dem ganzen Zeugs beschäftigen wollen bzw. die da überhaupt noch durchblicken. Man sieht dies ganz deutlich in vielen Microsoft moderierten Foren. Was da teilweise für Antworten von MS-Mitarbeitern kommen. Oder wie oft fehlt es an technischen Beschreibungen in der Knowledge Base oder Technet. Alles klare Anzeichen, dass die letzten Jahre viel in die falsche Richtung lief. Aber die Cloud soll es ja retten. Mal sehen, was nächste Woche auf der Build der neue Oberindianer von sich gibt.

Microsoft .Net Framework 3.5 unter Windows 8 offline nachinstallieren

23 August 2013

Zum Glück sind die nötigen Dateien auf der Windows 8 DVD enthalten, somit geht es schnell:

Dism.exe /online /enable-feature /featurename:NetFX3 /All /Source:D:\sources\sxs /LimitAccess

Im obigen Beispiel ist das DVD-Laufwerk unter D: zu finden.

Wers bebildert braucht, wird hier fündig: http://support.microsoft.com/kb/2785188

In den Niederungen von SecureString mittels Powershell

30 Dezember 2012

Im ersten Blogbeitrag zu SecureString bin ich auf die allgemeine Anwendung von SecureStrings in Powershell und indirekt im .Net-Framework eingegangen. http://newyear2006.wordpress.com/2012/12/30/spa-mit-net-securestring-und-powershell-oder-sicheres-speichern-und-einlesen-von-passwrtern/

Wenn man mit den SecureStrings herumspielt, fällt einem schnell auf, dass diese quasi immer einen gleichen Header verwenden. Dieser beginnt immer mit der folgenden Zeichenfolge:

01000000d08c9ddf0115d1118c7a00c04fc297eb

Ab hier wird es nun interessant. Wenn man Google bemüht, kommen nicht all zu viele Treffer bei raus: https://www.google.de/search?q=01000000d08c9ddf0115d1118c7a00c04fc297eb. Aber unter den wenigen Treffern, sind wahre Perlen dabei! Denn es geht um nichts anderes als um eine eindeutige Kennung für DPAPI BLOBs welche von Windows seit Windows 2000 verwendet werden um Passwörter sicher in der Registrierung, Festplatte und Speicher abzulegen. DPAPI steht für Data Protection API. http://msdn.microsoft.com/en-us/library/ms995355.aspx.

Bleiben wir zunächst bei Powershell. Michal Grzegorzewski hat auf seiner Seite die Einträge mittels Debugger auseinandergenommen, hier die englische Übersetzung mittels Google: http://translate.googleusercontent.com/translate_c?depth=1&hl=de&prev=_dd&rurl=translate.google.de&sl=auto&tl=en&u=http://zine.net.pl/blogs/mgrzeg/archive/2011/03/11/dpapi-internals-a-securestring-w-powershellu.aspx&usg=ALkJrhhOdJ83W5rHYAcEnuML-v-KZ1KqNw. Dabei hat er festgestellt, dass Powershell die Methode Protect aus der ProtectedData Klasse aus dem .Net-Framework verwendet. http://msdn.microsoft.com/de-de/library/system.security.cryptography.protecteddata.protect.aspx. Protect verwendet wiederum CryptProtectData aus Crypt32.dll. http://msdn.microsoft.com/en-us/library/windows/desktop/aa380261(v=vs.110).aspx. Ein Punkt der bei Powershells ConvertFrom-SecureString und ConvertTo-SecureString zu kurz kommt, ist die Sache dass es sich um benutzerbezogene Verschlüsselungen handelt. D. h. ein Passwort welches mittels ConvertFrom-SecureString als verschlüsselter Standardstring konvertiert und gespeichert wurde, kann nur von dem selben Benutzer auf dem ursprünglichen Rechner wieder gelesen und verwendet werden! Um die Sache dann noch weiter zu komplizieren, sei noch darauf hingewiesen, dass das verwendete Passwort des Benutzers auch noch eine Rolle spielt, was wiederum beim Zurücksetzten von Passwörtern wichtig werden kann: http://support.microsoft.com/kb/309408. Zu welchen Probleme das benutzerbezogene Speichern führen kann, schildert schön dieser Artikel: http://blog.codeassassin.com/2012/05/17/powershell-remoting-user-profiles-delegation-and-dpapi/.

Im zweiten Bereich seines ersten Blogeintrags unter “DAPI Internals” streift Grzegorzewski noch die Geschichte von Masterkeys und dass auf jedem Windows immer die vorhergehenden Keys gespeichert sein müssen, um auf ältere, verschlüsselte Daten zurückgreifen zu können. Thema CREDHIST. Aber das Thema lassen wir außen vor. Im zweiten Blog-Artikel geht er dann noch näher auf die Internas von DAPI Blobs ein http://translate.google.de/translate?hl=de&sl=auto&tl=en&prev=_dd&u=http%3A%2F%2Fzine.net.pl%2Fblogs%2Fmgrzeg%2Farchive%2F2011%2F03%2F30%2Fdpapi-internals-a-securestring-w-powershellu-cz-2.aspx. Dort nennt er Picod and Bursztein, welche das Tool libDPAPIck.dll, zu finden unter http://dpapick.com/ entwickelt haben. Das Tool erlaubt das Lesen von EFS-verschlüsselten Laufwerken von Linux oder anderen Offlinesystemen aus.

So nach dem kleinen Ausflug, wieder zurück zum Thema SecureStrings und Powershell. Im ersten Artikel http://newyear2006.wordpress.com/2012/12/30/spa-mit-net-securestring-und-powershell-oder-sicheres-speichern-und-einlesen-von-passwrtern/ wurde ja schon gezeigt, wie man ein Passwort wiederherstellen und sichtbar machen kann. Nun wollen wir die von Grzegorzewski verwendete Methode mittels Powershell auf den verschlüsselten Standardstring anwenden.

Wir haben also aus unserem ersten Artikel die Zeichenfolge

01000000d08c9ddf0115d1118c7a00c04fc297eb01000000d13e0b3adb59f6469325c229ee5b0d520000000002000000000003660000c0000000100
00000d57efc5b5ccd1e52e71296ec9b91a3530000000004800000a0000000100000006b946cd8b1c877db8c8ae6f39f4932bd10000000858fb31747
0ef57f405d954a5857409a14000000e2154da0885013dc5dbf21097c61c1d429f1e8ce

Dabei handelt es sich um einen Hexstring. Für den Aufruf von Unprotect http://msdn.microsoft.com/en-us/library/system.security.cryptography.protecteddata.unprotect wird als Parameter ein Bytearray benötigt. Dazu benötigen wir als erstes eine Hilfsfunktion, welche den verschlüsselten Standardstring in ein ByteArray umwandelt, diese gibt es hier: http://www.sans.org/windows-security/2010/02/11/powershell-byte-array-hex-convert und nennt sich Convert-HexStringToByteArray. Also los gehts:

# $es enthält obigen String
Import-Module .\HexHelper.PS1
$eb=Convert-HexStringToByteArray $es
$mb=[System.Security.Cryptography.ProtectedData]::Unprotect($eb,$null,"CurrentUser")
[System.Text.Encoding]::Unicode.GetString($mb)

Zurück bekommen wir dann das ursprüngliche “Hallo”.

Dabei gibt es noch ein paar Dinge zu beachten. Der Aufruf von Unprotect funktioniert erst, wenn davor ConvertFrom-SecureString bereits benutzt wurde! Falls dies nicht der Fall ist, bekommt man die Fehlermeldung

Der Typ [System.Security.Cryptography.ProtectedData] wurde nicht gefunden: Vergewissern Sie sich, dass die Assembly, die diesen Typ usw…

Zum Warmlaufen kann man diesen Befehl vorher verwenden:

Read-Host – AsSecureString | ConvertFrom-SecureString

Wie oben bereits geschrieben, die Strings sind immer benutzerbezogen, wenn man also den String auf einer anderen Maschine versucht zu verarbeiten, erhält man die Meldung:

Ausnahme beim Aufrufen von "Unprotect" mit 3 Argument(en):  “Schlüssel ist im angegebenen Status nicht gültig."

Spaß mit .Net SecureString und Powershell oder sicheres Speichern und Einlesen von Passwörtern

30 Dezember 2012

Wer sich per .Net dem Thema SecureString annähert wird sich irgendwann fragen: “Warum bekomm ich den hinterlegten String nicht einfach zurück?”. Tja die Sache liegt in der Natur des SecureString selber. Er soll sicher sein!

Fangen wir mal mit einer einfachen Geschichte an, man möchte ein Passwort sicher eingeben:

PS> $pw=Read-Host –AsSecureString
*****
PS>

Sieht schon mal gut aus. Meine Passworteingabe lautete Hallo und es wurden aber nur Sternchen angezeigt. Wer jetzt denkt, man bekommt bei Abfrage von $pw das Passwort der täuscht sich:

PS> $pw
System.Security.SecureString

OK, dann halt über ein Property?

PS> $pw | Get-Member

   TypeName: System.Security.SecureString

Name         MemberType Definition
—-         ———- ———-
AppendChar   Method     void AppendChar(char c)
Clear        Method     void Clear()
Copy         Method     securestring Copy()
Dispose      Method     void Dispose(), void IDisposable.Dispose()
Equals       Method     bool Equals(System.Object obj)
GetHashCode  Method     int GetHashCode()
GetType      Method     type GetType()
InsertAt     Method     void InsertAt(int index, char c)
IsReadOnly   Method     bool IsReadOnly()
MakeReadOnly Method     void MakeReadOnly()
RemoveAt     Method     void RemoveAt(int index)
SetAt        Method     void SetAt(int index, char c)
ToString     Method     string ToString()
Length       Property   int Length {get;}

Na supi! Nur Length ist als Property vorhanden. Na dann vielleicht ToString()?

PS> $pw.ToString()
System.Security.SecureString

Nene, das Ding soll ja sicher sein!

Übrigens was gibt Length zurück?

PS> $pw.Length
5

Das würde passen, “Hallo” hat genau fünf Buchstaben. Kurz gesagt, es gibt keine direkte Möglichkeit den String zurückzubekommen.

Wofür braucht man nun das Ding? Die aktuelle Beschreibung auf MSDN (V4.5), gibt keinen Tipp. http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx

Also mal etwas recherchiert:

Sicher gibt es noch mehr Stellen, aber die kleine Auswahl sollte erst mal reichen.

OK, der Anwendungszweck gegeben, aber was kann ich damit anfangen? Vor allem im Zusammenhang mit Powershell? Ein erster Hinweis steht in der SecureString Doku auf MSDN:

Note that SecureString has no members that inspect, compare, or convert the value of a SecureString. The absence of such members helps protect the value of the instance from accidental or malicious exposure. Use appropriate members of the System.Runtime.InteropServices.Marshal class, such as the SecureStringToBSTR method, to manipulate the value of a SecureString object.

Aha, man muss also in die Niederungen der InteropServices absteigen. Dann legen wir gleich mal los:

PS> $BSTR=[System.Runtime.InteropServices.marshal]::SecureStringToBSTR($pw)
PS> $BSTR
39018744
PS> $pws = [System.Runtime.InteropServices.marshal]::PtrToStringAuto($BSTR)
PS> $pws
Hallo
PS> [System.Runtime.InteropServices.marshal]::ZeroFreeBSTR($BSTR)

Hier findet nun die ganze Show statt. Zuerst holt man sich mittels SecureStringToBSTR die ursprüngliche Eingabe und einen Pointer auf die Stelle, wo der String nun temporär abgelegt wird. Bei PtrToStringAuto wird der temporäre String ausgelesen, zurückgegeben und in $pws gespeichert. Mit ZeroFreeBSTR wird der temporäre String wieder freigegeben, bzw der temporäre Speicherplatz mit Nullen überschrieben (Secure!). Blöd nur, dass wir das Passwort nun in $pws haben, denn ab nun ist die Sache nicht mehr sicher!!

Hier noch der Link zu SecureStringToBSTR: http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshal.securestringtobstr.aspx

Damit schließt sich der Kreis. Aber Moment, da geht noch mehr.

Passwörter in Dateien speichern
Es gibt nämlich die tollen Funktionen ConvertTo-SecureString und ConvertFrom-SecureString. Wer glaubt, damit ließe sich obige Prozedur abkürzen, der täuscht sich. Denn diese dienen nur dazu den SecureString zu serialisieren bzw. in einen Standard-String zu wandeln, um ihn z. B. in einer Datei speichern zu können.

Machen wir genau dies und speichern unseren String mal in einer Datei, dazu wandeln wir ihn zuerst, lassen ihn ausgeben und prüfen ob es ein String ist:

PS> $pwe = ConvertFrom-SecureString –SecureString $pw
PS> $pwe
01000000d08c9ddf0115d1118c7a00c04fc297eb01000000d13e0b3adb59f6469325c229ee5b0d520000000002000000000003660000c0000000100
00000d57efc5b5ccd1e52e71296ec9b91a3530000000004800000a0000000100000006b946cd8b1c877db8c8ae6f39f4932bd10000000858fb31747
0ef57f405d954a5857409a14000000e2154da0885013dc5dbf21097c61c1d429f1e8ce
PS> $pwe.GetType()

IsPublic IsSerial Name                                     BaseType
——– ——– —-                                     ——–
True     True     String                                   System.Object

PS> Set-Content –Value $pwe –Path pwenc.txt
PS> type .\pwenc.txt
01000000d08c9ddf0115d1118c7a00c04fc297eb01000000d13e0b3adb59f6469325c229ee5b0d520000000002000000000003660000c0000000100
00000d57efc5b5ccd1e52e71296ec9b91a3530000000004800000a0000000100000006b946cd8b1c877db8c8ae6f39f4932bd10000000858fb31747
0ef57f405d954a5857409a14000000e2154da0885013dc5dbf21097c61c1d429f1e8ce

Perfekt. Damit hat man eine saubere Möglichkeit gefunden Passwörter sicher abzuspeichern. Um sicher zu gehen, dass dem so ist, muss man die Sache natürlich auch wieder rückwärts machen können.

SecureString-Passwörter aus Dateien auslesen
Die Geschichte ist einfach erzählt

PS> $pw=Get-Content pwenc.txt | ConvertTo-SecureString

Damit kann man $pw wieder bei SecureStringToBSTR, wie oben gezeigt anwenden und bekommt das gespeicherte Passwort im Klartext zurück.

Fehlermeldungen bei Installation von Programmen die das .Net Framework 3.5 unter Windows 8 oder Windows Server 2012 benötigen

16 August 2012

Wenn es Probleme bei der Installation einer Anwendung gibt, die dass .Net Framework 3.5 benötigt, so könnten aktuell drei verschiedene Fehlernummern auftauchen. In allen drei Fällen gibt es unterschiedliche Gründe warum es nicht klappt. Sei es der Download funktioniert nicht oder die Dateien sind im hinterlegten Pfad nicht zu finden.

0x800F0906 – CBS_E_DOWNLOAD_FAILURE

0x800F081F – CBS_E_SOURCE_MISSING

0x800F0907 – CBS_E_GROUPPOLICY_DISALLOWED

Wie man das Problem löst und wie man am besten vorgeht, beschreibt dieser Artikel: http://support.microsoft.com/kb/2734782/en-us

Weitere Infos hält auch dieser Artikel parat: http://msdn.microsoft.com/library/windows/hardware/hh975396

MSBuild.EXE ist im Extended .Net Framework 4.0 enthalten

5 Oktober 2011

Um bestimmte Build-Skripte auf einem Rechner laufen zu lassen, die auf MSBUILD.EXE der Version 4 beruhen, wird das Extended .Net Framework 4.0 benötigt. Es reicht nicht die Client Version.

http://www.microsoft.com/downloads/de-de/details.aspx?familyid=0a391abd-25c1-4fc0-919f-b21f31ab88b7&displaylang=de

oder für Core Server:

http://www.microsoft.com/downloads/de-de/details.aspx?familyid=c2794455-274d-4363-ade6-e69008a24d8a&displaylang=de

Top Einführung in PNRP per NETSH

22 Mai 2011

Was man mit den Clouds von PNRP bei IPv6 alles anstellen, zeigt sehr einfach dieser Screencast: http://channel9.msdn.com/Blogs/SlickThought/Peer-to-Peer-Series-Part-1-Intro-to-PNRP

Daneben wird auch die komplette Programmierung über das .Net-Framework gezeigt:
http://channel9.msdn.com/Blogs/SlickThought/Peer-to-Peer-Series-Part-2-Registering-Names-with-PNRP-API

COPY CON unter Powershell

6 Mai 2011

Leider funktioniert COPY CON unter Powershell nicht, da CON nicht mehr als Eingabekonsole erkannt wird. Es gibt nun aufwendige Geschichten, wie z. B. http://www.nivot.org/nivot2/post/2008/04/02/HowToCopyConTexttxt
InPowerShellUpdated.aspx
.

Aber wenn man mal auf die schnelle auf einem anderen Rechner ein paar Befehle speichern muss, dann hilft folgendes:

[System.Console]::in.ReadToEnd() > meineDatei.ps1

Am Ende wird wie gewohnt mit F6 oder STRG+Z abgeschlossen.

Etwas spannender, vor allem kürzer ist die Variante:

PS C:\temp> ‘
>>Mein Text
>>’ > test.txt
>>

Entscheidend ist das einfache obere Anführungszeichen, danach kann man beliebig viele Zeilen schreiben. Abgeschlossen wird wieder mit oberem Anführungszeichen. Gespeichert wird dann durch das Weiterleiten mit > an die Datei test.txt. Am Ende um >> los zu werden, muss noch einmal Return eingegeben werden.

In beiden Varianten stehen mit den Pfeiltasten die Eingabehistorie ganz normal zu Verfügung.

Datei Hashes wie CRC-32, MD5, SHA1 oder SHA256 unter Windows erstellen

8 Dezember 2010

Dieses Tool erstellt erstellt Datei Hashes für beliebige Dateien unter Windows und da es in C# geschrieben wurde, steht es auch auf anderen Plattformen wie Mono zur Verfügung: http://blogs.msdn.com/b/delay/archive/2010/12/06/hash-for-the-holidays-managed-implementation-of-crc32-and-md5-algorithms-updated-new-release-of-computefilehashes-for-silverlight-wpf-and-the-command-line.aspx

WPF Anwendung kann aus 16bit Umgebung heraus nicht gestartet werden

7 Januar 2010

Wenn man per eine 16bit Umgebung ausführt bzw. command.com direkt ausführt und dann aus dieser Umgebung heraus versucht eine WPF Anwendung zu starten, der bekommt einen AppCrash serviert.

Die Lösung des Problems in der 16bit Umgebung

set windir=C:\Windows

zu setzen, danach konnte die WPF Anwendung gestartet werden. Hintergrund dürfte die Suche nach den im System verfügbaren Zeichensätzen gewesen sein. Da windir nicht bekannt war, wurde c:\windows\fonts nicht gefunden.

Wenn man windir nicht per Commandline direkt setzen kann, dann muss die Zuordnung innerhalb der AUTOEXEC.NT erfolgen!


Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.