Honey의 소스 코드를 읽어봤습니다

TThe PrimeTime
Computing/SoftwareAdvertising/MarketingInternet Technology

Transcript

00:00:00(키보드 타자 소리) 지금 큰 논란이 되고 있는 Honey 스캔들에 대해 살펴보려고 합니다.
00:00:12Honey에 대해 잘 모르시는 분들을 위해 설명하자면,
00:00:15Honey는 쿠폰 크롬 확장 프로그램 중 하나인데,
00:00:17이는 모든 코드를 제가 직접 열람할 수 있다는 의미입니다.
00:00:19그래서 이 유튜브 영상들에서 제기되는 주장들을 직접 살펴보고,
00:00:23실제로 이런 일이 일어나고 있는지 확인할 수 있습니다.
00:00:26더욱이 확장 프로그램의 경우,
00:00:28시간의 흐름에 따라 추적하면서 이런 나쁜 결정들이 내려졌는지,
00:00:32그리고 소프트웨어 엔지니어들이 이를 지속할 뿐만 아니라 이러한 나쁜 행위들을 더욱 정교하고 견고하게 만들기 위해 코드를 수정했는지 실제로 확인할 수 있습니다.
00:00:44네, 그들은 그렇게 했습니다.
00:00:45그리고 제가 그것이 어떻게 일어났는지 보여드리겠습니다.
00:00:47하지만 여러분 중 많은 분들이 아마 무슨 일이 일어나고 있는지 전혀 모르실 거라는 걸 알고 있습니다.
00:00:50Honey에 대해 잘 알지 못하시는 분들도 계시겠죠.
00:00:52그래서 상황을 제대로 파악하지 못하셨을 겁니다.
00:00:55이것은 사실 제가 다루고 싶은 Honey의 매우 특정한 작동 방식과 관련이 있습니다.
00:00:59그래서 우리는 실제로 이 최신 Honey 폭로 영상에서 3분짜리 발췌본을 볼 것입니다.
00:01:05그런 다음 제가 압축된 코드를 살펴보면서 정확히 무엇을 발견했는지,
00:01:08그리고 그 뒤에 숨겨진 의도가 무엇인지에 대해 이야기하겠습니다.
00:01:10그것은 꽤 놀라운 내용입니다..
00:01:12사람들이 속임수보다 더 싫어하는 게 있다면, 그건 바로 도둑질입니다.
00:01:15그리고 제 첫 번째 영상에서, Honey가 인플루언서들로부터 돈을 훔치는 방법을 보여드렸습니다.
00:01:19하지만 제가 말씀드리지 않았던 것은 이러한 행위가 대부분의 경우 명백히 허용되지 않는다는 것입니다.
00:01:25이 업계를 운영하는 회사들,
00:01:26즉 제휴 네트워크들은 Honey와 같은 쿠폰 확장 프로그램이 인플루언서,
00:01:30블로거,
00:01:31그리고 다른 콘텐츠 기반 제휴 파트너들로부터 수수료를 가로챌 가능성이 높다는 것을 잘 알고 있습니다.
00:01:37더 중요한 것은,
00:01:38그들도 이것이 공정하지 않다는 것을 이해하고 있다는 점인데,
00:01:41특히 업계 표준으로 남아있는 '마지막 클릭 승리' 정책 하에서는 더욱 그렇습니다.
00:01:46따라서 이런 유형의 수수료 도용을 방지하기 위해,
00:01:49대부분의 주요 제휴 네트워크는 '스탠드 다운 정책'이라고 알려진 것을 시행합니다.
00:01:53Honey에서 그것이 어떻게 작동하는지 보여드리겠습니다.
00:01:55먼저 제휴 링크 없이 newegg.com을 방문해 보겠습니다.
00:01:58보시다시피, Honey가 즉시 팝업으로 나타나 캐시백을 제안합니다.
00:02:02하지만 이번에는 제 Newegg 제휴 링크를 사용해서 다시 해보면,
00:02:05Honey가 전혀 팝업으로 나타나지 않는 것을 알 수 있습니다.
00:02:08그리고 Honey 아이콘을 클릭하면, Honey가 현재 비활성화되어 있는 것을 볼 수 있습니다.
00:02:12이것이 사용자가 이미 다른 사람의 제휴 링크를 클릭했을 때 Honey가 작동해야 하는 방식입니다.
00:02:17그렇다면 주장되는 사기는 어디에 있냐고요?
00:02:20알고 보니,
00:02:20Honey는 항상 앱에 스탠드 다운 시스템을 내장하고 있었지만,
00:02:24언제 누구에게 규칙을 적용할지 선택적으로 결정해왔습니다.
00:02:28제 Newegg 제휴 링크를 다시 테스트해 보겠습니다.
00:02:31단,
00:02:32이번에는 두 개의 완전히 별도의 크롬 브라우저를 동시에 열어두고,
00:02:35각각 다른 Honey 계정에 로그인되어 있습니다.
00:02:38왼쪽의 Honey 계정은 캐시백 포인트가 0이고, 오른쪽의 Honey 계정은 캐시백 포인트가 쌓여 있습니다.
00:02:45이제 두 브라우저 모두에서 Newegg 제휴 링크를 열면 무슨 일이 일어날까요?
00:02:49왼쪽의 Honey 계정은 처음처럼 스탠드 다운합니다.
00:02:52하지만 이것 좀 보세요, 캐시백 포인트가 있는 오른쪽 계정은 스탠드 다운하지 않았습니다.
00:02:58그렇다면 왜 그럴까요?
00:02:59이것이 제가 테스트하고 싶었던 것입니다.
00:03:01이것을 직접 살펴보고 싶었습니다. 왜냐하면 이것은 코드니까요.
00:03:03저는 코드를 이해할 수 있습니다.
00:03:05전송되는 JSON을 보고 이해할 수 있습니다.
00:03:09뿐만 아니라,
00:03:10AI의 힘을 이용하면 제 전체 프로그래밍 경험 동안에는 상상도 못했던 속도로 압축된 코드를 검색할 수 있습니다.
00:03:18그래서 우리가 한 것은 먼저 Honey의 여러 버전들을 확보한 것입니다.
00:03:22제가 살펴본 버전들은 대략 2019년 2월부터 현재까지, 1901 버전까지입니다.
00:03:29그리고 그것을 가지고,
00:03:30제가 하고 싶었던 것은,
00:03:31좋아,
00:03:31우선 이 사용자 포인트 같은 것이 스탠드 다운 메뉴를 언제 보여줄지 말지를 결정하는지,
00:03:35그게 존재하는지 확인하는 것이었습니다.
00:03:37네, 실제로 존재합니다..
00:03:38하지만 진짜 질문은, 그것이 변경되었는가 하는 것이었습니다.
00:03:40그것이 정말 바뀌었는지 말이죠.
00:03:43저는 대기업에서 일했었고, 여러분도 대기업에서 일해본 적 있으시죠?
00:03:47분명 몇 분은 그러실 텐데, 때로는 코드가 그냥 남아있다는 걸 아실 거예요..
00:03:50그러니까, 실수로 그냥 거기 있는 거죠. 5년 동안 아무도 건드리지 않았고, 그냥 그런 식인 거예요.
00:03:55그게 제가 찾고 있던 거였어요. 코드가 그대로 남아있었는지 말이죠.
00:04:00아니면 의미 있는 변경이 있었는지요.
00:04:03작은 버그 수정 같은 게 아니라요.
00:04:05자,
00:04:05저작권 문제를 피하기 위해서,
00:04:07왜냐하면 페이팔 변호사들이 실제로 코드를 보여주는 사람에게 DMCA로 저작권 공격을 할 수 있거든요.
00:04:13그래서 제가 칠판에서 이상한 몸짓 춤을 춰가며 무슨 일이 있었는지 보여드려야 해요.
00:04:18버전 11부터 시작해서, 기억하시죠, 대략 2019년쯤인데, 이 버전에는 스탠드 다운 로직이 있었어요.
00:04:25심지어 SSD 스탠드 다운 로직이라고 불리는 것들도 있었죠.
00:04:29수많은 데이터가 담긴 JSON 파일과 매칭되었어요.
00:04:32여기 로그인조차 하지 않은 사용자, 가장 기본적인 것들에 대한 제 스탠드 다운이 있습니다.
00:04:38여기서 UP는 사용자 포인트를 의미해요.
00:04:41ADB는 애드 블록 마지막 사용 시간 같은 거예요.
00:04:45계정 로그인 여부도 있고요.
00:04:47그리고 가끔씩 나타나는 다른 필드들도 있어요.
00:04:50흥미로운 건 2019년 버전 11에서는 종종 이렇게 생겼다는 거예요.
00:04:55거대한 switch 문이 있었고, 이메일을 테스트할지 같은 케이스들이 있었죠.
00:05:02그리고 네, 말 그대로 문자열이 있었어요.
00:05:04이 이메일에 test가 포함되어 있나요?
00:05:06그럼 무조건 스탠드 다운인데, 그건 그렇고 수상해요.
00:05:10링크 테스팅 계정들이 들어와서 링크 공유 테스트를 해보고 실제로 작동하는지 확인하는 걸 막으려는 거예요.
00:05:16솔직히 말해서, 여기 계신 분 중에 test가 포함되지 않은 테스터 계정을 가져본 적 없는 분이 계신가요?
00:05:20저는 분명히 있어요.
00:05:22그럼에도 불구하고, 여기 이게 명시적인 체크였어요.
00:05:24이메일 어디든 test라는 단어가 있으면, 비활성화시키는 거죠.
00:05:29하지만 그것보다 더,
00:05:30이미 언급되긴 했지만,
00:05:32정말 혼란스러웠던 건 일련의 체크를 거치면서 현재 활성화된 프로바이더가 LS,
00:05:37즉 링크셰어와 같은지 확인하는 거였어요.
00:05:41만약 그렇다면, 이 정확한 규칙들을 적용하라는 거죠.
00:05:44그리고 나중에는 파악해낸 모든 규칙들을 검토하는 체크가 있었고,
00:05:49작은 for 루프로 이 규칙들을 하나하나 거치면서 실패하는 게 있는지 확인했어요.
00:05:55하나라도 실패하면, 스탠드 다운되는 거죠.
00:05:57보시다시피 이건 꽤 하드코딩된 프로세스였어요.
00:06:01링크셰어면 이 작업을 하라는 식의 문자 그대로의 라인이 있었으니까요..
00:06:06다른 프로바이더라면, 다른 걸 하라는 식이었죠.
00:06:08물론 저는 이런 일이 그냥 일어나는 많은 프로젝트에 참여해왔어요.
00:06:12이건 완전히 정상이에요.
00:06:14처음에는 한두 개의 프로바이더만 있을 거라고 생각하고 시작하잖아요.
00:06:18그래서 그냥 약간의 하드코딩된 엣지 케이스를 여기 넣고 특정 방식으로 처리되도록 확실히 해두는 거죠.
00:06:24일정 시간 동안 스탠드 다운하는데, 그건 그렇고 그리 긴 시간이 아니었어요.
00:06:27규칙들이 실제로 얼마나 끔찍했는지 정확히 알아보려면 MegaLeg의 영상을 보셔야 해요.
00:06:34하지만 다시 말하지만, 제 목표는 코드에 변경을 가했는지, 버그 수정이었는지 확인하는 거예요.
00:06:39무슨 일이 있었나요?
00:06:40글쎄요,
00:06:40여기서 일이 좀 혼란스러워지는데,
00:06:43버전 11부터 14까지,
00:06:45제 생각엔 2022년까지인데,
00:06:47네 2022년,
00:06:48상황이 거의 일정하게 유지됐어요.
00:06:52실제로 아무것도 변하지 않았고, 약간의 수정만 있었을 뿐 보여줄 만한 건 별로 없어요.
00:06:56하지만 제 생각에 버전 16부터,
00:06:58그러니까 2024년에,
00:07:00이런 결정들의 상당 부분을 Honey의 엔드포인트에서 처리할 수 있도록 강력한 리팩토링이 이루어졌어요.
00:07:07이제 이 엔드포인트는 이런 모습의 객체를 보내는데,
00:07:11기본값이 있고,
00:07:12이런 값들이 있고,
00:07:14X 아래에 이런 값들이 있어요.
00:07:16즉, 이전 버전에서는 원하는 동작 유형을 결정하기 위해 일련의 if 문을 많이 사용했다는 뜻이죠.
00:07:23그런 다음 규칙 평가를 수행해서 이 규칙이 실제로 통과했는지 확인합니다.
00:07:28실제로 참 또는 거짓이 나왔는지 말이죠.
00:07:30하지만 버전 16에서는 소프트웨어 엔지니어링 측면에서 좀 더 본격적으로 접근하기로 했습니다.
00:07:36우리 모두 알다시피,
00:07:37데이터를 래핑하고 객체에 기본적인 변경을 가하는 일련의 if 문이 있을 때 어떻게 하나요?
00:07:45당연히 어떤 종류의 설정을 통해 구동하고 싶을 겁니다.
00:07:48좀 더 쉽게 만들기 위해 좀 더 동적인 것을 통해 구동하고 싶을 거예요.
00:07:52그리고 그들이 정확히 그렇게 했습니다.
00:07:53여기로 돌아가서 로그인하지 않은 허니 사용자인 저에게서 내려오는 데이터를 보면,
00:07:58여기 베이스 클래스가 있는 걸 볼 수 있습니다.
00:08:00이 베이스 클래스는 허니가 판단하는 기준이 되는 기본 객체가 됩니다.
00:08:05현재 이 로그인하지 않은 사용자 베이스 클래스의 경우,
00:08:09허니가 물러서지 않으려면 65,
00:08:11000 사용자 포인트가 필요합니다.
00:08:1365,
00:08:14000 포인트보다 적으면,
00:08:15저는 로그인하지 않았으니 0 포인트를 가지고 있다는 걸 기억하세요,
00:08:17죄송하지만 물러서겠다고 말할 겁니다.
00:08:18이걸 피하는 거죠.
00:08:20이제 그 베이스를 얻으면, 다음으로 하는 일은 어떻게 여기에 도달했는지 확인하는 겁니다.
00:08:25어디서 여기에 왔을까요?
00:08:27왜 여기에 왔을까요?
00:08:28그리고 다음 확인을 합니다. 이게 이런 제휴 네트워크 중 하나에서 온 건가요?
00:08:32그런 다음 래핑을 시작합니다.
00:08:33그러니까, 제가 링크 셰어 같은 곳에서 오면, 이제 필요한 포인트가 5,001로만 됩니다.
00:08:40이 베이스 객체를 편집하는 겁니다.
00:08:41실제로 더 나은, 더 정교한 엔지니어링을 하고 있는 거죠.
00:08:44더 이상 일련의 하드코딩된 if 문이 아닙니다.
00:08:48대신, 실제로 베이스를 가져오는 거죠.
00:08:51그런 다음 내 프로바이더가 있나요?
00:08:55내 프로바이더가 있으면, 내 프로바이더의 값들을 스프레드하거나 그냥 빈 객체를 넣고 싶은 겁니다.
00:09:01그런 다음 훨씬 더 놀라운 일을 했는데, 바로 여기 X 아래에 있는 이 모든 것들입니다.
00:09:07이것들은 모두 스토어별 값들입니다.
00:09:09그런 다음 확인합니다. 현재 어떤 스토어에 있든, 그 값들도 넣고 싶다고요.
00:09:17그런 다음 기본 규칙 로직을 실행하면서 더 이상 어떤 종류의 유지보수 모드가 아니라는 걸 보여줍니다.
00:09:23더 이상 10년 동안 존재해온 하드코딩된 해키한 것이 아니라는 걸 보여주는 거죠.
00:09:29대신, 그것에서 벗어났습니다.
00:09:31그리고 2024년에 그들은 이렇게 말했습니다.
00:09:33더 견고해져야 하고 더 많은 스토어와 더 많은 프로바이더에 대해 더 유지보수하기 쉬운 방식으로 더 많은 결정을 내릴 수 있어야 한다고요.
00:09:43이게 바로 소프트웨어 엔지니어링이고 그들은 해냈습니다.
00:09:46제가 이걸 볼 때,
00:09:47시간이 지나면서 그들이 시스템을 더 좋게 만들기 위해 변경을 했다는 것을 알 수 있고,
00:09:52이는 그 뒤에 의도가 있다는 의미입니다.
00:09:54그들은 시스템이 하고 있는 것이 사기든 아니든, 그것을 유지하고 싶어 합니다.
00:09:59그게 사기인지 아닌지는 제가 말할 수 없고 다른 누군가가 결정할 일이지만,
00:10:03적어도 그들의 결정이 더 견고하고 더 좋게 만드는 쪽이었다는 건 말할 수 있습니다.
00:10:07그리고 이 시스템이 꽤 수상하다는 일반적인 인식을 고려하면,
00:10:11그들은 꽤 수상한 시스템을 훨씬,
00:10:14훨씬 더 좋게 만들었습니다.
00:10:16하지만 제가 발견한 게 그게 전부가 아닙니다.
00:10:17제 흥미를 끈 다른 것을 발견했습니다.
00:10:19VIM이라는 단어가 계속 나타나는 걸 계속 봤습니다.
00:10:23저는 VIM이라니, 텍스트 에디터가 여기서 뭘 하는 거지?
00:10:26클로드 코드에게 물어봤을 때,
00:10:28실제로 허니 안에서 발견된 VIM 인스턴스 매니저에 대해 얘기하는 거라고 했습니다.
00:10:34그래서 저는 VIM 인스턴스 매니저라고요.
00:10:35좋아요, 그게 아닐 수가 없어요.
00:10:37그게 아니에요.
00:10:38그리고 이걸 보기 시작하면서,
00:10:40제가 결국 본 건 허니 플러그인 안에서 실행되는 완전한 자바스크립트 인 자바스크립트 엔진이 있다는 겁니다.
00:10:49이제 이건 제가 본 것 중 가장 이상한 것입니다.
00:10:54이에 대해 좀 읽어보려고 했습니다.
00:10:56저는 크롬에 관한 플러그인 개발자 전문가가 아닙니다.
00:10:59그래서 왜 누군가 자바스크립트 안에서 자바스크립트를 실행하려고 하는지 전혀 몰랐습니다.
00:11:05하지만 허니가 하는 일은 실제로 에이콘(Acorn)을 가지고 있다는 건데,
00:11:10이건 자바스크립트 파서이고 유효한 자바스크립트에서 AST를 생성합니다.
00:11:14그리고 이걸 가져와서 자바스크립트를 평가한 다음 이 VIM 엔진에 공급합니다.
00:11:19코드 내에는 cart ops retrieval JS와 product ops retrieval JS라는 다른 객체를 참조하는 여러 참조가 있는데,
00:11:27이들은 때때로 null이 아니라 실제로 코드를 포함하고 있습니다.
00:11:31그리고 이 JS 코드도 참조하는데,
00:11:33이것도 때때로 null이 아니고,
00:11:35바로 여기처럼 실제 진짜 JavaScript입니다.
00:11:38하지만 제가 확인한 바로는, 실제로 이 코드들 중 어느 것도 실행되지 않는 것 같습니다.
00:11:41브레이크포인트를 설정해보기도 했습니다.
00:11:42트리거를 만드는 단계까지는 실제로 도달하지 못했지만, 그럼에도 불구하고 이것은 존재합니다.
00:11:47Honey로부터 반환되는 것에 기반하여 여러분의 컴퓨터에서 원격 코드를 실행할 수 있는 장치가 매우,
00:11:54매우 난독화된 방식으로 설정되어 있습니다.
00:11:57JavaScript 안의 JavaScript, 그들은 JavaScript 파서를 가지고 있습니다.
00:12:00JavaScript 가상 머신을 가지고 있습니다.
00:12:03JavaScript 안에 있는 실제 JavaScript입니다.
00:12:06하지만 또한 문자열화된 함수들로만 가득 찬 섹션도 있습니다.
00:12:11그리고 페이지를 검색하는 방법들로 가득 찬 인라인 JavaScript가 잔뜩 있습니다.
00:12:18하지만 그것들은 제품과 함께 내려옵니다.
00:12:22그래서 기술적으로는 이전 Google 서비스 약관을 위반하지 않습니다.
00:12:26왜냐하면 manifest V3의 추가 요구사항을 보면,
00:12:29JavaScript eval을 사용하는 것이 허용되지 않아야 한다고 되어 있거든요.
00:12:33좋아요, 그럼 그렇게 하지 않을 겁니다.
00:12:34eval은 사용하지 않을 거예요.
00:12:35대신 할 것은 다른 플러그인들이 우리가 하는 일을 알지 못하게 하고 싶은 작업들을 하드코딩하는 겁니다.
00:12:40그리고 나서 우리가 하는 일을 더욱 난독화하기 위해 그것들을 실행할 JavaScript 엔진 전체를 통합할 겁니다.
00:12:47재미있는 건 바로 여기 이 V3이 마치 Honey를 위해 특별히 설계된 것처럼 보인다는 겁니다.
00:12:52왜냐하면 '원격 소스에서 가져온 복잡한 명령을 실행하기 위한 인터프리터를 구축하는 것,
00:12:56그 명령들이 데이터로 가져와지더라도'라고 되어 있거든요..
00:12:59그래서 그들은 이걸 우회합니다.
00:13:00이것들은 원격 것들이 아닙니다.
00:13:01이것들은 실제로 Honey 확장 프로그램 내에서 사용 가능한 문자열들입니다.
00:13:05하지만 와, 이건 정말 난독화네요.
00:13:07이건 정말 이상한 것들입니다.
00:13:09저는 개인적으로 이게 왜 실제로 일어나고 있는지 단 하나의 이유도 이해할 수 없습니다.
00:13:14제가 말했듯이,
00:13:14다른 확장 프로그램들과의 상호작용 때문인 것 같은데,
00:13:16그 다른 확장 프로그램들이 바로 광고 차단기들입니다.
00:13:19광고 차단기들이 특정 함수를 직접 실행하면 Honey 확장 프로그램을 차단할 수 있는데,
00:13:24어떻게든 이 이상한 인터프리터를 통해서는 감지되는 것을 피하면서 실제로 실행할 수 있는 것 같습니다.
00:13:31잘 모르겠지만, 제게는 완전 엉망진창으로 보입니다.
00:13:34그리고 저는 이게 매우, 매우 흥미로웠습니다.
00:13:35왜냐하면 저는 어떤 종류의 리버스 엔지니어링도 해본 적이 없거든요..
00:13:37다른 사람의 소스 코드, 특히 압축된 소스 코드를 제대로 살펴본 적이 없습니다.
00:13:41여러분께 이걸 보여드리고 싶었습니다.
00:13:42이것은 아마도 제가 평생 본 것 중 가장 특이한 엔지니어링일 겁니다.
00:13:46저는 만 줄 이상의 이상한 상태 머신들로 이루어져 있고 작업하기 불가능하고 이해하기 어려운 코드베이스의 일원이었던 적이 있지만,
00:13:55이건 단연 최고입니다.
00:13:57이건 제가 본 것 중 가장 복잡하고 가장 이상한 장치, 루브 골드버그 수준입니다.
00:14:03게다가, 스탠드다운 작업을 위한 동적 규칙들은 견고합니다.
00:14:08목적이 사기인지 아닌지와 관계없이,
00:14:11이것은 스토어별,
00:14:12제공자별,
00:14:13사용자별로 JSON을 통해 동적으로 제어되도록 설계되었습니다.
00:14:19어쨌든, Magalega에게 특별한 감사를 드리고 싶습니다.
00:14:21정말 멋졌습니다.
00:14:22그와 대화를 나눌 수 있었습니다.
00:14:23그가 몇 가지를 살펴보는 데 조금 도움을 주었습니다.
00:14:25그에게 큰 감사를 드립니다.
00:14:26꼭 그 영상을 확인해보세요.
00:14:27설명란에 있습니다.
00:14:28정말 잘 만들어졌습니다.
00:14:29여러 개가 있으니 전부 보시길 추천합니다.
00:14:32정말, 정말 좋습니다.
00:14:33또한, 제가 한 이것이 마음에 드시나요?
00:14:35이 형식이 마음에 드시나요?
00:14:36잘 모르겠네요.
00:14:37이건 좀 새로운 거예요.
00:14:38이건 그냥 제가 스트림에서 시간을 보내며 재미있게 놀고 나서 여러분께 보고하는 겁니다.
00:14:42스트림에 계셨다면 이게 실시간으로 일어나는 걸 보셨을 겁니다.
00:14:44여러분에게 훨씬 더 재미있었을 수도 있었을 거예요.
00:14:45제 이름은 '리버스 엔지니어가 아니지만'이고, 이건 정말 재미있었습니다.
00:14:50사람들이 왜 이걸 하는지 알 것 같아요.
00:14:51안녕히 계세요.
00:14:52저기, 그거 HTTP야?
00:14:55그런 거 치워.
00:14:56우리는 그런 식으로 커피 주문 안 해.
00:14:57우리는 SSH로 커피를 주문해, terminal.shop에서.
00:15:00진짜 경험을 원하는 거야?
00:15:02진짜 커피를 원하는 거야?
00:15:03다시는 기억할 필요 없는 멋진 구독 서비스를 원하는 거야?
00:15:06독점 블렌드, 독점 커피, 독점 콘텐츠를 원하는 거야?
00:15:12그럼 CRON을 확인해 봐.
00:15:13SSH가 뭔지 모른다고?
00:15:14그럼 이 커피는 너한테 안 맞을 수도 있어.
00:15:18♪ 터미널 커피를 손에 들고 ♪ ♪ 꿈속을 살아가네 ♪

