Container Registry に自分の作ったDockerイメージをpushする
cloud.google.com プライベートなDockerコンテナレジストリが欲しかったので使ってみた。
gcloud
コマンドのセットアップを終えるgcloud auth configure-docker
でDocker Registryの認証をする- 下記コマンドでビルド済みのイメージ名にタグ付けをする
$ docker tag [任意のイメージ名] gcr.io/[プロジェクトID]/[イメージ名]:[バージョン]
- 下記コマンドでContainer RegistryにDocker イメージを push
$ docker push gcr.io/[プロジェクト名]/[イメージ名]:[バージョン]
これで作ったDockerイメージのContainer Registryへpush完了
Ingressのヘルスチェックに対応する
tl;dr
- "/"パスへのHTTPリクエストに対し200ステータスを返すように実装すればよい
Ingress のヘルスチェック
GKEでIngressを使っていた所ヘルスチェックをうまく通過しない。 色々と調べたところIngressのヘルスチェックはreadinessProbe.httpGetを指定しないと、デフォルトでは"/"パスにHTTP GETリクエストを送信し200ステータスが帰ってこない場合は対象ポッドが動作していないとみなすみたい。 https://github.com/kubernetes/ingress-gce/issues/42
readinessProbe.httpGetを指定しても別に良かったが、"/"パスは使っていないし、どうせヘルスチェック用にyamlを書き足しAPIのエンドポイントを作るのだったら、"/"へのリクエストに200返すようなコードを書いておけばいいだろうと思い、下記のGolangコードをエンドポイントに追加して対応した。
package main import ( "net/http" "github.com/labstack/echo" "github.com/labstack/echo/middleware" ) func main() { e := echo.New() e.Use(middleware.Logger()) e.Use(middleware.Recover()) e.GET("/", func(c echo.Context) error { return c.String(http.StatusOK, "OK") }) e.Logger.Fatal(e.Start(":8080")) }
参考
Ingressというよりk8sの話だが、ヘルスチェックについては下記ドキュメントが参考になった - https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/ - https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
Practical Binary Analysisの演習用環境をDockerで作った
三行で
- Practical Binary Analysis はリバースエンジニアリング入門にはうってつけの本
- 基本的な演習環境はVMで配布されている
- Dockerで環境を作るときはバージョンを指定しよう
概要
Practical Binary Analysisはモダンなバイナリ解析について学ぶことができる本。 目次は下記の通り。
Chapter 1: Anatomy of a Binary Chapter 2: The ELF Format Chapter 3: The PE Format: A Brief Introduction Chapter 4: Building a Binary Loader Using libbfd Part II: Binary Analysis Fundamentals Chapter 5: Basic Binary Analysis In Linux Chapter 6: Disassembly and Binary Analysis Fundamentals Chapter 7: Simple Code Injection Techniques for ELF Part III: Advanced Binary Analysis Chapter 8: Customizing Disassembly Chapter 9: Binary Instrumentation Chapter 10: Principles of Dynamic Taint Analysis Chapter 11: Practical Dynamic Taint Analysis with libdft Chapter 12: Principles of Symbolic Execution Chapter 13: Practical Symbolic Execution with Triton Part IV: Appendices Appendix A: A Crash Course on x86 Assembly Appendix B: Implementing PT_NOTE Overwriting Using libelf Appendix C: List of Binary Analysis Tools Appendix D: Further Reading
基礎的なディスアセンブラを実装したり、テイント解析やシンボリック実行をやったりと、今からリバースエンジニアリングをするなら抑えておきたい点を実装して手を動かしながら体系的に学ぶことができる。
実行環境について
そんなPractical Binary Analysisは演習用の実行環境としてVMを配布している。
別にVMでもいいのだが、単純にコードを参照したいくらいの時だと少し実行速度が遅い...
なので特段VMでないといけないような処理以外はDocker
で実行しようと思い至った。
少しググった所、Practical Binary Analysisの演習用環境をDocker
で作っている人がいたので、その環境を利用。
https://github.com/wilvk/practical-binary
しかしこのコンテナ、RUN apt-get -y install gcc-4.9 g++-4.9
を実行する際に下記エラーを出力しビルドが失敗してしまう。
Package g++-4.9 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source
RUN add-apt-repository -y ppa:ubuntu-toolchain-r/test
を実行しているのになぜ...?
ググるとこれはUbuntu 18.04に起因しているっぽい
https://askubuntu.com/questions/1036108/install-gcc-4-9-at-ubuntu-18-04
DockerFile
を改めて見ると最初の行でUbuntuのバージョンを指定していない。
FROM ubuntu RUN apt-get update RUN apt-get -y install software-properties-common RUN add-apt-repository -y ppa:ubuntu-toolchain-r/test RUN apt-get update RUN apt-get -y install gcc-4.9 g++-4.9 RUN update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.9 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.9 RUN apt-get -y install build-essential RUN apt-get -y install libc6-dbg gdb valgrind RUN apt-get -y install binutils-dev RUN apt-get -y install strace RUN apt-get -y install ltrace RUN apt-get -y install vim-common CMD ["/bin/bash"]
そのためUbuntu 18.04をダウンロードしてきてしまいビルドが失敗してしまう。 なのでUbuntuのバージョンを16.04に指定すると、失敗せずビルドすることができる。
FROM ubuntu:16.04 RUN apt-get update RUN apt-get -y install software-properties-common RUN add-apt-repository -y ppa:ubuntu-toolchain-r/test RUN apt-get update RUN apt-get -y install gcc-4.9 g++-4.9 RUN update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.9 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.9 RUN apt-get -y install build-essential RUN apt-get -y install libc6-dbg gdb valgrind RUN apt-get -y install binutils-dev RUN apt-get -y install strace RUN apt-get -y install ltrace RUN apt-get -y install vim-common CMD ["/bin/bash"]
https://github.com/famasoon/practical-binary/ にコミットしておいた。 これで、とりあえずコードを見ながら軽く動作させる環境のできあがり。
おわりに
https://practicalbinaryanalysis.com/ のRunning Code Samples on Windows and Other Platforms
の所でカーネル4.4以降だとうまく動作しないとか、そんな時のためのUbuntu 16.04 用カーネルダウングレードの仕方とかが載っているが、その時は適宜VMで演習をするなり環境を構築すればよいと思っているので問題なし。
という訳で環境を整えたのでリバースエンジニアリングをこれからやっていく(続く...?)
minikubeのダウンロードが途中で止まる
問題
タイトル通りminikubeを利用しようとしたところisoファイルのダウンロードで止まってしまう。
環境
macOS上で実行しているminikube v1.0.0
~ ❯❯❯ uname -a Darwin DoenoMBP 18.2.0 Darwin Kernel Version 18.2.0: Fri Oct 5 19:41:49 PDT 2018; root:xnu-4903.221.2~2/RELEASE_X86_64 x86_64 ~ ❯❯❯ minikube version minikube version: v1.0.0 ~ ❯❯❯ minikube start --kubernetes-version=v1.11.3 There is a newer version of minikube available (v1.0.1). Download it here: https://github.com/kubernetes/minikube/releases/tag/v1.0.1 To disable this notification, run the following: minikube config set WantUpdateNotification false 😄 minikube v1.0.0 on darwin (amd64) 💥 Kubernetes downgrade is not supported, will continue to use v1.14.0 🤹 Downloading Kubernetes v1.14.0 images in the background ... 🔥 Creating virtualbox VM (CPUs=2, Memory=2048MB, Disk=20000MB) ... 💿 Downloading Minikube ISO ... 1.97 MB / 142.88 MB [>-----------------------------------------] 1.38% 28m14s
毎回2%くらいダウンロードしたあたりでハングしてしまう。
対策
GitHubのissueをみる限り既知の問題のようでワークアラウンドが出ている。
Hung downloading ISO (network contention with image pull) #4035
minikube start
時に--cache-images=false
オプションをつけて問題を回避する。
minikube start --cache-images=false
自分の環境だとこれで正常にisoがダウンロードできるようになった。 上記GitHubのissueを見る限り、このバグに対応するコードをv1.0.1に盛り込む予定っぽいので今後のバージョンアップに期待。