1. 컴퓨터에 연결합니다 (baud rate: 115200)
2. 중요: H는 도움말 출력 기능입니다, 어디서나 사용하세요
3. 보드 GND를 Jtagulator GND에 연결하고, 보드 핀 1,2,3을 Jtagulator 채널 1,2,3에 연결합니다
4. V: 작동 전압 설정
5. U: UART 식별 메뉴 진입
6. U: 식별 시작
7. Text string to output: 기본값
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: screen 닫기

1. GND 기준점 찾기
   • 이전에 찾은 부품 사용
   • 보통 금속 판은 GND에 연결됨
2. VCC 기준점 찾기
   • 이전에 찾은 부품 사용
   • 커패시터를 검색하세요, 보통 VCC에 한 점이 있습니다
3. 아래 표를 채우면서 JTAG 후보 핀을 테스트합니다 (글머리 기호는 각각 표의 열입니다)
   1. JTAG 핀의 GND에 대한 저항 테스트 (멀티미터를 저항 측정으로, 보통 200k)
   2. JTAG 핀의 VCC에 대한 저항 테스트 (멀티미터를 저항 측정으로, 보통 200kOhm)
   3. 기기에 전원을 켜고 GND에 대한 JTAG 핀 전압 테스트 (멀티미터를 전압 측정으로, 보통 20V)

   • 표
4. 찾은 값을 일반적으로 사용되는 JTAG 핀아웃과 비교하십시오. jtagtest에서 확인 가능

1. 컴퓨터에 연결하십시오 (baud rate: 115200)
2. 중요: H는 도움말 출력 기능입니다. 어디서든 사용하십시오
3. 보드 GND를 Jtagulator GND에, 보드 핀 1,2,3...을 Jtagulator 채널 1,2,3...에 연결하십시오
4. V: 동작 전압 설정
5. J: JTAG 식별 메뉴 진입
6. 두 가지 옵션이 있습니다
   • I: IDCODE 스캔으로 식별, TDI를 찾지 못함 (빠름), 식별할 핀이 많을 때 더 좋음
   • B: BYPASS 스캔으로 식별, TDI를 찾음 (느림), 식별할 핀이 적을 때 더 좋음
7. Starting channel: 보드의 핀 1을 연결한 채널
8. Ending channel: 보드의 핀 n을 연결한 채널
9. Already known pins: 아니요. 하지만 일부 핀을 이미 알고 있다면 프로세스 속도를 높일 수 있음
10. 시작하고 기다리십시오... 완료!

• JTAG이 비활성화되었을 수 있습니다(하드웨어, 저항 제거). 따라서 멀티미터와 Jtagulator로 찾은 결과가 일치하지 않을 수 있습니다. 이 핀과 VCC 사이에 약 300Ohm 또는 1kOhm 저항을 연결하면 해결할 수 있습니다
• 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

빌드 시스템을 사용하여 빌드(기능 선택 및 종속성 자동 추적)

• 최고의 빌드 시스템 선택
  • Yocto 프로젝트
  • Buildroot (최고)
  • OpenWRT 빌드 시스템

에뮬레이션 시작

• QEMU 에뮬레이션 스크립트
  root@kitploit:~

  #!/bin/bash
  # 이 스크립트는 root 사용자에 대한 암호 없이 환경을 구축합니다
  export QEMU_AUDIO_DRV="none" # 오디오 드라이버 무시
  
  qemu-system-${PROCESSOR}${ARCHITECTURE} -M $CPUFAMILY \ # 포인트 2 참조
                                          -m $RAMSIZE \
                                          -kernel $KERNELPATH \
                                          -nographic \ # GUI 없음
                                          -hda $FILESYSTEM \
                                          -net nic,model=$NETCARDMODEL \ # 네트워크 카드 모델, 드라이버는 커널에 포함되어야 함
                                          -net user, hostfw=tcp::2222-:22, hostfw=tcp::9000-:9000 \ # 2222는 ssh, 9000은 GDB 서버용
                                          -no-reboot \ # 시스템이 중지되면 종료
                                          -append "root=/dev/hda console=uart0" # 루트 파일시스템과 콘솔 설정
  

  • 바이너리 실행 시 누락된 라이브러리 오류가 출력되면 (머신 내부에서) 다음과 같이 LD_LIBRARY_PATH를 설정하십시오: export LD_LIBRARY_PATH=/lib:/usr/lib:$PATHTOORIGINALFILESYSTEMLIBFOLDER
