1. コンピュータに接続する（ボーレート: 115200）
2. 重要: Hはヘルプ表示機能。あらゆる場面で使用する
3. ボードGNDをJtagulatorGNDに、ボードのピン1,2,3をJtagulatorのチャンネル1,2,3に接続
4. V: 動作電圧を設定
5. U: UART識別メニューに入る
6. U: 識別を開始
7. Text string to output: default
8. Starting channel: ボードのピン1を接続したチャンネル
9. Ending channel: ボードのピン3を接続したチャンネル
10. Ignore non-printable characters: Yes
11. 完了！

• $BAUDRATEはこちらにあるもののいずれか
• 最も一般的な$BAUDRATE
  • 115200
  • 9600
  • 57600
  • 38400
  • 19200
• 重要: $BAUDRATEを間違えると、文字化けが見えるか、何も見えない可能性がある
• ctrl + a -> k -> y: close screen

1. GNDへの参照を見つける
   • 以前に見つけたコンポーネントを使用
   • 通常、金属プレートはGND
2. VCCへの参照を見つける
   • 以前に見つけたコンポーネントを使用
   • コンデンサを探す。通常、コンデンサの一方の端子はVCC
3. 以下の表を埋めながらJTAG候補ピンをテストする（箇条書きは表の各列に対応）
   1. JTAGピンのGNDに対する抵抗をテストする（マルチメータを抵抗測定に、通常200k）
   2. JTAGピンのVCCに対する抵抗をテストする（マルチメータを抵抗測定に、通常200kΩ）
   3. デバイスを起動し、JTAGピンのGNDに対する電圧をテストする（マルチメータを電圧測定に、通常20V）

   • 表
4. 見つかった値を、jtagtestで入手可能な一般的なJTAGピン配置と比較します。

1. コンピュータに接続します（ボーレート：115200）
2. 重要: H はヘルプ表示機能です。あらゆる場面で使用してください。
3. ボードの GND をJtagulatorの GND に、ボードのピン 1,2,3... をJtagulatorのチャンネル 1,2,3... に接続します。
4. V: 動作電圧を設定します。
5. J: JTAG識別メニューに入ります。
6. ここには2つのオプションがあります。
   • I: IDCODEスキャンで識別します。TDIは見つかりません（高速）。識別するピンが多い場合に適しています。
   • B: BYPASSスキャンで識別します。TDIを見つけます（低速）。識別するピンが少ない場合に適しています。
7. Starting channel: ボードのピン 1 を接続したチャンネル。
8. Ending channel: ボードのピン n を接続したチャンネル。
9. Already known pins: いいえ。ただし、すでにいくつかのピンがわかっている場合は処理を高速化できます。
10. 開始して待つ... 完了！

• JTAGは無効化されている可能性があります（ハードウェア、抵抗の除去）。そのため、マルチメータとJtagulatorで見つけた結果が一致しない可能性があります。この問題は、該当ピンとVCCの間に約300Ωまたは1kΩの抵抗を挿入することで解決できます。
• JTAGは無効化されている可能性があります（ハードウェア、抵抗の除去）。この問題は、抵抗を元に戻すか、抵抗パッドをショートして直接接続することで解決できます。
• JTAGは無効化されている可能性があります（ソフトウェア、何らかの値の設定）。
• JTAGは無効化されている可能性があります（ハードウェア、ヒューズの溶断... この場合は希望がありません）。

• $BINTOWRITE：bin（バイナリ）、ihex（Intel hex）、elf（ELFファイル）、s19（Motorola s19）、mem... などが可能です。
• $ADDRTOSTART：書き込みを開始するアドレス（デフォルトは 0 だと思います）。

• $OUTFILE：ダンプを保存するバイナリファイル
• $ADDRTOSTART：読み取りを開始するアドレス（デフォルトは 0 だと思います）。
• $SIZETODUMP：ダンプするバイト数

• OpenOCD PDF
• OpenOCD HTML

• ブートローダメニューを探してください。ここでこの質問に対する答えが見つかる可能性があります。

• help コマンドはあなたの味方です。
• メモリの内容をダンプする方法を見つけてください。Pythonはあなたの味方です。
• OOBデータ（誤り訂正符号）はダンプしてもあまり役に立ちません。

