빈워크가 해석할 수 없는 상황 등을 자신의 힘으로 퍼블릭 이미지를 분석하는 방법의 노트.Mac OS X El Capitan을 통해 수행됩니다.

stings 명령

바이너리에 포함된 문자열을 확인합니다.문자열의 오프셋을 확인할 수도 있습니다. -8 등을 지정하고 긴 문자열을 확인하면 됩니다.문자열이 나타나지 않으면 인코딩이 압축될 수 있습니다.

$ strings -t x original.bin | grep config.har
330000 config.har

옵션은 man 페이지를 확인하십시오.

hexdump 명령

바이너리를 확인합니다.

$ hexdump original.bin
0000000 10 00 01 03 24 1a 00 00 10 00 02 9c 24 1a 00 01
0000010 10 00 02 d1 24 1a 00 02 10 00 02 cf 24 1a 00 03
0000020 10 00 02 cd 24 1a 00 04 10 00 02 cb 24 1a 00 05
0000030 10 00 02 c9 24 1a 00 06 10 00 02 c7 24 1a 00 07

grep에서 gzip의 제목인'1f8b08'등을 찾습니다.또한 블록의 끝은 0xff 등으로 채워져 블록의 크기를 추측할 수 있다.
이렇게 하면 데이터의 집합을 확인할 수 있다.

$ hexdump original.bin | grep -1 '^*'

FreeBSD에서hexdump에-C 옵션을 추가하면 바이트로 표시됩니다.hd 명령과 같습니다.왜 이 디스플레이는 한 자릿수의 편이량을 표시합니까?

% hd Softbank_E-WMTA22.zimage | head
00000000  27 05 19 56 19 7e 4d bc  5d bf 60 d6 00 15 84 de  |'..V.~M.].`.....|
00000010  80 05 01 80 80 05 01 80  20 91 70 29 05 02 02 01  |........ .p)....|
00000020  46 72 65 65 42 53 44 20  4b 65 72 6e 65 6c 20 49  |FreeBSD Kernel I|
00000030  6d 61 67 65 00 00 00 00  00 00 00 00 00 00 00 00  |mage............|
00000040  1f 8b 08 08 d6 60 bf 5d  02 03 53 6f 66 74 62 61  |.....`.]..Softba|
00000050  6e 6b 5f 45 2d 57 4d 54  41 32 32 5f 6b 65 72 6e  |nk_E-WMTA22_kern|
00000060  65 6c 2e 6b 62 69 6e 00  dc bd 0b 98 5c 55 99 2e  |el.kbin.....\U..|
00000070  bc 76 5d 77 77 2a c9 ee  a4 03 6d d3 c2 4e 68 34  |.v]ww*....m..Nh4|
00000080  66 5a 53 b9 a0 31 87 81  0a 20 32 80 52 b9 71 9b  |fZS..1... 2.R.q.|
00000090  88 85 97 19 e7 8c 33 16  0c 9e 71 1c 1d ab fa 9e  |......3...q.....|

dd 명령

일부 이진법을 추출할 수 있다.

$ dd if=original.bin of=tp.gz bs=1 skip=262660 count=48702
48702+0 records in
48702+0 records out
48702 bytes transferred in 0.225961 secs (215533 bytes/sec)
$ file tp.gz
tp.gz: gzip compressed data, was "welkin-tp.b", from Unix, last modified: Fri Apr  9 01:01:29 2010, max compression

흩어진 물건을 연결할 때cat 명령을 사용합니다.

xxd 명령

boot의 원추형 깔창 등으로 저장된 이진 요소를 복원한다.

$ head -1 hexdump.asc 
bfc40000:46 69 72 6d 77 61 72 65-00 ff ff ff ff ff ff ff Firmware........
$ sed 's/^.\{9\}//;s/.\{17\}$//' hexdump.asc | xxd -r -p > hexdump.bin

이 명령어와 boot 컨트롤러를 사용하여 어떤 공유기의 플래시 이미지를 분석한 결과 이렇다.

이 정도로 분석하려면 빈워크만으로는 안 되고 장인의 느낌과 기교로만 할 수 있다.
boot은 64K 두 부분으로 나뉘는데 hexdump 각도에서 보면 두 부분으로 나뉜다.최초의 부분은 일반적인 지도였고 뒷부분은 압축된 집행 형식으로 여겨졌지만 gzip은 아닌 것 같다.첫 번째 부분을 실행하고 뒷부분을 RAM에 펼쳐서 실행한다.
펼친 주소 커널의 마운트 주소가 0x8004000이기 때문에 이전 주소인 것 같습니다.
각 64K 섹터의 헤드 구조(예: boot 관리 펌웨어)tftp push를 사용하면 되기 때문에 직접 조작하지 않을 수도 있습니다.
타입
바이트 수
시험을 준비하다
파일 이름
16
NULL 레이어 문자열
청크 번호
4
파일 크기
4
?
4
?
36
Version 블록은 문자열일 뿐입니다.welkin-tp.b 테스트 프로그램이 시작되었을 때나 boot 컨트롤러에서 tp 명령을 실행할 때 읽히고 처리됩니다.실제 펌웨어의 넷bsd 부분이라고 상상할 수 있습니다.
welkin-tp.b는 gzip 형식이고netbsd는 미지의 형식입니다.
펌웨어에 있는 블록의 머리 구조를 조사해 보신 분들이 있는 것 같아요.
타입
바이트 수
시험을 준비하다
표식
4
아마 31위가 gzip 로고 17위일 거예요. 실행 로고 16위가 END 로고예요.
데이터 길이
4
데이터 시작 위치
4
0x18 고정
체크섬
2
데이터 길이 이후의 16비트 단위의 IP 헤더와 같은 체크섬.근데 내부 부분만 상위 아르바이트가 좀 안 어울려요.몇 개의 펌웨어를 조사한 결과 데이터 크기와 차이가 비례하는 것을 발견하였다.내부 핵 이외에 사이즈가 작기 때문에 완전히 일치하는 것도 이해할 수 있다.데이터 길이를 25000 정도로 나누어 보았더니 순조롭게 되었다.
가상의
2
로드 주소
4
실행 가능한 마운트 주소
신청 요점
4
실행 가능한 신청 지점
체크섬 범위는 짧은 블록에서 확인하고 추정하는 것이 좋습니다.
이 목표의 검증과 검증은 수수께끼이기 때문에 위의 논리로 적당히 다루면 편차가 있을 수 있다.
체크섬 NG

boot> load Firmware
Firmware system: load fail

체크섬 OK 시

boot> load Firmware
begin  : 0x80040100
length : 1807018
startup: 0x80040100

이 목표는rootfs 부분이 없지만 ufs로kernel에 들어가는 것 같습니다.현재의 CPU와 메모리의 규격을 고려하면 좋은 방법은 아닌 것 같다.
루비 등에서는 검사 구조의 스크립트를 쓰는 것도 유효하다.(예: EZ-USB FX2용 펌웨어 추출 스크립트
objudmp에서 어셈블리 문집을 해석할 수도 있지만 힘들기 때문에 정말 마지막이다.역어셈블리의 해석이 현실적이지 않기 때문에 AI를 사용하는 역컴파일러가 가장 좋다.

$ objdump -b binary -m mips -D hoge.bin

endian이 무엇인지 모르면 EL 및 EB 옵션을 추가하여 유사한 명령이 있는지 확인합니다.
QUEM에서 바이너리를 실행하는 방법도 있을 수 있습니다.
바이너리를 편집하고 싶을 때 맥에는 Hex Fiend라는 앱이 있고 앱스토어에는 고정되어 있다.