이제는 커스텀 롬도 옛말인 것 같다

10년 전이나 20년 전만 해도 커스텀 롬이라는 것은 일종의 반 필수였다. 제조사 기본값은 너무나도 구렸기 때문이다.

여전히 우리를 괴롭히고 있는 '기본 앱'이라는 것도 옛날에는 너무 많아서 아예 커스텀 롬에서 '우린 거지 같은 기본 앱들을 전부 빼버렸어요'라는 문장을 장점 혹은 특징으로 내세우기도 했다.

지금은 몇몇 기본 앱을 설치할 것이냐고 묻지만, 옛날에는 묻지도 따지지도 않고 무작정 아예 시스템 영역에 박아놓고 펌웨어를 배포했었다.

그렇게 바뀐 것도 5년이 채 안 되었을 것이다.

 

지금에 와서는 상황이 많이 바뀌었다.

 

첫째로, 안드로이드나 제조사 커스텀에서 커스텀 롬이 구현한 것들을 자체적으로 구현하는 모습을 보이고 있다.

가장 최근의 것이 무엇이냐 묻는다면…

삼성의 안드로이드 12 펌웨어에는 '어떤 앱이 토스트 메시지를 보냈는가'에 대한 표시로 앱 아이콘을 토스트 메세지 옆에 보여주는 기능이 있다. 해당 기능은 아주 옛날, KitKat(4.4) 즈음에 Xposed 모듈로 구현되었던 기능을 가져온 것이다.

이외에도 커스텀 롬의 기능이 안드로이드나 제조사 커스텀에 추가된 것이 상당히 많다.

 

둘째로, 제조사 측에서 이러한 커스텀을 막기 위한 방지책을 꾸준히 개선함과 동시에 커스텀 사용에 단점을 부여하고 있다.

말해 무엇하랴, 삼성의 Knox를 말하는 것이다.

Knox가 처음 나왔을 때는 Knox를 적극적으로 활용한 기능이 없었고, 기업만을 대상으로 하는 경향이 심했다. 그 말인즉슨, 일반 사용자 입장에서는 Knox 카운터를 깨버려도 별 상관이 없었다는 이야기다.

하지만 지금에 와서는 Knox에 연결된 서비스가 너무나도 많다. 삼성 헬스부터 시작해서 보안 폴더, 삼성 페이 등등…

일부 기능은 커스텀 커널을 통해 Knox 카운터를 속여 정상적으로 이용할 수 있지만, 삼성 페이와 같은 기능은 Knox 카운터를 속일 수 없다. 즉, 커스텀 롬을 설치하면 영영 삼성 페이를 사용할 수 없게 된다는 뜻이다.

거기다가 삼성의 Good Lock을 보자. 삼성 갤럭시 스토어에 대놓고 나타나 있지는 않지만, 검색하면 나온다.

이걸 설치해서 이런저런 모듈을 설치하면 삼성의 One UI를 상당히 내 입맛대로 뜯어고칠 수 있다.

이러한 점 역시 커스텀 롬의 필요성을 저하한다.

이것마저도 불만족스럽다면 Substratum을 이용해서 테마를 바꿀 수도 있다. Good Lock이 Substratum을 보고 만든 것 같지만 말이다.

 

왜 굳이 삼성만 이야기하냐면, 삼성이 이런 데 있어서 제일 까탈스러운 제조사이기 때문이다.

다른 제조사는 부트로더를 언락한다고 해서 딱히 기능이 제한된다는 이야기를 들어보지 못했지만, 삼성은 Knox 카운터라는, 하드웨어적 잠금장치를 구현해서 쓰고 있는, 내가 알고 있는 유일한 제조사이다.

그런 삼성마저도 XDA에 가면 온갖 커스텀 롬이 나오고 있다.

 

다만 새로 나오는 기기일수록 이러한 제조사의 커스텀 롬 방지 대책에 영향을 받아 커스텀 롬의 개발 자체가 더뎌지고 있다.

