仮想化ベースのセキュリティが有効であるとVMware Workstationの仮想マシンが起動できない

Windows 10 Pro Version 1909
VMware Workstation 15 Pro 15.5.1
CPU: Intel Core i7-3520M

自端末へ VMware Workstation 15 Pro をインストールして幾ばくかの時間を隔てたのちに改めて仮想マシンの起動を試みたところ、見慣れぬエラーメッセージに見舞われて面食らった。曰く、

VMware Workstation と Device/Credential Guard には互換性がありません。VMware Workstation は Device/Credential Guard を無効にした後で実行することができます。詳細については、 http://www.vmware.com/go/turnoff_CG_DG を参照してください。

とのことである。調べてみるとWindows Defender Application GuardやWindows サンドボックスを導入すると仮想化ベースのセキュリティが有効になって、此れがVMware Workstationと相容れない情勢であるBIOSでIntel VT-xを有効にしてあっても無効であるものと判断されている。

何もしていないのに壊れたと憤慨したものであるが、Windows サンドボックスを有効にした覚えがある。何もしていないのに壊れたという申し立ては必ず嘘である。

こういう事では困るから慌ててWindows サンドボックスを無効にしたのであるけれども此れがちっとも効果が無い。コマンドプロンプトからmsinfo32を立ち上げて「システムの要約」→「仮想化ベースのセキュリティ」項目を確認すると値は「実行中」である。はてな、此は如何にと思案に暮れているとどうも無効にする手順が別に在る模様である。

先ずはローカルグループポリシーエディターを起動して、「コンピューターの構成」→「管理用テンプレート」→「システム」→「Device Guard」と辿る。そうして二つの設定「Windows Defender アプリケーション制御を展開する」「仮想化ベースのセキュリティを有効にする」を無効とする。

次いで幾つかのレジストリキーを削除する。

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LsaCfgFlags
HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\LsaCfgFlags
HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\EnableVirtualizationBasedSecurity
HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\RequirePlatformSecurityFeatures

自端末には EnableVirtualizationBasedSecurity しか見当たらなかったから此れのみ削除した。続いてコマンドプロンプトを管理者として実行して以下のコマンドを放り込む。全体どういう了見でこのUUIDが世に出たか知れないけれども兎に角、効く。

mountvol X: /s
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
mountvol X: /d

ここまでこなしたら端末を再起動する。起動中に Credential Guard を無効にするか否かを問われ、無効にするならWindowsキーもしくはF3キーを押下する。時間制限があるからもたついていると何もせぬままに起動が進行してしまう。

あらためてmsinfo32を実行すると無事、仮想化ベースのセキュリティが無効になり仮想マシンの起動も恙無く済んだ。VMware Workstation ProとWindows サンドボックスの両立はむつかしいようであるから欲を張らずに、仮想化ベースのセキュリティを都度、有効か無効に切り替えてどちらかを選ぶしかないようである。

参考:
Windows Defender Credential Guard の管理
“VMware Workstation and Device/Credential Guard are not compatible” error in VMware Workstation on Windows 10 host (2146361)

Tera Termで以ってtelnetで25番ポートへ接続してSMTPコマンドを打ち込むための設定

Tera Term 4.104

メールサーバの移行作業後にtelnetで以ってメール送信のテストをおこないたかったけれどもWindows10はデフォルトでTelnetクライアントが無効になっているようである。さりとて有効化は都合が許さなかった為に代わりにTera Termを用いるよう助言をいただいたものである。

ところがTera TermのTelnetで25番ポートへ接続するとSMTPバナーは表示されるもののキー入力をしても何ら反応がないので誠に困った。tcpdumpで様子を窺うと入力内容は送信されているようであるからエコーバックがなされていないような風情である。

調べると次のようにTERATERM.INIの設定を変更せねばならぬ模様である。

Telnet プロトコルに対応していないホスト(通常 23 以外のポート番号を使用)に TCP/IP 接続する場合、ローカルエコーを on に、送信する改行コードを CR+LF にする必要がある場合があります。

TCPLocalEcho=on
TCPCRSend=CRLF

TCPLocalEcho をonに、TCPCRSend をCRLFにセットすることで23番以外のポートへTelnetで接続した途端にローカルエコーが有効にされ、送信改行コードがCR+LFに変更されるというのである。

