自分自身が相当に迷ったのでメモ。
結論としては上記の通り。
Intel 760p SSD を刺していますが、普通に認識されて使えています。
どうもみむらです。
久しぶりに wasamusume の CTF の活動を再開したくなり、リハビリがてらに参加してみました。
結果としては98位。
3人だけでひっそりと参加していたのですが、結果としてはかなり上々かも。
というわけで、解いた問題についての Write-up です。
問題のおしながき:
・welcome_to_the_game
・babytrace
・know_your_mem
FLAG : OOO{Game on!}
ファイルを開くと出てくる。
FLAG : OOO{memory_objects_get_you_every_time}
claripy と angr で作られたトレーサを経由して問題のファイルを覗く問題。
プログラムは純粋に使うと2文字までしか表示されないようになっています。
0x856 の位置に “movzx eax,[rbp+eax+buf]” という処理があり
ここで、任意の位置の文字が “eax” に積まれます。
その処理を利用して、任意の文字の位置を読んでみます。
あとは上記を繰り返して、文字列を読んでいくとフラグが得られます。
FLAG : OOO{so many bits, so many syscalls}
実行すると下記のように、シェルコードを入れるように指示されます。
ここに、文字列長とシェルコードを入力するとそれが実行されます。
シェルコードで実現する必要があることは、
プログラムのどこかに読み込まれている「フラグ」のデータを探し出して
それを読み込んで表示すること。
また、10秒間のタイムアウト値が設定されているため、それを越えての探索は出来ません。
64bit 空間のメモリを全部探すのは現実的ではないので
スタック中から何か出ていないか探します。
下記のようなアセンブラを書いて、それをシェルコードとして与えます。
bits 64
section .text
global _start
_start:
mov rsi,rsp
mov rdx,70
mov rdi,1
mov rax,1
syscall
mov rax,0
ret
どうやら白く塗ってある場所に同じ表示が出ているのでこれが使えそう。
ただ大会期間中は、メモリ位置を考慮するのが面倒くさくなったので
別の方法を使いました。
“flag” の読み込みを r15 が指し示すメモリアドレスに読み込む処理が入っています。
というわけで下記のようなアセンブラを書いてみました。
bits 64
section .text
global _start
_start:
mov rsi,r15
mov rdx,50
mov rdi,1
mov rax,1
syscall
mov rax,r15
ret
結果としては下記の通り
というわけで r15 レジスタを参照するだけで解けました・・。
うーんこれで良いのだろうか・・。
ところで
フラグが OOO{so many bits, so many syscalls} なので
下記のようなコードを書くのが正しいのかもしれませんね・・?
(ただし速度が追いつかないので改良等をする必要は大いにあります)
bits 64
section .text
global _start
_start:
mov rsi,0x100000000000
_nextpage:
add rsi,0x1000 ; mmap のアライメント.
_nextbyte:
mov rdx,10
mov rdi,1
mov rax,1 ; write は今回の seccomp の設定で許可されていたので.
syscall
_faultcheck:
cmp al,0xf2 ;EFAULT
jz _nextpage
mov eax,0x4F4F4F7B ; egg "OOO{"
inc al
scasd
jnz _nextbyte
mov rax,rdi
ret
普通に Egg Hunter の Exploit code のもじりです(苦笑)
というわけで、
久しぶりに CTF やるのと、久しぶりにアセンブラ読み書きしてるのが楽しかったので
また機会があれば CTF やりたいかもしれません。
また家にメンバーを読んでやってたのですが、
あのワイワイした感じで解くのも面白かったし。であであー。
どうも、みむらです。
先日発表されたばかりの “Windows Terminal” を使ってみました。
とりあえず、これは今すぐ会社用PCとかにも入れておこうかと思いました。
普段使いそうなツール群を呼び出せるようにしてみたのですが、
結構使いやすそうな子のようです。
マイクロソフト社からちゃんとストア経由で今後出てくると思いますが
常に最新のものを触りたい!という人向けに、ビルド方法のメモになります。
執筆時点(2019年5月8日)では、下記のものを用意する必要があります。
1. Visual Studio 2017 (2019 だと上手くビルド出来ませんでした..)
2. Windows 10 (ストアアプリ扱いになります)
また、ビルドするためには Visual Studio 2017 にて
「C++ ユニバーサル Windows プラットフォームツール」を有効にする必要があります。
下記 URL より git clone を実施してソースコードを取得します。
https://github.com/microsoft/Terminal
Clone 完了後、”git submodule” を使用して、
依存関係にあるコードもダウンロードします。
# git submodule update –init –recursive
コードの準備が完了したら “OpenConsole.sln” を Visual Studio 2017 で開きましょう。
“CascadiaPackage” を右クリック → ストア → 「アプリパッケージの作成」と選択します。
そして「サイドロード用」のパッケージとして、
お使いのアーキテクチャにチェックを入れて “Release” となっていることを確認してパッケージを作成します。
ビルド中、もの凄くメモリを使います。
下手をすると下記のようなエラーが出てコンパイルエラーになることもあります。
13>c1xx : error C3859: PCH の仮想メモリを作成できませんでした
13>c1xx: note: PCH: ファイル マップ全体にメモリをコミットできません
13>c1xx: note: 詳細については https://aka.ms/pch-help をご覧ください
そのときは Visual Studio の同時コンパイル数を1にすることで
改善できる場合があります。
ツール → オプション → プロジェクトおよびソリューション → ビルド / 実行
にて「平行してビルドするプロジェクトの最大数」を1にします。
下記のようにビルドが完了したら、Add-AppDevPackage.ps1 を実行します。
あとはウィザードに従って進めればインストール完了となります。
なお、このファイルを常用するコンピュータに持って行き、
インストールをすることで他のコンピュータでも利用することが可能になります。
開発者モードになっているかを確認しましょう。
早速スタートに登録されましたのでバンバン使っていきましょう。
初回起動時はこんな感じの無機質なターミナルが表示されます。
ここで Ctrl + T を押しましょう。
下図のようにいい感じにタブと設定メニューが登場します。
では右端のボタンから “Settings” を開きましょう。
下図のように json が表示されると思いますので、適宜成形 (Visual Studio であればドキュメントの整形機能があります)して眺めます。
まず、全体設定ですが確認できるのは次の通りです:
“alwaysShowTabs” はタブを画面に常時表示するかどうか。これについては “true” に書き換えておいた方が無難です。
“showTerminalTitleInTitlebar” はタイトルバーにアクティブなタブのタイトルを表示させるかどうか。
“experimental_showTabsInTitlebar” はタブをタイトルバー部分に表示するかどうか。
つぎに “profiles” の中ですが、ここに項目を追加すると呼び出せるプログラムが増えます・・!
お好きなフォントを “fontFace”, “fontSize” で設定し、
透過させたい場合は “useAcrylic” を true にした上で、 “acrylicOpacity” (1に近いほど無透過)を設定すると良いと思います。
参考までに、私の設定ファイルも置いておきます。参考までにどうぞ・・!
https://gist.github.com/mimura1133/4e65fdbf8fd686d3a3691bd9b43678ac
発表されてすぐさま使ってみて、かなり使い勝手がよさそうでしたので
私としては早く標準のコマンドプロンプトの代わりになって欲しいなと思うそんな今日この頃です。
巻末に、私の環境でビルドしたファイル(x64 専用)もおいておきます。
どうしてもビルドに失敗してしまうかたがいれば、自己責任にてお試しください。
http://mimumimu.net/beta/programs/CascadiaPackage_1.0.0.0_Test.zip
どうも、みむらです。
しばらく記事を書かない間に、新暦が発表され、
そして私も会社が変わってしまいました。
最近はアプリ診断員にジョブチェンジしました。
IDA さんが友達です。
特に最近は iOS アプリを見ているので、
フォレンジックネタとか iOS に関するセキュリティ診断ネタであれば、
凄く話に乗れると思います。
それ以外には、Unity のアプリとか (lib2cpp の読み解きとか)
Windows ならユーザランドからカーネルランドまで。お話まってます。
閑話休題。
新暦と言えば、やはり新暦対応でしょう。
私も新暦が発表された直後から「なんとしても対応しよう」と遊んでました。
などなど。
今回は、もし「令和じゃない元号にします」と発表があった際に
素早く手持ちの環境を自己責任において対応させられるように(要出典)
Windows と Linux の対応の仕組みを見ておこう、とそういうテーマです。
Windows の場合はレジストリキーを追加します。
(注:本修正を実施した事によりご利用中のプログラムに不具合が発生しても本サイトは責任を負いかねますと共に、くれぐれもプログラムの製造元へ連絡されませんようお願い致します)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras 以下に
年号情報が詰まっていますので
REG_SZ 型にて
キー名:”<開始年> <開始月> <開始日>”
値:”<フル読み>_<代表する一文字>_<英語表記>_<英語短縮表記>”
のフォーマットにてキーを生成すれば OK のようです。
この値を設定すると、
この値を参照しているプログラムの処理系であれば
基本的に新年号に対応出来るようになります。
Linux の場合は locale ファイルを修正します。
(注:本修正を実施した事によりご利用中のプログラムに不具合が発生しても本サイトは責任を負いかねますと共に、くれぐれもプログラムの製造元へ連絡されませんようお願い致します)
locales ファイルは下記のパスに保存されています。
(Arch Linux, CentOS 7 にて確認)
/usr/share/i18n/locales/ja_JP
修正するのは、”era” の部分。
「○○元年」(+1 で始まるレコード)と「○○年」(+2 で始まるレコード)
を用いて年号の変換を行います。
そして年号は UTF-16BE の順番で書いていきます。
できあがった例は次の通り
1つめの “+:1:2019//05//01:2019//12//31:<U4EE4><U548C>:%EC<U5143><U5E74> は
2019年5月1日~2019年12月31日までを「令和(<4EE4><548C>) 元年(<5143><5E74>)」 と
表記するというもの。
2つめの “+:1:2020//01//01:+*:<U4EE4><U548C>:%EC%Ey<U5E74> は
2020年1月1日以降を「令和(<4EE4><548C>) %Ey(+2)年(<5E74>)」 と
表記するというものになります。
ですので上記のような ja_JP ファイルを作成し、locale-gen をすると
下記のように新暦に対応することができます。
Windows や Linux のシステムがかなり柔軟に新暦対応させられる作りになっていることはおわかりいただけたかと思います。
ただ、これは一人のソフトウェア作者としてのコメントではありますが
全てのプラットフォームが上記で挙げたような簡単な方法で
すぐ対応出来るようになっているわけではありません。
また、上記のようなレジストリキーやファイルを参照するものであっても
(平成)31年から(令和)1年へ変わるわけですので
エラーが発生するシステムも十二分に考えられます。
ですので上記の方法で対応ができ、
ご利用のソフトウェアで問題なく稼働した場合でも
これは運が良かったという程度にお考えいただき、
ベンダーの正式対応を基本的にはお待ちいただくようにしてください。
上記のリスクにご理解いただけるかたで、新しいものに楽しみを感じるかたは
ぜひ自己責任において新暦対応を一足お先にお試しくださいませ。
なお、それによりデータ破損等が発生しても当方では責任を負いかねます。
・・というわけで。であであー。
どうもみむらです。
VirtualBox や VMware だとできるのに、
Hyper-V だと出来ない事。色々とあります。
多分一番大きなところは、共有クリップボードでしょうか。
最近 ESXi に VMware Remote Console でつなぎに行ってもクリップボードが使えなくなりまして
なんとも悲しい思いをしています。
さて。
Hyper-V では Linux で通常セッションは普通使えないのですが、
ふと「拡張セッションは本当に有効に出来ないのかな・・?」と思いやってみました。
結論としてはクリップボードの共有も、画面の高速な描画も出来した。
1. 普通に Kali Linux をインストールします。
(Install the Kali Linux.)
2. 下記のスクリプトを Root で実行します。
(Execute the script with Root account on Kali Linux.)
bash –c “$(curl –sL https://go.mimumimu.net/2CQlyKy)”
# Do you want to check the code?, please check the page:
# https://gist.github.com/mimura1133/25451be04929d65993e0fb658d0b6890
3. Kali Linux をシャットダウンします。
(Shutdown the Kali Linux.)
4. 管理者権限の PowerShell で下記のコマンドを実行します
(Execute the PowerShell Script with Administrator Account on Host Windows OS)
Set-VM –VMName <YOUR_VM_NAME> -EnhancedSessionTransportType HvSocket
5. Kali Linux を起動します。
(Start the Kali Linux VM.)
正常にインストールが完了していれば、
5番で起動した際に、下記のように「拡張セッション」で接続しなおすように聞いてきます。
( When open the VM window, it will ask you an window-size settings if you’re finished the installation successfully. )
元ネタはこれ。
( Sneak Peek: Taking a Spin with Enhanced Linux VMs – Virtualization Blog )
下図が凄く分かりやすいのですが、
Hyper-V の 拡張セッションモードは内部的に “RDP” を利用して機能が実現されています。
早い話がリモートデスクトップのあれです。
(Src : https://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/MDC-B330#fbid=M3oY0SjYJi2 )
今回のスクリプトを確認頂くとわかるのですが、
XRDP を用いて、VMCI (hv_sock) 経由で RDP 接続を受け付けることで
今回の「拡張セッションモード」を実現する、という構図です。
Ref : https://gist.github.com/mimura1133/25451be04929d65993e0fb658d0b6890
あります。
Microsoft のリポジトリで Arch Linux 用と Ubuntu 用が提供されています。
https://github.com/Microsoft/linux-vm-tools
Redhat 系列の場合は、xrdp パッケージが vsock オプションが使えるようにビルドされていませんので、
SRPM を取ってきてコンパイルオプションを設定してコンパイルしなおせば動きます。
というわけで、私自身の作業環境がこれでぐぐっと作業しやすくなりました。
であであー。