옛날에는 AOKP니, OmniRom이니, SlimRoms니, 독도프로젝트니, 곰돌라이트니 해서 국내 해외 할 것 없이 다양한 커스텀 롬이 나왔지만, 최근 기기들은 글쎄다. 내가 S8+에서 본 프로젝트만 따지면 Evolution X, HavocOS, Lineage OS, Pixel Experience, crDroid 이게 전부다.

리커버리 역시 TWRP 혹은 거기서 파생된 리커버리가 다 해 먹고 있다. 옛날에는 ClockworkMod 혹은 Philz가 대세였는데, 요새는 도통 보지를 못했다. Philz도 뭐 ClockworkMod에서 파생된 것이니까 옛날에는 ClockworkMod가 다 해 먹었다고 해도 되겠지만…

 

루팅 관련해서도 슬슬 제약이 걸리고 있다.

옛날에는 KingRoot와 같은 기기의 하드웨어 취약점을 이용하거나 su 바이너리를 추가한 펌웨어를 플래싱하는 등의 방식으로 기기를 루팅하곤 했다.

은행과 같은, 루트 환경에서의 앱 사용을 막고 싶은 개발 측은 기기가 루팅 되었는지 확인하기 위해 SuperSU와 같은 유명 루트 권한 관리자 앱이나 su 바이너리의 존재 여부를 확인하기 시작했다.

그러자 아예 특정 앱에 대해 루트 여부 자체를 숨겨버리는 Magisk가 나왔다. 뭐, Magisk의 특징은 그것 하나뿐만이 아니긴 했지만.

Magisk가 대세가 되자, 앱 개발자들 역시 Magisk를 타깃으로 잡기 시작했다.

 

여기에 얽힌 이야기도 좀 웃긴대, 처음에는 앱에서 기기의 Unix Socket을 훑어보고 Magisk와 관련된 것 같은 이름을 가진 소켓이 있으면 '아 루팅했네'라고 판단하고 앱을 종료했다.

이에 대응해, Magisk 개발자인 John Wu는 Magisk가 사용하는 소켓의 이름을 32글자 길이의 랜덤한 문자열로 설정했다.

그러자 앱 개발자들은 그냥 기기에 이름 길이가 32글자인 Unix Socket이 있으면 묻지도 따지지도 않고 기기가 루팅 된 것으로 판단했다. 야, False Positive는 어디 갔냐? Magisk가 아닌 다른 앱이 32글자 길이의 Unix Socket을 등록해도 기기가 루팅 된 것으로 판단하는 것이다.

이것 때문에 국내 유명 개발자인 arter97이 '헬조선 Magisk'를 개발했는데, 여전히 앱 개발자들은 이 '헬조선 Magisk'를 제대로 못 잡는 것 같다. 병신들.

 

아무튼, Magisk의 개발자인 John Wu는 구글에 이직한 이후, Magisk의 존재를 다른 앱으로부터 숨기는 Magisk Hide 기능을 제거했다.

본인 말로는 Zygisk + DenyList라는 더 강력한 방법이 있으니 그걸 쓰는 게 더 좋다고 하지만… 글쎄다. 아직 이걸 써본 적이 없어서 모르겠다. 일단 설명만 들어보면 기존의 Magisk Hide보다 더 강력한 기능이기는 하다. OS 레벨이 아니라 커널 레벨부터 루트 여부를 숨겨버리니까.

하지만 John Wu가 이직한 부서가 '안드로이드 보안' 관련 부서라서 거기서 압력이 좀 있지 않았을까 하는 의심이 든다.

 

그래서 이 긴 글의 목적이 무엇이냐 묻는다면, 그냥 주저리이다.

'옛날에는 커스텀 롬도 많았고 갖고 놀거리도 많았는데…' 하는 –틀–의 주저리, 그런 셈이다.

comments powered by Disqus