Key Takeaway

Honey는 2019년부터 제휴 수수료를 선택적으로 가로채는 스탠드 다운 시스템을 운영해왔으며, 2024년에는 이를 더욱 정교하고 동적인 시스템으로 발전시켰고, JavaScript 인터프리터까지 내장하여 극도로 난독화된 방식으로 작동하고 있습니다.

Highlights

Honey 크롬 확장 프로그램의 소스 코드를 2019년부터 현재까지 분석하여 스탠드 다운 로직의 변화를 추적했습니다

2024년 버전 16부터 하드코딩된 if문 대신 동적 JSON 기반 규칙 시스템으로 대규모 리팩토링이 이루어졌습니다

사용자 포인트에 따라 선택적으로 제휴 링크 가로채기를 수행하는 차별적 스탠드 다운 정책이 확인되었습니다

Honey 내부에 JavaScript 인터프리터(VIM 엔진)가 숨겨져 있어 원격 코드 실행이 가능한 구조로 설계되어 있습니다

테스트 계정 차단, 제휴 네트워크별 차별화, 스토어별 맞춤 규칙 등 정교한 회피 메커니즘이 발견되었습니다

manifest V3 정책을 우회하기 위해 Acorn 파서와 자체 VM을 사용한 극도로 난독화된 코드 구조를 사용합니다

