タグ別アーカイブ: VMWare

VMWare PlayerのOS別3D性能比較

誤解されないように最初に書いておくと、ゲストOSの比較。
単純に3DMark06で比較しただけだがまあキニシナイ。

で、条件。
ホストは以下のようなスペック

CPU: Core i7 920
メモリ:どっかのDDR3 2G*3 1333 トリプルチャネル
グラボ:GTX 295
OS: Windows 7 Ultimate 64bit

まあ関係しそうなのはこの辺か。

で、ゲストは以下のOSを比較

Windows XP Professional 32bit
Windows XP Professional 64bit
Windows 7 Ultimate 32bit
Windows 7 Ultimate 64bit

OS以外の条件は以下の通り

CPU: Core i7 920 2コア割り当て
メモリ: 2G
仮想化エンジン:Intel VT-x/EPT または AMD-V/RVI
画面サイズ:1280*1024
備考:DirectXはすべて最新にして、Windows Updateで重要な更新を全部当てた状態
使用ベンチマーク: 3DMark06

んで、結果

Windows XP 32bit 2675
Windows XP 64bit 4846
Windows 7 32bit 7211
Windows 7 64bit 7280

XPの32bit惨敗でござる。
7の32bitと64bitはまあ誤差みたいなもんだからいいとして、XPの方は明らかな差が。
まあ、XPはサービスパックも32bitの方はSP3まであるが64bitの方はSP2まででなにげに2003 Serverと同じサービスパックだからたぶんアーキテクチャ的にも違うんだろう。
でもサーバ用途なはずな64bitの方が3Dパフォーマンスがでるっていうのも皮肉というかなんというか。
んでまあ、ついでに、XPは描画もなんかおかしくなった。
32bit, 64bit共通で。
なんというか、説明するよりみてもらう方がはやい。

これXP

んで、こっち7。

とりあえずVMWare PlayerのDirectX周りはWindows 7の方がいけてるっぽい。
でもまあハードウェアとかその辺の関係もあるやもしれない。
仮想マシンで3Dグラフィック考えている人は何も考えずにXP 32bit定説とか思わずにほかのゲストOSも検討した方がよさげだ。

ゲームの多重起動とか窓化とか

ゲームによっては多重起動したいやつとか窓化したいゲームとかある。
まあたいてい特定ジャンルのオンラインゲームだけど。
で、最近書いてるとおり仮想マシン使えば種別問わず共通の方法でそれらを実現できるわけだけども、検索できてるやつみて気づいた。
やり方っていうやり方は大して書いてないことに。
ということでまとめてみる。

続きを読む ゲームの多重起動とか窓化とか

仮想環境3D性能比較。。。のつもりが

比較しようとおもったんだが。
3dmark06が動いたのがVMWare Playerだけだった。
別のベンチつかってもいいっちゃいいけど面倒だった。
VirtualBoxでもいけるかと思ったんだけど、shader model 2.0に対応していないらしくて動かず。
Direct3Dは動いたんだけどね。
バージョン7はこけてたけど。
DirectX 8,9はとりあえずVirtualBoxでもいけるらしい。
ということでVMWare Playerで3dmark06動かしてみた。
結果は1280*768で2810。
Geforce 6800無印くらいみたい。
余談だけどメインだと1360*768で18537。

ここでちょっとDirectX 10を試したくなった。
Windows7のゲストを作って3dmark vantageを試してみる。
。。。が、DirectX 10は動作しないとのこと。
まあ、そうだよなー、と思いつつ、でもなんかさっきまでいじっていたXPと比べて妙に動きがしゃきしゃきしてる。
ダウンロードの速度とかもだいぶ速いような。
もしかして、とおもい、Windows7のゲストで3dmark06を実行。

あるぇえええええええええええええ。
なんかだいぶ速い。
スコアは8215。
ホストの40%くらいか。
7900GTXくらいにまでなってもうた。
VMWare toolsのディスプレイアダプタドライバの出来がとんでもに違うのかはたまたほかの理由なのかはよくわからないが、とりあえず少なくともうちの環境ではWindows XPよりもWindows7のゲストの方が遙かに性能がでる。
操作感からして、PCMarkとってもきっと差が出てる。
なんか想定外な発見だ。

Themida突破

ついさっきThemidaうぜええええええって叫んでたんだけども、なんか突破できちった。
ああ、暗号化の方じゃないよ、仮想マシン検出の方ね。
チートしたい人とかはそっちはどうでもいいんだろうけど、まあ探せばアンパッカーきっと見つかるだろうからがんばって。
んで、仮想化検出を突破出来たと言っても、正直自分でも細かいところはわかってない。
というかわかろうとしていない。
動けばいいやっていう感じで今回は調べてるので。
んでまあどういうながれかっていうと、いやね、VMってばれてるってことは、どっかをみてVMかどうかを判別してるんだから、そこをどうにかすれば突破出来るのはまあ誰でも察しがつくだろう。
そこで、まあ一番資料が豊富そうなきがしてなおかつDirect3dに対応してるVMWareでなんかないものかとおもって、vmxの設定のリファレンスないかとおもってさがしてみたのよ。
で、まあこんなところがでてきた。
で、眺めていたら以下のような記述が。