• binwalk、file、hexdump -C を使用して、ダンプされたファイルが正常かどうか、圧縮または暗号化されているかを確認します。
  • binwalk -E でファイルのエントロピーを分析します。
    • エントロピーが 1 に近い：ランダム、圧縮、または暗号化されたファイル
    • エントロピーが 1 未満：通常の実行可能ファイルまたはファイル
• binwalk -e を使用して、識別可能なファイルセグメントを抽出します。

• dd if=$IN_DUMPED_IMAGE of=$OUT_FILE bs=1024 skip=$BYTES_TO_SKIP_FROM_THE_START count=$HOW_MANY_BYTES_TO_WRITE
• sha1sum、md5sum、または binwalk -W -i を使用してイメージを比較します（例えば、同じイメージだと思われる場合）。

• コマンド例（ファイルシステムの種類に基づく）：fakeroot -s fakeroot.dat usquashfs -d squashfs-root u04-sqfs.dat
  • fakeroot：偽のルート環境を作成します。ファイルパーミッション、デバイスファイルなどのエミュレーションに役立ちます。
    • -s fakeroot.dat：偽のルート環境を保存し、後で fakeroot -i fakeroot.dat bash コマンドで復元できるようにします。
  • usquashfs：squashfs ファイルシステムを抽出します（あなたのケースでは異なる可能性があります）。
    • -d squashfs-root：出力先フォルダ
    • u04-sqfs.dat：抽出するファイルシステムイメージ

• initプロセスによって起動される興味深いファイルを探し、一般的に名前だけで止まらず、実行されているバイナリを詳細に調査して分析する。最も興味深いのは非標準のものです。
• factory mode 文字列を探す。デバイスをファクトリモード（存在する場合）にできれば、ハッキングがはるかに簡単になります。
• 便利なコマンド
  • テキストエディタ
  • grep
  • find
  • xargs
  • strings

• 許容範囲：同じ X、より高い Y

ビルドシステムを使用してビルドする（機能を選択し、依存関係を自動追跡）

• 最良のビルドシステムの選択肢
  • The Yocto project
  • Buildroot（最良）
  • OpenWRT build system

エミュレーションを開始する

• QEMUエミュレーションスクリプト
  root@kitploit:~

  #!/bin/bash
  # This script will build an environment without password for the user root
  export QEMU_AUDIO_DRV="none" # ignore audio drivers
  
  qemu-system-${PROCESSOR}${ARCHITECTURE} -M $CPUFAMILY \ # See point 2
                                          -m $RAMSIZE \
                                          -kernel $KERNELPATH \
                                          -nographic \ # No GUI
                                          -hda $FILESYSTEM \
                                          -net nic,model=$NETCARDMODEL \ # Model of net card, driver must be included in kernel
                                          -net user, hostfw=tcp::2222-:22, hostfw=tcp::9000-:9000 \ # 2222 as ssh and 9000 for GDB server
                                          -no-reboot \ # Terminate the machine when is halted
                                          -append "root=/dev/hda console=uart0" # Set root filesystem and console
  

  • バイナリ実行時にライブラリ不足のエラーが表示される場合、内部で LD_LIBRARY_PATH を次のように設定します：export LD_LIBRARY_PATH=/lib:/usr/lib:$PATHTOORIGINALFILESYSTEMLIBFOLDER