코드의 지속적인 개선과 유지보수는 이러한 행위가 의도적이고 전략적임을 보여줍니다

Timeline

영상 소개 및 분석 목표 설정

발표자는 현재 논란이 되고 있는 Honey 스캔들에 대해 소스 코드 레벨에서 분석하겠다고 소개합니다. Honey는 크롬 확장 프로그램이기 때문에 모든 소스 코드를 직접 열람할 수 있다는 점을 강조합니다. 시간의 흐름에 따라 코드 변경 사항을 추적하여 이러한 의심스러운 행위들이 실수가 아닌 의도적인 결정이었는지 확인하는 것이 목표입니다. 소프트웨어 엔지니어들이 이러한 나쁜 행위들을 더욱 정교하고 견고하게 만들기 위해 실제로 코드를 수정했는지 검증하겠다고 밝힙니다. AI의 힘을 이용하면 압축된 코드도 이전에는 상상할 수 없었던 속도로 검색하고 분석할 수 있다고 설명합니다.

MegaLeg 영상 클립: Honey의 선택적 스탠드 다운 정책

MegaLeg의 Honey 폭로 영상 중 3분 분량이 재생됩니다. 영상에서는 제휴 네트워크들이 쿠폰 확장 프로그램의 수수료 가로채기를 방지하기 위해 '스탠드 다운 정책'을 시행한다고 설명합니다. Newegg 제휴 링크로 접속했을 때 Honey가 비활성화되는 것을 보여주는 정상적인 사례를 먼저 시연합니다. 그러나 놀랍게도 두 개의 다른 Honey 계정으로 테스트했을 때, 캐시백 포인트가 0인 계정은 스탠드 다운하지만 포인트가 쌓인 계정은 스탠드 다운하지 않는 차별적 행동이 발견됩니다. 이는 Honey가 사용자를 선별하여 언제 누구에게 규칙을 적용할지 선택적으로 결정하고 있음을 보여주는 결정적 증거입니다.

