다시 시작하는 TIL 30일차

오늘 한일

3일째 삽질하다가 지금 어느정도 길을 잡았다.

 

firmware 파일을 가져와 추출하는 데이터는 7z이나 binwalk, unblob 으로도 많은 데이터 추출 툴들이 지원된다.

 

웬만한 임베디드 관련 운영체제는 Unix 기반이기에 linux 관련 함수가 많이 존재하여 사용하면 되겠지만

 

window에서는 다르다. 지원하는 파일시스템의 한계도 있고 그거를 분석하는 분석툴 자체도 매우 불친절하다.

 

unblob을 window에서 네이티브로 돌려볼라고 했는데 결국 Rust code에서 문제가 생긴다.

 

 

rustup add <'window-flayform'>

 

대충 위와 같이 적어도 적용이 안되는 것도 그렇고, 함수자체가 리눅스 친화적이라 내가 만지기엔 말이 안된다.ㅋㅋㅋㅋ

 

그래서 binwalk를 네이티브로 돌리려고하는데 이거 설정하는데도 좀 애먹었다.

 

pip로 pyinstaller 설치하고 오픈소스인 binwalk를 다운받아 setup.py 를 해준다.

 

또한 binwalk.py를 다운받아준다.

 

설치되고 나중에 pyinstaller -onemake binwalk.py 를 하면 실행파일이 만들어지는데

 

그거를 환경변수에 넣든 뭘하든 실행하면 된다.

 

너무 얼렁뚱땅 넘어가긴했는데 회사 컴퓨터에 다 기록해놔서 명확하게 기억이 안난다.

 

일단 구동은 시켰으니 내일 파일 시스템에 따라서 처리 핸들링을 구현 하면 될 것 같다.

 

 

퇴근 후 공부

read write는 버퍼하나를 가지고 데이터를 주고 받는 형식이다.

하지만 readv, writev는 여러 버퍼에 대해서 원하는 곳에 데이터를 보낼 수 있다.

즉 , read 함수는 함수는 영역을 나눠서 호출해야한다.


버퍼가 비어있을떄 write 호출해서 그 메모리 공간에 넣는다고 했을때 데이터가 하나의 패킷이 되서 전달이 된다. 

하지만 writev함수를 호출하면 데이터가 버퍼에 한번에 다들어간다.

즉 -> 패킷의 수가 줄어든다는 이점이 있다.

간단하게 생각해봐도 패킷을 더 적게보낸다면 헤더를 붙이는 횟수가 줄어들어 , 전체적인 성능이 좋아진다.

iovec 라는 구조체를 이용해 버퍼의 정보를 따로 저장한다.

ssize_t writev(int filedes, const struct iovec p_iov, int iovcnt);

성공시 전송된 바이트 수, 실패시 -1 반환

fileded : 데이터 전송의 목적지를 나타내는 소켓의 파일 디스크립터 전달, 단 소켓에만 제한된 함수가 아니기 때문에 , read함수 처럼 파일이나 콘솔 대상의 파일 디스크립터도 전달 가능하다.

iov : 구조체 iovec배열의 주소 값 전달, 구조체 iovec의 변수에는 전솔할 데이터의 위치 및 크기가 담긴다.

iovcnt : 두 번째 인자로 전달된 주소 값이 가리키는 배열의 길이 정보 전달.


이는 둘 이상의 영역에 나뉘어 저장된 데이터를 묶어서 한번의 함수호출을 통해서 보낼 수 있다.

iov_base -> 버퍼 주소값
iov_len = 크기 정보

ssize_t readv(int filedes, const struct iovec p_iov,  int iovcnt);

filedes : 데이터를 수신할 파일의 디스크립터를 인자로 전달.
iov: 데이터를 저장할 위치와 크기 정보를 담고 있는 iovec 구조체 배열의 주소값.
iovcnt: 두 번째 인자로 전달된 주소 값이 가리키는 배열의 길이 정보 전달

readv & writev 함수의 적절한 사용

여러 영역에 나뉘어 있는 데이터들을 하나의 배열에 순서대로 옮겨다 놓고 write 함수를 호출하는 것과 결과가 같다.

writev 함수호출이 유용한 이유는 아래와 같다.

- 단순한게 보면 , 함수의 호출 횟수를 줄일 수 있다.
- 잘게 나뉜 데이터들을 출력버퍼에 한번에 밀어 넣기 떄문에 하나의 패킷으로 구성되어서 전송될 확률이 높아지고, 이는 전송속도의 향상으로도 이어질 수 있다.