sshを経由して閉環境内のhttp proxyを利用する
ssh proxy
みたいなワードを頑張って組み合わせて検索しても、大体HTTP proxy経由でsshトンネルを掘るという記事が出てきてぱっと見当たらなかったのでメモしておく。
結論から言うと LocalForward
の機能を使えばできると。
LocalForwardの説明とかは この辺り のチートシートサイトを見てもらえればよいかと。
自分は開発でたまに使いそうだったので .ssh/config
に設定を追記してバックグラウンド実行する感じで使いました。
.ssh/config
Host INTERNAL_PROXY HostName aaa.bbb.ccc.ddd IdentityFile RSA_KEY_PATH User USER DynamicForward 8080
コマンド
ssh -f -N INTERNAL_PROXY
どこで必要だったのか
仕事でサービス連携とかしていて、稀にIP登録してそのIP以外は受け付けないというサービスがあったりあったりする。 その時に自社が管理する複数のインスタンスからアクセスしたいという場合、自社サービス環境内にproxyを立ててそこ経由でアクセさせるというのは、前述の様な条件のサービスの場合はままあるのではないかと。
で、困るのが開発するときに動作確認がやりにくいという点。 なんとかproxyを経由してアクセスしたいけど、前述の様なproxyをGlobalに公開するようなことはあまりない気がするのでなんとかしないといけない、というのを解決したかったのが動機。
DDDの本を読み始めた
以前人に勧められてWebで軽く調べるとかしていたけど、先日の電子書籍セールでDDDの本を買ったので読み始めた。
まだ3章までしか読んでないが、訳本なのでやはりなんとなくぎこちない感があるけどわかりやすくて良い本だと思う。 (色んな方々が推奨しているので今更ではあるが)
8単位符号
必要な箇所だけ見ていっていたらわかりにくかったのでわかりにくかった点をメモ。
図 拡張方法
にあるByteコードの記載方法について
ESC 04/2F
みたいな記載があるが、ルールとして以下の2点を考慮して見る必要がある
- 数字は10進で書かれている
/
は上位4Bitと下位4bitを示したもの- 下位は1桁でも0はつかないが上位はなぜか
0
がつく
- 下位は1桁でも0はつかないが上位はなぜか
という点を考慮すると以下のようになる
ESC 04/2F -> ESC 0x42 F ESC 02/10 02/0F -> ESC 0x2A 0x20 F
※先述の通り数字は10進表記であり、Fは数字でなく資料で後述されている終端符号のこと
終端符号とか単語としては冒頭でサラっと出てきて表中では説明なく F
とか記載されてて分かりづらかったですが、ここまで分かると 表 符号の指示制御
と 表 符号集合の分類と終端符号
の繋がりが分かりました。
バッファの初期値
単に探すのが大変だったというだけですが、 第一遍 第三部
の 初期状態
の表に記載がありました。
バッファ名 | 初期値 |
---|---|
G0 | 漢字系集合 |
G1 | 英数集合 |
G2 | 平仮名集合 |
G3 | マクロ符号集合 |
でGLとGRの割当は
割当先 | バッファ名 |
---|---|
GL | G0 |
GR | G2 |
となっているのでGLが漢字系集合、GRが平仮名集合になっているみたいですね。
TSファイルの8単位文字符号がつらい
最近自前の録画サーバーでTSをパースして情報抽出しようかと思ってパーサーをgolangで書いてたんですが、最後の日本語化のところで出てきた8単位文字符号がつらい・・・
http://www.arib.or.jp/english/html/overview/doc/2-STD-B24v5_1-1p3.pdf
ARIBでは文字列をよくある文字コードではなく8単位文字符号というので表しているみたいです。上記資料の2篇7章に記載があるんですが、正直ちょっと面倒な気分に・・・
golangでプロコン
最近家ではgolangばっかりなので試しにプロコンで使ってみた。 (2016/09/05現在AtCoderではGo1.6が使えるっぽい)
参加したのはAGC004 ちゃんと解答できたのはAだけでBは不完全ですが最後の段階でPostしたコードをおいておきました。 そもそもAのコードもブサイクなのはご愛嬌ということで・・・
AtCoderは解説をあげてくれるのでどこかでちゃんと実装したいですね。
よく考えると当たり前ですが、配列が0で初期化されてるとかlenがそのまま配列長が返ってくるというのに気がつくのに時間がかかったorz 普段は適当に書いているので割とsliceでよしなっていた弊害か・・・
foo := [2]int{} // foo -> [0, 0] // len(foo) -> 2 bar := []int{} // bar -> {} // len(bar) -> 0
tmctf2016
用事があって帰省していたので解析等の環境もなくほぼ参加できなかったんですが、一問だけぱっと見て出来そうだったので一応Writeup。
設問とコードは以下のgithubにおいてありますのでざっくり概要だけ。
analysis-offensive 200
自分が見た時には(最初から?)問題分に a simple remote overflow of a global array
とあるし、サーバ側のコードも記載してあるので一目瞭然ですね。
フラグの書き出し処理は pwned
の上位16bitと下位16bitをチェックしていて条件に合えばフラグが返ってくるというもの。
で、この pwned
についてはグローバル変数として int pwned
と char buffer[1024]
で連続したスタックに置かれています。
コード中を見るとソケットから buffer
に対して1028byteの読み込みが行われているのでこのオーバーフローした4byte文でpwnedを書き換えてチェックが通るようにパケットを送信すれば良いというものです。
pwnedは上下16bitづつ特定の値とXORをとった結果を確認しているので比較している値に同じくXORをとってやれば期待される値がわかりますね。
(0xc0fe ^ 0x7eaf) << 16 + (0x1a1a ^ 0xdae4) -> 0xBE51C0FE
ということでサーバーに対して先ほどの4byteのところに上記のデータを送るようなコードを書いてやればレスポンスとしてフラグが返ってきます。 バイトオーダーはまぁリトルエンディアンかなとおもってやったら通った。