초기 버전(2019년) 스탠드 다운 로직 분석

발표자는 2019년 2월부터 현재까지 Honey의 여러 버전을 확보하여 분석을 시작합니다. 버전 11(2019년)에서는 SSD 스탠드 다운 로직이 이미 존재했으며, 사용자 포인트(UP), 애드 블록 마지막 사용 시간(ADB), 계정 로그인 여부 등을 체크하는 JSON 기반 규칙이 있었습니다. 특히 주목할 만한 점은 이메일에 'test'라는 단어가 포함되어 있으면 무조건 스탠드 다운시키는 명시적인 체크가 있었다는 것인데, 이는 링크 테스팅 계정들의 검증을 의도적으로 막으려는 시도로 보입니다. 당시 코드는 링크셰어(LS) 같은 특정 제공자에 대해 하드코딩된 switch문과 if문으로 구성되어 있었으며, 규칙들을 하나씩 체크하여 하나라도 실패하면 스탠드 다운하는 방식이었습니다. 발표자는 이러한 하드코딩 방식이 초기 프로젝트에서는 정상적이라고 언급합니다.

2022년까지의 정체 기간과 2024년 대규모 리팩토링

버전 11부터 14까지, 즉 2022년까지는 코드가 거의 변경되지 않고 유지되었습니다. 그러나 2024년 버전 16부터 강력한 리팩토링이 이루어졌습니다. 이전의 하드코딩된 if문 방식에서 벗어나 서버 엔드포인트에서 동적으로 결정을 내릴 수 있도록 설계가 변경되었습니다. 새로운 시스템은 베이스 클래스 객체를 기반으로 하며, 로그인하지 않은 사용자의 경우 65,000 사용자 포인트가 필요하다는 기본값을 설정합니다. 그런 다음 사용자가 어떤 제휴 네트워크에서 왔는지 확인하고, 예를 들어 링크셰어에서 온 경우 필요 포인트를 5,001로 낮추는 방식으로 베이스 객체를 동적으로 수정합니다. 더 나아가 스토어별 값들도 별도로 관리하여 훨씬 더 세밀한 제어가 가능하도록 설계되었습니다. 발표자는 이것이 더 이상 유지보수 모드가 아니라 적극적인 소프트웨어 엔지니어링임을 강조합니다.