• NAND EEPROM도 에뮬레이션할 수 있습니다
  root@kitploit:~

  #!/bin/bash
  
  # 1부: 커널 모듈용 바이트 식별
  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,... # 소거 블록 수로 파티션 크기 정의; 파티션 수는 장치에 따라 다르며, 파티션은 일반적으로 부팅 시 출력됨
  
  # 2부: 생성된 파티션 소거 (EEPROM 파티션 분석)
  flash_erase /dev/mtd0 0 8 
  flash_erase /dev/mtd1 0 20
  # ...
  
  # 3부: 장치에서 덤프한 파티션을 방금 생성한 파티션에 로드
  nandwrite /dev/mtd0 part0.bin
  nandwrite /dev/mtd1 part1.bin
  # ...
  
  # 4부: 파일시스템 마운트 지점 생성 및 연결 (UBIFS인 경우)
  mkdir /mnt/filesystem
  ubiattach -O $N -m $MTDDVENUM -d $UBIDEVNUM
  ```# Part 5: Mount
  mount -tubifs /dev/ubi${UBIDEVNUM}_0 /mnt/filesystem
  

  1. 커널 모듈용 바이트 식별
     • 부팅 중에 보통 NAND 정보가 출력되며, 위 단계에서 그 정보를 확인하고 NAND ID를 검색하세요. 출력되는 바이트는 첫 번째, 두 번째, 네 번째 바이트 순서입니다.
     • 해당 정보는 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 선택
       • debug level을 최고로 하여 Build packages with debugging symbols 선택
       • 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
   • 저장(SAVE)하는 것을 잊지 마세요
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 실행. 문제가 있으면 다시 반복하십시오.
    • 발생 가능한 컴파일 오류
      • Need to use -fPIC
        • 커널 모듈(포인트 7)의 Toolchain -> Additional gcc options 아래에서 --enable-shared를 추가하거나 buildroot를 패치하십시오.

• git으로 buildroot 구성 파일 저장하기
  • 외부 트리 구성 (buildroot가 이해할 수 있는 파일 트리 보기) (br2)
    root@kitploit:~

    +-- board/
    |   +-- <company>/ (not always used)
    |       +-- <boardname>/
    |           +-- linux.config
    |           +-- busybox.config
    |           +-- kernel-defconfig (kernel config file)
    |           +-- <other configuration files>
    |           +-- post_build.sh (executed just before building the image, useful to copy root filesystem into the image)
    |           +-- post_image.sh
    |           +-- rootfs_overlay/ (everythin here will be copied in the final image)
    |           |   +-- etc/
    |           |   +-- <some file>
    |           +-- patches/
    |               +-- foo/
    |               |   +-- <some patch>
    |               +-- libbar/
    |                   +-- <some other patches>
    |
    +-- configs/
    |   +-- <boardname>_defconfig (buildroot config for our board)
    |   +-- uClibc.config (optional)
    +-- patches/
    |   +-- (here patches to be applied)
    |
    +-- Config.in (if using a br2-external tree)
    +-- external.mk (if using a br2-external tree)
    +-- external.desc (if using a br2-external tree)
    

  • 외부 트리를 사용하려면 buildroot를 다음과 같이 호출합니다: make BR2_EXTERNAL=$PATHTOEXTTREE $COMMAND
  • buildroot 구성을 외부 트리에 저장하려면: make BR2_EXTERNAL=$PATHTOEXTTREE savedefconfig
  • 커널 구성을 외부 트리에 저장하려면: make BR2_EXTERNAL=$PATHTOEXTTREE linux-update-defconfig

• expat
• json-c