disable VM-detection

あ、はい。
設定させていただきます。

this example prevents that the app
Sword of the New World
detects that it is running in a VM

あ、はい。
設定させていただきます。

両方の設定をくっつけたのが以下。

monitor_control.disable_directexec = "true"
monitor_control.disable_chksimd = "true"
monitor_control.disable_ntreloc = "true"
monitor_control.disable_selfmod = "true"
monitor_control.disable_reloc = "true"
monitor_control.disable_btinout = "true"
monitor_control.disable_btmemspace = "true"
monitor_control.disable_btpriv = "true"
monitor_control.disable_btseg = "true"
monitor_control.virtual_rdtsc = "false"
monitor_control.restrict_backdoor = "true"
isolation.tools.getPtrLocation.disable = "true"
isolation.tools.setPtrLocation.disable = "true"
isolation.tools.setVersion.disable = "true"
isolation.tools.getVersion.disable = "true"

それを対象の仮想マシンのvmxに設定して起動。
あ。突破出来た。
んが、くそ重くなってどうしようもない。
んでいじくってみた結果、monitor_control.virtual_rdtsc = “false”は除去。
軽くなった。
重いのはこいつが原因だったみたい。
時間の同期パラメータだそうだ。(falseだとホストの時刻を参照)
ということで以下が最終パターン。

monitor_control.disable_directexec = "true"
monitor_control.disable_chksimd = "true"
monitor_control.disable_ntreloc = "true"
monitor_control.disable_selfmod = "true"
monitor_control.disable_reloc = "true"
monitor_control.disable_btinout = "true"
monitor_control.disable_btmemspace = "true"
monitor_control.disable_btpriv = "true"
monitor_control.disable_btseg = "true"
monitor_control.restrict_backdoor = "true"
isolation.tools.getPtrLocation.disable = "true"
isolation.tools.setPtrLocation.disable = "true"
isolation.tools.setVersion.disable = "true"
isolation.tools.getVersion.disable = "true"

使用は自己責任で。

追記

その後、どこ使えばいいかちょこちょこいじって突き止めていったところ、一項目だけでいいことにたどり着いた。
それが以下。

monitor_control.restrict_backdoor = "true"

これなんなのかと思って前述のサイトでチェックしたら以下のような記述。

if you want to run VMware inside a VM you will need this setting – it may cheat any program that scans for the VMware-backdoor channel like Ken Katos vmchk.exe

It is NOT enough to cheat advanced VM-scanning methods like redpill or scoopy

かなり要約すると、仮想マシンじゃないふりを仮想マシンにさせるけど、高レベルなツールはだませないんだぜ、っていうフラグらしい。
先に説明読んでおけばまずこれだけで試したんじゃないだろうか。。。

んで、もうちょっと調べてみたらこんなのでてきた。

This closes the backdoor channel that VMware uses to communicate with guests via the vmware-tools.

なるほど、得心がいった。
VMWareがvmware toolsで通信するバックドアチャネルを閉じるのか。

Themidaうぜえええええええええええええええ

オンラインゲームとかで2垢とかやってアイテム受け渡しとかしたいときあるじゃない。
そういうときって、多重起動できないゲームとか、仮想化つかって仮想マシン上でゲーム起動して同時起動とかしたいじゃない。
で、やってみた。

うぜええええええええええええええええええええええ。
sorryじゃねーよぼけ。

themidaっていうのはプログラムを暗号化したりするいわゆるパッカーなんだけども、仮想マシン検出機能なんかもついていたりする。
そいつがxtrapに同梱されているらしくて、「Sorry, this application cannot run under a Virtual Machine」と。
んだが、これがまたウィルスと一緒にくっついてきてるやつなんかもある。
どういうことかというと、元々パッカーはプログラムが解析されたりするのがいやんなことから作られてるのだが、ウィルスなんかはもちろん解析されるとワクチン作られるのでいやんにきまってる。
そのため、パッカーで解析困難にするために一緒にくっつけてきたりするわけだ。
で、ウィルスの解析なんかは仮想化環境上でわざと感染させるようなのをおいて(ハニーポット)行ったりするわけで、こういうやつがいると非常に邪魔になるわけだ。
んでまあ、Themidaは実際ウィルスに搭載されてまき散らされたことがあり、その絡みでThemidaそのものをウィルスと認識して駆除しようとするウィルス対策ソフトもある始末。
別にゲームをハックするきもクラックするきもないしアセンブラなんてミジンコ程度しか読めないからそもそも出来ないし、ついでにパックされてればアンパックする気もないから読めるはずもないんだからVMで実行くらいさせろよksgってはなしだ。

ちなみに、VMWare Player, Virtual PC, VirtualBoxでだめだった。
XenはそもそもDirectXの関係で起動しなかった。