리팩토링의 의미와 의도성 분석

발표자는 2024년의 리팩토링이 단순한 유지보수가 아니라 시스템을 더 견고하고 확장 가능하게 만들기 위한 전략적 결정이었다고 분석합니다. 더 많은 스토어, 더 많은 제공자에 대해 더 유지보수하기 쉬운 방식으로 결정을 내릴 수 있도록 시스템을 개선했다는 것입니다. 시간이 지나면서 그들이 시스템을 더 좋게 만들기 위해 지속적으로 변경을 가했다는 것은 그 뒤에 명확한 의도가 있음을 의미합니다. 시스템이 하고 있는 것이 사기인지 아닌지는 다른 누군가가 결정할 일이지만, 적어도 그들의 결정이 시스템을 더 견고하고 더 좋게 만드는 쪽이었다는 것은 명백합니다. 일반적으로 수상하다고 여겨지는 시스템을 훨씬 더 정교하게 만들었다는 점에서 의도성이 드러납니다.

JavaScript 인터프리터(VIM) 발견과 분석

발표자는 코드를 분석하던 중 VIM이라는 단어가 계속 나타나는 것을 발견합니다. 처음에는 텍스트 에디터를 의미하는 줄 알았지만, 실제로는 'VIM 인스턴스 매니저'라는 것으로 Honey 플러그인 안에서 실행되는 완전한 JavaScript 인 JavaScript 엔진이었습니다. Honey는 Acorn이라는 JavaScript 파서를 내장하고 있으며, 이를 통해 JavaScript를 평가하고 VIM 엔진에 공급합니다. 코드 내에는 cart ops retrieval JS, product ops retrieval JS 같은 객체들이 있으며, 이들은 때때로 실제 JavaScript 코드를 포함하고 있습니다. 발표자가 확인한 바로는 실제로 실행되지는 않는 것 같지만, Honey로부터 반환되는 것에 기반하여 원격 코드를 실행할 수 있는 장치가 매우 난독화된 방식으로 설정되어 있습니다. 페이지를 검색하는 방법들로 가득 찬 인라인 JavaScript가 제품과 함께 내려오는 구조입니다.