そうすると無事、操作を受け付けるようになった。

参考:
非 telnet TCP/IP 接続用の端末設定

Windows10の検索ボックスでWeb検索をおこなわないよう設定する

OS: Windows 10 Pro version 1903

素早くバッチファイルを呼び出して実行したりメモ帳のようなアプリケーションを起動するのに誠に有用な検索ボックスであるけれども、検索結果にWeb検索の候補が押し寄せてくるのが大変煩わしいからこれを無効にする。

まず検索ボックスから regedit で以って検索してレジストリエディタを起動する。

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Search へ移動して新規にDWORD値を追加し BingSearchEnabled と名付ける。データは0のままで宜しい。次いでCortanaConsentのデータも0にする。

改めて検索ボックスから検索をおこなうとWeb検索は最早機能していない。すっきりとして清々しい心持ちである。設定を施しても変化がない事もあったけれどサインインし直すと反映されていた。

コマンドプロンプトから一息に実施するならこういう具合である。

>reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Search" /v BingSearchEnabled /t REG_DWORD /d 0 /f
>reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Search" /v CortanaConsent /t REG_DWORD /d 0 /f

参考:
Win 10編: 検索ボックスから「ウェブ」を取り除く

コマンドプロンプトから時刻合わせを試みたけれども狙い通りの挙動にならない

OS: Windows 10 Pro version 1809

主として使用しているパソコンの時刻が日本標準時から1.2秒も進んでいたからコマンドプロンプトからチャッと時刻を同期して精密に時計を合わせようと試みたけれどもWindowsの時刻同期は挙動が掴み切れず生半可な知見で臨んだところ忽ち返り討ちである。

w32tmコマンド一度きりの実施で時刻が確り同期される場合もあれば何遍繰り返してもちっとも同期されないケースもあったから困る。まずはコマンドプロンプトを管理者として実行するところから始めねばならない。一先ず時刻同期の様子を確認しようと次のコマンドを流すとこういう有様である。

>w32tm /query /status
次のエラーが発生しました。 そのサービスを開始できませんでした。 (0x80070426)

Windows Time サービス(w32time)が実行されていないとw32tmコマンドの主たる機能が取り扱えないようである。w32timeを開始するにはこうである。

>net start w32time
Windows Time サービスを開始します.
Windows Time サービスは正常に開始されました。

改めて w32tm /query /status を実行すると時刻の同期にCMOS Clockを使うことを発見した。おおかたマザーボードに搭載されているCMOSの時計を照らし合わせに用いるという設定であるとおもうからこれをNICTが公開しているNTPサーバ ntp.nict.jp に切り替える。

>w32tm /query /status
閏インジケーター: 3 (同期未実行)
階層: 0 (未指定)
精度: -23 (ティックごとに 119.209ns)
ルート遅延: 0.0000000s
ルート分散: 0.0000000s
参照 ID: 0x00000000 (未指定)
最終正常同期時刻: 未指定
ソース: Local CMOS Clock
ポーリング間隔: 10 (1024s)

NTPサーバの指定に続けてカンマを配して同期モードを16進数でセットできる風情である。1,2,4はSymmetric ActiveとかいうNTPサーバ同士でやり取りを交わすためのモードであったからクライアントとして使うPCには相応しくないとおもってClientモードを用いる0x8を記述した。

>w32tm /config /update /manualpeerlist:ntp.nict.jp,0x8 /syncfromflags:manual
コマンドは正しく完了しました。

>w32tm /query /status | find "ntp.nict.jp"
ソース: ntp.nict.jp,0x8

そうしたら /resync オプションで以って手づから時刻を同期させる。

>w32tm /resync
再同期コマンドをローカル コンピューターに送信しています
コマンドは正しく完了しました。

ズレが解消されたか確認をすると何ら効果を齎していない風情であった。幾度か実施を繰り返して見たけれどもほとんど動きが見られない。此は如何にとおもって調べるとじわじわと時刻を調整してゆくslewモードと一息に時刻を同期させるstepモードが用意されていて、諸条件を満たすとslewモードになりそうでなければstepモードになるという仕組みである。