• NAND EEPROMのエミュレーションも可能です。
  root@kitploit:~

  #!/bin/bash
  
  # Part 1: Identify bytes for kernel module
  modprobe nandsim first_id_byte=$FIRSTBYTE \
                      second_id_byte=$SECONDBYTE \
                      third_id_byte=$THIRDBYTE \
                      fourth_id_byte=$FOURTHBYTE \
                      cache_file=/root/nandsim.bin \
                      parts=x,y,z,... # Define partitons size in number of erase blocks; the number of partitions depends on your device, partitions are usually print on boot
  
  # Part 2: Erase partitions created (analyze EEPROM partitions)
  flash_erase /dev/mtd0 0 8 
  flash_erase /dev/mtd1 0 20
  # ...
  
  # Part 3: Load partitions dumped from device in the ones just created
  nandwrite /dev/mtd0 part0.bin
  nandwrite /dev/mtd1 part1.bin
  # ...
  
  # Part 4: Create mountpoint for filesystem and attach (if UBIFS)
  mkdir /mnt/filesystem
  ubiattach -O $N -m $MTDDVENUM -d $UBIDEVNUM
  ```# 第5部: マウント
  mount -tubifs /dev/ubi${UBIDEVNUM}_0 /mnt/filesystem
  

  1. カーネルモジュールのバイトを特定する
     • 起動時にNANDに関する情報が印刷されることが多いので、それを確認し（上記の手順）、NAND IDを探します。バイトは最初、2番目、4番目の順で出力されます。
     • EEPROMのデータシートを調べてもこれらの情報が見つかることがあります。
     • writesize、oobsize、erasesize、iowidthを使用して、こちらで正しいコマンドを見つけることもできます。
     • それ以外の場合は、試行錯誤します。
  2. ブート時に出力されるEEPROMパーティションを分析し、そのサイズと名前を調べます。flash_eraseコマンドの最後の数値は、erasesize（parts=x,y,z,...と同じ）に関連したサイズです。
  3. デバイスからダンプしたパーティションを、先ほど作成したパーティションにロードします。
  4. ファイルシステム用のマウントポイントを作成し、アタッチします。
     • -O: ボリュームIDヘッダのオフセットを指定します。値が間違っていると、システムは正しい値を教えてくれます。それでも、512、1024、2048などの異なる値を試すことができます（試行錯誤）。
     • -m: mtdデバイス番号（ポイント3を参照）
     • -d: UBIデバイス番号（ポイント5を参照）
  5. マウント

• 注釈
  • あまり安定していない
  • 奇妙な結果を返すことがある
• 手順
  1. QEMU実行形式を見つける: qemu-$PROCESSOR$ARCHITECTURE
     • 例: qemu-mips64
  2. QEMUがインタプリタがないと文句を言う場合は、-L（またはmanを参照）でそのインタプリタが含まれているフォルダのパスを渡す
     • 実行ファイルがどのインタプリタを使用しているかを調べるには、readelf -l $EXECUTABLEを使用する

• 構築するカーネルは（元のカーネルに対して）以下の条件を満たす必要がある
  • 同じカーネルバージョン
  • 同じlibcバージョン（uClibc、uClibc-ng、musl、dietlibc...）
  • 同じライブラリバージョン（対象の実行ファイルに関連するもの）

1. デバイスのバージョンに最も近いbuildrootバージョンを検索する
   • 起動時やダンプしたメモリの調査中に、使用されたbuildrootのバージョンが見つかることがある（デバイスがbuildrootで構築されている場合）
2. 見つけたbuildrootバージョンと互換性のあるLinuxバージョンを見つけ、dockerコンテナを作成する。ここにDockerfileのサンプルがある（パッケージはbuildrootを実行するために重要）
3. 選択したbuildrootバージョンをこちらからダウンロードし、dockerコンテナの共有フォルダ内に配置する
4. dockerコンテナを実行し、切り替える
5. buildrootを展開し、make manualを実行してbuildrootのマニュアルを作成する
6. make helpを使用すると、buildrootがサポートするすべてのデバイス（ボード）が表示される。make $YOURBOARDNAMEでボードのbuildroot設定ファイルを作成する
7. make menuconfig（テキストベース）またはmake xconfig（GUI）を使用して、ビルドに追加するカーネルモジュールを選択する。ここではmake xconfigを使用する
   • 以下は例/ガイドラインであるが、アプリケーションを実行するために必要なモジュールは自分で見つける必要がある
   • チート: Edit->Findでモジュールを検索する
   • オプション
     • Target options
       • Show options and packages that are deprecated or obsolete にチェック
       • Build packages with debugging symbols にチェックし、最高の debug level を選択
       • Strip command for binaries on target を None にチェック
       • GCC optimization level を 0 にチェック
     • Toolchain
       • Toolchain type を Buildroot toolchain にチェック
       • Kernel headers を Manually specified linux version にチェック
       • Custom kernel headers series を $DEVICEKERNELVERSION に設定
       • Linux version を $DEVICEKERNELVERSION に設定
       • C library を $DEVICECLIBRARY にチェック
       • $DEVICECLIBRARY version を $DEVICECLIBRARY $DEVICELIBRARYVERSION にチェック
       • Enable large files にチェック
     • System configuration
       • Passwords encoding を MD5 にチェック
       • Init system を $DEVICEINITSYSTEM（または BusyBox）にチェック
       • /dev management を Dynamic using devtmpfs only にチェック
       • /bin/sh を Busybox default shell にチェック
       • Install timezone info にチェック
     • Kernel
       • Kernel version を $DEVICEKERNELVERSION に設定
       • Kernel binary format を vmlinux にチェック
     • Target packages
       • Compressors and decompressors
         • bzip2 と xz-utils
       • Debugging profiling and benchmark
         • gdb と full debugger にチェック
       • Development tools
         • 必要なものを選択
       • Filesystem and flash utilities
         • mtd, jffs2 and ubi/ubifs tools（または必要なもの）
       • Libraries
         • 一般的に必要なもの（以下の提案）
         • Crypto
           • libsha1
     • Networking applications
       • rsync と必要なもの
     • Shell and utilities
       • file
     • Filesystem images
       • ext2
     • Host utilities（ターゲットデバイスではなく、ホストデバイスについて）
       • host mtd, jffs2 and ubi/ubifs tools
       • host util-linux
   • 保存するのを忘れずに
8. 上記で定義した設定を恒久的に保存するには、make savedconfig を使用する
9. make linux-menuconfig（テキストベース）または make linux-xconfig（GUI）でカーネルを設定する。ここではCLIバージョンを使用する
   • 以下は例/ガイドラインであるが、アプリケーションを実行するために必要なモジュールは自分で見つける必要がある
   • オプション
     • Kernel type -> Preemption model (Preemptible Kernel (Low-Latency Desktop)) -> Preemptible Kernel (Low-Latency Desktop)
     • Kernel type -> Device drivers -> Memory technology device (MTD) support -> NAND device support -> Support for NAND flash simulator
     • Kernel type -> Device drivers -> Memory technology device (MTD) support -> ->
10. uclibc-menuconfig（常に同様）で uClibc（またはCライブラリ）を設定する
    • デバッグを有効にする: Development/Debugging options -> Enable debugging symbols。これが機能しない場合（コンパイルエラー）は、Development/Debugging options -> (Wall) compiler warnings -> -Wall -ggdb -g3 を追加する
      • -ggdb: GDBで使用するデバッグ情報を提供する
      • -g3: 追加のデバッグ情報を提供する
    • Save
    • デバイスと同様の機能を有効にする（試行錯誤。エラーが発生した場合は調査し、必要な機能を追加して再ビルドする）
11. make。問題があれば戻って繰り返す
    • 考えられるコンパイルエラー
      • -fPIC を使用する必要がある
        • カーネルモジュール（ポイント7）の Toolchain -> Additional gcc options に --enable-shared を追加するか、buildrootにパッチを適用する

• buildrootの設定ファイルをgitで保存する
  • 外部ツリー構成（buildrootが理解できるツリービュー形式のファイル）（br2）
    root@kitploit:~

    +-- board/
    |   +-- <company>/ (常に使われるわけではない)
    |       +-- <boardname>/
    |           +-- linux.config
    |           +-- busybox.config
    |           +-- kernel-defconfig (カーネル設定ファイル)
    |           +-- <その他の設定ファイル>
    |           +-- post_build.sh (イメージ構築直前に実行され、ルートファイルシステムをイメージにコピーするのに便利)
    |           +-- post_image.sh
    |           +-- rootfs_overlay/ (ここにあるものはすべて最終イメージにコピーされる)
    |           |   +-- etc/
    |           |   +-- <何らかのファイル>
    |           +-- patches/
    |               +-- foo/
    |               |   +-- <何らかのパッチ>
    |               +-- libbar/
    |                   +-- <その他のパッチ>
    |
    +-- configs/
    |   +-- <boardname>_defconfig (ボードのbuildroot設定)
    |   +-- uClibc.config (オプション)
    +-- patches/
    |   +-- (ここに適用するパッチ)
    |
    +-- Config.in (br2-externalツリーを使用する場合)
    +-- external.mk (br2-externalツリーを使用する場合)
    +-- external.desc (br2-externalツリーを使用する場合)
    

  • 外部ツリーを使用するには、buildrootを次のように呼び出す: make BR2_EXTERNAL=$PATHTOEXTTREE $COMMAND
  • buildrootの設定を外部ツリーに保存する: make BR2_EXTERNAL=$PATHTOEXTTREE savedefconfig
  • カーネル設定を外部ツリーに保存する: make BR2_EXTERNAL=$PATHTOEXTTREE linux-update-defconfig
  • uClibc設定を外部ツリーに保存する: make BR2_EXTERNAL=$PATHTOEXTTREE BR2_UCLIBC_CONFIG=$PATHWHERETOSAVEUCLIBCCONFIG uclibc-update-defconfig

• expat
• json-c