Manifest V3 정책 우회 메커니즘

발표자는 Honey의 JavaScript 인터프리터가 Google의 manifest V3 정책을 기술적으로 위반하지 않도록 설계되었다고 설명합니다. Manifest V3에서는 JavaScript eval 사용이 허용되지 않지만, Honey는 eval을 직접 사용하지 않는 대신 다른 플러그인들이 알지 못하게 하고 싶은 작업들을 하드코딩합니다. 그리고 이를 더욱 난독화하기 위해 JavaScript 엔진 전체를 통합했습니다. 정책에는 '원격 소스에서 가져온 복잡한 명령을 실행하기 위한 인터프리터를 구축하는 것'이 금지되어 있지만, Honey는 이것들이 원격이 아니라 확장 프로그램 내에서 사용 가능한 문자열들이라는 점을 이용하여 우회합니다. 발표자는 개인적으로 이것이 왜 실제로 일어나고 있는지 단 하나의 이유도 이해할 수 없으며, 아마도 광고 차단기 같은 다른 확장 프로그램들의 감지를 피하기 위한 것으로 추정합니다.

결론 및 최종 평가

발표자는 Honey의 코드가 자신이 평생 본 것 중 가장 특이하고 복잡한 엔지니어링이라고 평가합니다. 만 줄 이상의 이상한 상태 머신으로 이루어진 코드베이스를 경험한 적이 있지만, 이것은 단연 최고 수준의 루브 골드버그 장치라고 표현합니다. 스탠드다운 작업을 위한 동적 규칙들은 목적이 사기인지 아닌지와 관계없이 매우 견고하며, 스토어별, 제공자별, 사용자별로 JSON을 통해 동적으로 제어되도록 설계되었습니다. MegaLeg에게 감사를 표하며 그의 영상들을 추천합니다. 마지막으로 이러한 리버스 엔지니어링 형식의 콘텐츠에 대한 피드백을 요청하며, 스트림에서 실시간으로 진행된 분석을 요약한 것이라고 설명합니다. 영상은 terminal.shop의 커피 광고로 마무리됩니다.

Community Posts

View all posts