>w32tm /monitor /computers:ntp.nict.jp /nowarn
ntp.nict.jp[133.243.238.163:123]:
ICMP: 25ms 遅延
NTP: -1.1755319s ローカル コンピューターの時刻からのオフセット
RefID: 'NICT' [0x5443494E]
階層: 1

slewモードの条件を満たしたから時計がすぐに合わないのだといっときは納得したけれども腰を据えて条件式を計算したところぜんぜん要件を満足しないからstepモードでパッとずれが解消されることが期待される筈であるのにどうも挙動がわからない。

>w32tm /debug /enable /file:"%userprofile%\desktop\w32tm.txt" /size:0 /entries:0-300
プライベート ログを有効にするコマンドをローカル コンピューターに送信しています...
コマンドは正しく完了しました。

>w32tm /resync
再同期コマンドをローカル コンピューターに送信しています
コマンドは正しく完了しました。

>w32tm /debug /disable
プライベート ログを無効にするコマンドをローカル コンピューターに送信しています...コマンドは正しく完了しました。

デバッグログを出力するよう設定して時刻同期を実施した際の内容を眺めたけれどもなんだかむつかしくてslewモードで時計を合わせようとしている情勢で或ることくらいしか掴めない。

もうすっかり厭になってしまって捨て鉢で時刻の自動設定をオフにしてから時刻を徒に大きくずらして改めて時刻を自動的に設定する設定をオンに切り替えたところ、何がどう作用したかは知れないけれども期せずしてstepモードのような働きによって時刻のぶれが慎ましい値へ落ち着いた。

>w32tm /stripchart /computer:ntp.nict.jp /period:5

たいへん強引なやり方であるから決して常用できないけれども退っ引きならない情勢であるときは不承不承この方法を選択せざるを得ない。

参考:
第3回 w32tmコマンドとレジストリによるWindows Timeサービスの制御 (1/4)

HTTPSによる暗号化された通信のやり取りをWiresharkで復号して内容を読み取る

OS: Windows 10 pro version 1809
Wireshark 2.6.6 64-bit
Google Chrome 72.0.3626.96

或るサイトから取得されるファイルのURLを探ろうとしてWiresharkを立ち上げ通信を捕えても近頃はすっかりHTTPSでやり取りがなされるから、中身を覗き見ようとしてもEncrypted Application Dataという具合に暗号化されて出鱈目な文字がおどるだけであって具体的な内容は確認できない。そうするとリクエストヘッダであるとかレスポンスヘッダが全く定かでなくなるから一寸内容を知りたいときにこまる。

Google Chromeのショートカットアイコンを右クリックしてプロパティを開くと「リンク先」の欄にGoogle Chromeのexeファイルを示すパスが記載されているからその後にひとつ、半角スペースを付け加えてから --ssl-key-log-file オプションと値を続けて記す。値は、暗号化にまつわる情報を書き出してゆくファイルのパスを指定するのである。デスクトップへssl.txtとして情報をダンプするならこういう具合でよかった。

--ssl-key-log-file=%userprofile%\desktop\ssl.txt

Google Chromeをすっかり終了させ改めて起動するとデスクトップへssl.txtがひとりでに作成され暗号化に使われている各種の情報が詳らかに記載されてゆく。悪いやつの手に落ちると大変危ないファイルであるから厳重な管理のもとに扱わねばならない。

今度はWiresharkを起動して「編集」の「設定」を開く。

「Protocols」の項目を展開するとおびただしい数のプロトコルがずらりと並ぶからそのうち「SSL」を見つけて「(Pre)-Master-Secret log filename」という設定項目に、先に作成された暗号化にかかわる情報が溢れているファイルのパスを指定する。

そうして改めてWiresharkで以ってHTTPSの通信内容をキャプチャして中身を確認するとこういった具合である。

目論見通り暗号化された情報が復号されて具体的な内容が確認できる。

ショートカットのプロパティを編集する方法であると、のちに復号の必要がなくなったというのに設定を消し忘れて痛い目を見る恐れもあるから、一時的に利用する手立てとしてコマンドプロンプトを開いて SSLKEYLOGFILE という環境変数を定めてからGoogle Chromeを起動してやればのちに禍根を残す蓋然性が低くなって良いとおもう。

>set sslkeylogfile=%userprofile%\desktop\ssl.txt
>start "" "%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe"

参考:
NSS Key Log Format