patch

_posts/2024-03-11-Android-1day-Exploit-Analysis-ko.md

@@ -136,7 +136,7 @@ BUILD_CONFIG=../build-configs/goldfish.x86_64.kasan build/build.sh
 
 ## 3.2 Patch diff
 
-- 우리는 patch 내용을 보고 실제 코드에서 어떤 부분이 취약했는지 유추하고 이를 어떤 방법으로 막았는지 살펴본다.
+- patch 내용을 보고 실제 코드에서 어떤 부분이 취약했는지 유추하고 이를 어떤 방법으로 막았는지 살펴본다.
 
     ```diff
     /drivers/android/binder.c patch diff
@@ -241,7 +241,7 @@ epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event);
 - epfd : epoll_create의 return value
 - fd : binder file descripter
 
-binder 드라이버의 파일 디스크립터는 `open("/dev/binder0", O_RDONLY);` 코드를 통해 얻을 수 있고, epfd는 `epfd = epoll_create(1000);` 이 코드를 통해 얻게 된다. 따라서 우리는 먼저 `epoll_create`를 분석한다.
+binder 드라이버의 파일 디스크립터는 `open("/dev/binder0", O_RDONLY);` 코드를 통해 얻을 수 있고, epfd는 `epfd = epoll_create(1000);` 이 코드를 통해 얻게 된다. 따라서 `epoll_create`를 먼저  분석한다.
 
 <br>
   
@@ -503,7 +503,7 @@ struct binder_thread {
 
   
 <br>
-우리는 앞서 패치 노트를 통해 epoll과 waitqueue에 어떤 부분에 의하여 UAF가 발생했다는 것을 추측할 수 있다. 따라서 이와 관련이 있어 보이는 `poll_wait(filp, &thread->wait, wait);` 코드를 볼 필요가 있다.
+앞서 패치 노트를 통해 epoll과 waitqueue에 어떤 부분에 의하여 UAF가 발생했다는 것을 추측할 수 있다. 따라서 이와 관련이 있어 보이는 `poll_wait(filp, &thread->wait, wait);` 코드를 볼 필요가 있다.
 
 ```c
 //drivers/android/binder.c
@@ -1295,7 +1295,7 @@ circular double linked list의 경우 노드가 해제되어 하나의 노드만
 
 ### 5.3.1 Overwrite thread.addr_limit
 
-우리는 UAF를 통해 iovecStack[11].base와 iovecStack[10].len을 바꿀 수 있다. 간단하게 생각해서, readv를 통해 corrupt pointer로 입력을 넣을 수 있을 것으로 보이지만, 아래 이유로 인해 readv를 사용할 수 없다.
+UAF를 통해 iovecStack[11].base와 iovecStack[10].len을 바꿀 수 있다. 간단하게 생각해서, readv를 통해 corrupt pointer로 입력을 넣을 수 있을 것으로 보이지만, 아래 이유로 인해 readv를 사용할 수 없다.
 
 - readv를 사용할 경우, iovecStack[10].len의 크기가 매우 커졌기 때문에, readv에서 iovecStack[10]만 출력하고 그 다음에 우리가 실제로 값을 넣어야 할 iovecStack[11].base에는 접근하지 못한다. 따라서 이 exploit에서는 readv대신 recvmsg를 사용한다.