언제나 제자리걸음..

내가 몇몇 일을 봐주고 있는 회사 하나가 층별 출입 통제로 세콤 지문 단말을 사용하고 있었는데, 사옥을 리모델링하면서 8층은 엘리베이터에서 바로 접근이 가능해졌다.
그래서 엘리베이터에 8층 버튼은 그냥 눌러선 눌리지 않고, 지문 인증시에만 작동하도록 설치가 되어있었다.

그렇게 별 생각없이 살고 있었는데, 건물 관리 담당 직원을 보니 신규 직원 입퇴사시마다 건물 관리 보안용으로 세콤에 사용자 등록을 하고, 또 8층 엘리베이터 용으로 신규 직원들을 매번 모아 관리실에 가서 지문 등록을 또 따로 해주고 있더라.

지문 단말기는 Suprema 사의 BioStation L2 라는 장비로, 글 작성 시점 기준으론 지원 종료된 단말기이다.
관리실에는 Windows 서버, 엘리베이터에 장착된 L2 단말기, 등록용 L2 단말기와 이들을 연결하는 공유기로 구성되어 있다.

담당 직원이 매번 관리실로 가야하는 이 비효율과 퇴사 지원의 관리 문제, 그냥 시스템에 대한 관심이 생겨서, 개선할 방법이 없나 이래저래 살펴보았다.

서버 PC 에 어떻게 하는지 살펴보니, 웹브라우저로 관리 페이지에 접속해서 사용자 등록, 등록 과정에서 지문 스캔을 누르면 옆에 있는 등록용 단말기가 반응하고, 지문을 입력할 수 있는 구조였다.

서버 PC 에선 로컬에 MariaDB, java 등을 설치하고 웹 서버가 구동되고 있었고, 서버 내 DB 정보를 단말기 간에 동기화 해준다. 서버가 꺼져있어도 각 단말기는 직전 동기화 정보 기준으로 정상 작동함.

그리고 엘리베이터까지 뜯어보진 않았지만,, 단말기 뒷쪽을 보면 전원, LAN, 릴레이 신호 출력 등을 연결할 수 있는 웨이퍼 커넥터들이 달려있다.
웹 장치 설정을 보면, 특정 이벤트마다 어떤 동작이 수행될지 정의할 수 있는데, 카드 / 지문 / PIN 등 각각 인증 성공시 릴레이로 신호 출력을 걸어둘 수 있다. 릴레이 출력에 문 개폐 등의 장치를 연결해두는 식인 듯. 우리는 엘리베이터에 8층이 눌리도록 배선되어 있겠지?

또한 서버 PC 로컬에 설치된 MariaDB 엔 접속해보면 사용자 관련 데이터는 암호화되어 있어서 DB 직접 접근은 조금 제한되지만 이 서버는 감사하게도 API 를 제공한다.
단, 기본 웹서버는 로컬만 바인드하고 있기 때문에, BioStar 2 Setting 이라는 프로그램을 실행해서 Unified Gateway 를 실행해주면 nginx 를 통해 웹서버가 다시 구동된다.
내 기억엔 이 과정에서 전체 인터페이스로 바인드 했던 것으로 기억.. 아니라도 nginx 는 설정 파일 변경이 용이하니 설치 디렉토리에서 nginx 를 찾아 설정을 변경해주자.

이제 해당 PC 로의 접근이 가능하다면, BioStar X API 문서를 참고하여 시스템을 제어할 수 있다.
위의 BioStar 2라는, 제어용 웹사이트 자체도 이 API 를 기반으로 작동하는 듯?

API 가 완벽한건 아닌 것 같지만,,, 사용자 목록 조회, 사용자 수정(지문 추가 등)/비활성화/삭제, 기기로 지문 스캔 요청 등은 모두 가능하다.
사용자 관리야 그러려니하고, 지문 등록 기준으론 다음 과정을 거치면 된다. 한개의 지문(fingerprint)은 등록시 2개의 스캔 결과(template)가 필요하다.

1. 지문 스캔 두번 - Scan Fingerprint
   • API 를 호출하면, 요청에서 선택한 기기로 지문 인식해달라는 메시지가 바로 표시된다.
   • 정상 스캔시 지문의 퀄리티가 기준치를 충족하는지 확인. Web 에서 기본값은 80인 듯, API 이용한다면 직접 검증 필요
2. 이미 등록된 지문과 일치하는 template인지 확인 - Verify Duplicate Fingerprint
3. 스캔한 2개의 지문(template)이 동일한 지문이 맞는지 검증 - Verify Fingerprint Scan
4. 사용자 정보에 해당 지문(2개의 template 쌍) 추가하여 수정 - User: Update
   • fingerprint_templates 에 기존값 포함하여 추가

이제 제어는 되었고, 매번 관리실로 내려가는 수고를 덜기 위해, 등록용 단말기를 사무실로 가지고 올라와야한다.
서버 PC 와 같은 망에 있어야 하니, 사무실과 관리실까지 건물 내부 EPS 실에서 랜선을 내리니 마니 쌩쑈를 하다가,,

관리실의 서버PC 로 공유기에서 포트포워딩을 해두고, 장비에서 서버의 주소를 공인 IP 로 설정해버렸다.

‘장치에서 서버 연결’이 활성화되어있으면, 단말기에서 서버주소:포트/tcp 로 연결을 요청하고, 연결이 끊겼을 땐 10초? 30초? 잘 기억 안나는데 그 정도 텀을 두고 서버 연결을 시도한다.
장치 포트는 어디 쓰는지 모르겠고 서버 포트 하나만 사용함. 아마 장치에서 서버 연결을 끄면 쓰일 수도 있을 것 같은데, 굳이 테스트해보진 않았다.
연결 성공시 30초 단위로 ping 을 보내면서 연결을 유지하고, 서버에서 지문 인증 요청 등 요청을 보내면 이 채널을 통해서 단말로 명령을 보내고 단말이 작동하는 구조.

등록용 단말기를 테스트한다고 집으로 가져왔는데, 여기서도 잘 작동하는 것을 확인…ㅎㅎㅎ
이제 관리실에 내려가지 않고도 지문 등록이 가능해졌다. 다만 서버 컴퓨터가 항상 켜져있어야 한다는 제약이 생김..

이대로만 끝냈으면 글을 쓰지도 않았을 것,, 시스템 자체에 관심이 생겨서 좀 더 살펴봤다.

DB 암·복호화

로컬에 설치된 DB 는 어찌저찌 접속해도, 사용자 정보에 관한 부분은 대부분 암호화되어 있다.

사실 API 로 가져오면 되니까 크게 필요는 없기도 하다.
이 DB를 그대로 쓴다면, 기기 동기화 시켜야하니 API 호출이 어차피 필요하고, BioStar 서버 자체를 안쓰겠다면 DB 암호화를 깰 필요도 없으니.. 그래도 일단 작업해본 김에 간단하게 기록삼아.

눈으로 보이다시피, &@~ 로 시작하면 암호화된 데이터이고, AES + PKCS7 패딩으로 이루어져있다.
BioStar 설치 폴더/util/enckey 에 BioStar.secure_communication.encryption_key 로 암호화를 하는데, 이 키를 그대로 쓰진 않고 여기다가 xor 및 시저 암호를 간단히 적용하여 key, iv 를 만들어낸다.
이 후 각 record 를 복호화하면 됨.

프로토콜 분석

Suprema 는 위에서 내가 사용한, BioStar 2 서버를 사용하지 않고도 단말기를 제어할 수 있게 Device SDK 란걸 제공한다.
관련 문서는 BioStar Device SDK 에서 확인할 수 있고, 샘플 코드와 Windows/Linux 각 32bit/64bit 라이브러리를 제공한다. (ARM은 없지만…)

위에서 얘기한, ‘장치에서 서버 연결’ 를 설정해두면 기기에서 서버의 tcp 포트로 소켓을 연결한다. 초기 키 교환 이후 요청은 AES로 암호화하여 주고받는다.

1. 서버는 연결되자마자 32B source_key 를 고정 키로 암호화하여 응답 반환
2. 장비는 source_key 를 해싱하여 key, iv 생성, 이 후 상호 통신 간엔 AES-256-CBC 로 암호화하여 통신
   • 평문 20B + 암호화 데이터{ 헤더 16B + Payload }

SDK 에 통신 프로토콜에 대한 구조는 없어서, SDK 없이 직접 구현은 좀 까다롭다.

그래도 최소 기능만 사용 기준으로 어찌저찌 거의 대부분 다 만든 것 같은데…
방금 새로 스캔한 지문이 이미 누군가에게 등록된 지문인지 확인할 방법이 없다ㅠ
이 기능 하나가 없어서 기껏 만든게 모두 도로묵...ㅠㅠㅠ

지문 template 분석

지문 검사를 내가 직접해줄 순 없을까? 싶기도 하고 이 쯤 오니 궁금해져서, 지문 template 데이터도 분석해봤다.
template은 지문 스캔 이미지를 일부 전처리한 후 융선과 특징점을 추출한 데이터로, 최대 384B 의 데이터를 base64 인코딩되어 있다.

설정상 ISO 나 ANSI378 이란 포맷도 있던데,, 현재 기본 값은 Suprema 포맷.

지문 이미지가 최대 288x320 로 만드는 듯 하고, 한 셀이 16px, 최대 18x20의 융선과 특징점으로 표현하고 있다. 세로는 20셀 고정에 가로는 14,16,18 등등 가변으로 사용하는 듯?

지문 원본 이미지는 회색 음영인 PGM 포맷이고, 설정에서 지문 - 이미지 표시 활성화시 단말 기기에서 바로 볼 수 있는 이미지이다.
이 raw 이미지는 스캔시 받을 수 있도록 API 구조에 있긴 한데, 실제로 이미지를 주진 않았던 같다. (이런식으로 API 가 뭔가 구멍이 하나씩 빠져있다..ㅠ) 난 SDK 구현 이용해서 가져옴.

웹이나 API 사용시 기본적으로 template 을 이미지로 변환한, 두번째 형태의 이미지를 준다.

template 구조를 분석하면 3번쨰 이미지를 자체적으로 생성할 수도 있음. 세부 구조 분석 결과는 생략.

분석한 구조를 바탕으로 자체 지문 매칭을 구현할 수 있을까,, 도 좀 고민해봤는데 쉽지도 않고 실제 작동과 차이도 발생할 것 같아서 일단 말았다ㅠㅜ
기껏 시간 투자했는데, 그냥 간단했던 API 방식으로 회귀하는 것으로...ㅠㅠㅠ

아직 만들진 않았는데, 자체 ERP 에 지문 등록 기능을 만들어두고 각자 직원이 스스로 직원 등록을 하게 진행할 예정이다.
보안 문제가 살짝 있을 순 있겠지만,, 이게 근태나 엄격한 시설 출입에 사용되는 것도 아니라서, 일단 괜찮을 듯?

Odroid 공홈에서 판매중인 와이파이 모듈
공홈에서 CF-813B 의 OEM이며, Realtek RTL8821CU chipset 을 사용한다고 나와있다.

공홈에서 파는거니 확실히 지원이 보장되겠지만,, 크기가 조금 크기도 하고 결정적으로..

처음 꽂은 후로 뺄때 분리가 되어버렸다.......ㅠㅠㅠㅠ

조금 큰 본체가 마음에 안들기도 해서 대체품을 찾아봤는데,
무선랜이 은근히 드라이버를 많이 가린데서 조금 고민이 되었다.

다른 애들도 작동을 안하진 않을 것 같지만,, 일단 가능한 동일 칩셋으로 찾아본 제품이 NEXT-653WBT 이거.

블루투스 등 스펙도 동일하고, 연결시 드라이버도 동일하게 잡히고 잘 작동한다.
최저가 기준 가격도 조금 더 저렴하고,, 크기도 작고..!!

Ubuntu 24 + Odroid N2+ 에서 테스트해봤고,
Ubuntu 24 + NanoPi RS3 에서도 별다른 드라이버 과정없이 연결하자마자 작동하는 것 확인.

Ubuntu 24 + Odroid N2+ 기준, 위 2개 상품은 8821c 칩셋이고, 이 드라이버가 커널 내장이라 정상 작동한다.
iptime A3000MINI 의 경우 8822b 이고, 해당 드라이버가 Odroid 공식 배포 Ubuntu 24 배포판에 들어 있긴 한데,,,
zstd 압축이 되어 있는데, 커널이 압축된 드라이버 옵션이 빠진 채로 빌드되어 있어 로드되지 않는다.

테스트는 안해봤지만,, 압축만 해제해주고 재부팅하면 될 것 같음

# 8821cu 는 커널 내장이라 안해줘도 됨
# unzstd --keep /lib/firmware/rtw88/rtw8821c_fw.bin.zst
# 8822b
unzstd --keep /lib/firmware/rtw88/rtw8822b_fw.bin.zst

들어가기에 앞서,
- 구매한 도서를 본인의 능력으로 직접 DRM을 해제한 경우는 국내법상 합법으로 알고 있습니다.
- 다른 사람이 도와주거나 대신 해제해준 경우 불법입니다.
- 구매가 아닌 대여 도서의 해제도 당연히 불법이겠죠?
이 글은 작업의 기록이지 세부 내용이나 방법은 다루지 않습니다.

솔직히 난 종이책이든 이북이든 책을 잘 읽지 않는다.
그렇지만, 우연히 지인의 이북 리더기를 보았는데 갖고 싶다는 생각이 들었다.
모델명은 물어보지 않았지만, 아마 오닉스 포크6 인 것 같은데,, 가볍고 생각보다 빠른 화면 전환...

그래서 어떤 제품이 있을까 뒤적이다가, 뜬금없이 epub drm 에 꽂혔다.
이북리더를 산들, drm 에 묶인 전자책을 전용 뷰어앱으로만 보고 싶진 않았거든.

옛날 옛적에 리디북스의 DRM 해제에 대한 방법과 코드가 공개된 적이 있었다.
블로그 글은 사이트가 날아간 것 같고, 깃헙은 남아있네 - https://github.com/disjukr/ridi-drm-remover

저분은 무슨 깡으로 저런걸 공개했는지 모르겠지만,, 나도 당시에 코드를 받아 한권 정도 재미로 풀어봤었다.
이게 생각이 나서, 나도 DRM을 풀어서 소장해야겠다.. 라는 이상한 의식의 흐름이랄까.
그래서 시작된, 이북리더 구매도 전에 EPUB DRM 부터 해제하기!

플랫폼마다 난이도는 천차만별일거라,, 일단은 EPUB 의 DRM 대해 공부해볼겸 만만하게 공공도서관의 전자책 대여 시스템을 타겟으로 삼았다. 물론 대여한 도서의 DRM 제거는 빼박 불법이겠지만,, DRM 기술에 대한 학습 목적으로...?
난 취미삼아 다른 서비스들 리버싱을 종종 해보는데, 그러면서 배우는게 꽤 많았던 것 같다.

그리고 미리 전자책 업체에 대한 변명을 해주자면,, 소프트웨어에서 창과 방패의 싸움에서는 절대적으로 창이 유리하다.
특히 전자책과 같이 소프트웨어와 컨텐츠가 사용자 기기로 내려받아지고, 로컬 기기에서 복호화를 해서 내용을 표시하는 경우엔 무조건 뚫릴 수 밖에 없다. (극단적으론 책 한장한장 다 사진 찍어서 만들면 그걸 어떻게 막을 것인가?)

그래서 기술 외적으로 사법의 힘을 빌려 처벌하거나, 최대한 귀찮게 만들어 효용 가치를 사라지게 하는 방법이 유효하다. OTT 서비스가 부상하면서 쉽게 VOD를 볼 수 있게 되자 웹하드나 토렌트가 상당히 죽은 것과 비슷하달까?
그러니 이렇게 뚫린다고 해서 그 기관이나 개발사를 괴롭히는 일은 없었으면 좋겠다..

가장 먼저 해볼 일은, 책을 구매하든 대출하든 전용 뷰어로 열어보는 일이다.
그래야 중간에서 컨텐츠를 훔치던가 복호화를 하던가 할 수 있으니까...
나쁜 업체, 하지만 내 입장에선 고마운 업체가 대충 만들면 중간 네트워크 패킷을 훔치는 것만으로 DRM 프리한 컨텐츠를 그대로 얻을 수 있을지도 모른다.

그러다보니, 훔쳐보지 못하게 하는 보안 기술 중에 SSL Pinning 이란 것도 있다. 이걸 적용하는 경우는 잘 없는데,, 좀 의외...
물론 창이 유리하다고 했지? 이런 것도 우회할 수 있다.
그래도 환경에 따라 우회가 상당히 제한되기도 하고 방법이 더 복잡해지기 때문에, 이런 조치만으로도 나같은 툴 키디의 공격으로부터 서비스를 보호할 수 있게 된다.
다른 OS에서 SSL pinning 을 우회활 방법을 만들어 뒀었기에 OS 를 바꿨는데, 다른 OS의 앱에선 pinning 이 안걸려 있어서 편하게 바로 스니핑이 가능했다.

얘들은 로그인 인증이 개판이라 이런건 좀 혼나도 될 것 같긴 한데,, 지금 중요한건 아니니 넘어가도록 하자.
주고 받는 패킷에 epub 주소가 있고, 그냥 다운받아 쓰고 있다. '어라? 그냥 저 epub 를 다운받아주기만 하면 되나?'

까비~
파일을 열어보니 신기하게 파일이 통째로 암호화된게 아니다. 뷰어에서도 책의 이름은 정상적으로 가져오더라.

EPUB 는 컨테이너로 zip 을 사용하고 있어서, 확장자만 zip 으로 바꾸면 압축파일처럼 내부 파일이 풀린다.
그 안에 책에 대한 정보나 이미지, 본문 텍스트 등이 있는 구조인데, 기본 정보 외에 폰트, 이미지, 텍스트는 모두 암호화된 상태였다.
도서를 한번 열람하면 앱 내부에 .epub 파일을 .zip 으로 저장하던데, 아쉽게도 암호화는 유지한 상태로 저장을 하고 있었다. 책을 열 때 마다 복호화하는 구조.

xml 구조인 메타 데이터 내에서 눈에 띄는 키워드로 검색해보니 EPUB 의 DRM 에 주로 사용되는 표준 암호화 방식이 있더라.

대충 정리하면 리소스는 각 aes 암호화가 되어 있으면서, 그 aes 키는 license 파일에 다른 키로 암호화된 상태로 저장되는 구조였다.
암호화 하는 다른 키는 구현하기 나름이겠지만, 내가 본 업체는 RSA 키로 암호화가 되어 있었다.

조금 특이한건, 서버에서 내려주는 epub 파일 자체는 키가 없어서 내가 복호화할 수 없는 license 파일이다. 대신 도서를 열 때 내 기기에 저장된 RSA 키 페어 인증서를 서버에 보내는데, 그 때 내 공개키로 암호화된 값을 가진 새 license 파일만 내려준다.
그러면 앱은 로컬에 저장된 epub 내의 license 파일을 서버에서 새로 내려준 파일로 덮어씌운채로 저장해둔다.

리소스 자체는 aes, 즉 대칭키로 암호화되어 있기 때문에, 라이선스 파일이 교체되지만, epub 리소스를 복호화 하기 위한 키 자체는 고정된 동일한 값이다. 어차피 한번만 복호화 키를 얻으면, 완전 복호화한채로 저장하면 되기 때문에 뭔들...

이제 남은건 2가지.
1. 뷰어 앱 혹은 기기에 저장된 개인키
2. 복호화 방식

개인키를 추출하는데 가장 오래걸렸는데,, 결국 내 기기에 설치된 뷰어 앱이 해당 개인키로 복호화를 하기 때문에, 어딘가엔 있다. 굳이 꺼낼 수 있는 방법이 마련되어 있지 않을 뿐. 어디에 있는지 모르기 때문에 찾는게 좀 귀찮다.
드물게 하드웨어에 키를 저장하고 사용하는 방식의 경우 키 추출이 불가한 경우도 있는데, 다행히 그렇진 않았다.(보통 잘 안쓴다.)
저장소 자체가 어디인지는 찾지 못한게 아쉽지만,,, 뷰어앱도 결국 복호화를 위해 비밀키를 메모리로 불러오기 때문에 그 과정에서 키를 가로채는게 가능하다.

내가 분석한 앱은 앱 자체는 하는 작업이 거의 없는 가벼운 앱이었고, DRM 프레임워크가 앱 용량의 대부분을 차지하고 있었다.
멀티플랫폼 지원용인지, OpenSSL 을 프레임워크 내에 내장하고 있더라.

시간이 조금 걸렸지만, 어쨋든 비밀키 추출 성공!
난 리버싱을 잘하는건 아니라서, 비효율적인 편법을 주로 사용한다. 상당한 노가다를 동반한다고 생각하면 됨.
위에서 서버에 보내는 내 기기 인증서의 키와 페어임도 확인했다.

참고로 복호화는 키가 틀려도 일단 복호화 자체는 문제없이 된다. 결과물이 쓰레기일 뿐...
그래서 키가 올바른 키인지 검증 과정이 따로 필요한데, 라이센스 파일의 encryption.device_key.key_check 값을 비밀키로 복호화하면 license 파일의 id 와 동일한 값이 튀어나온다. 이를 통해 올바른 키인지 확인할 수 있다.

조금 특이한건, 암호화 과정에서 보통 PKCS7 패딩을 많이 쓰는데,, ISO 10126 패딩인 것 같더라?
리버싱으로 복호화를 할 땐 기껏 키를 찾고 나면 iv와 패딩을 찾는데도 꽤나 시간을 쓰기도 한다. 이번엔 다행히 쉽게 해결함.

그 후에 찾은 복호화 방식은 비교적 간단했다.
encryption.content_key.encrypted_value 를 내 개인키로 복호화하면 32바이트 키가 나오고, 이를 이용해 리소스 파일들을 각각 복호화하면 된다.
기술적으론 암호화 키를 여러개 사용할 수도 있나본데, 어차피 하나만 쓰고 있으니 그런 경우는 무시.
먼저 압축한 후 암호화된 경우도 있으나 이 정보도 xml 에 기록되어 있으니 적절히 리소스에 따라 복호화 및 압축 해제해주기...

복호화 방식을 알고 비밀키가 있으니, 나머지 과정은 자동화할 수 있다.
대여/구매한 책의 라이선스 키를 받고, 암호화된 epub 를 다운받은 뒤 복호화까지 한방에 하는 스크립트 작성이 가능하단 의미.

drm 해제가 완료되면 평범한 epub 파일이 된다. epub 포매을 지원하는 어떠한 앱(나의 경우엔 애플 도서 앱)으로도 볼 수 있다.

근데 여긴 아쉽게도 내가 읽고 싶은 책이 없네.

그냥 poc 삼아, drm 구현의 공부 삼아 대출 도서로 진행해봤다.
실제론 이북으로 구매하고 그 구매한 책을 대상으로 사용할 예정인데, 업체마다 DRM의 구현 방법은 다 제각각이기 때문에, 완전 처음부터 다시 분석해야하고 방법이 완전 다를 가능성도 있다.
운 좋으면 같은 외주사가 개발했다거나,, 사용 기술이 비슷해서 날먹할 수도 있지만....

어쨋든 시도해보기 전엔 난이도를 알 수 없는데, 부디 내가 쉬운 이북 업체를 잘 찍기를 바라보며,,,
다른 서비스의 DRM 해제는 이북리더를 진짜 사게되면 진행해봐야겠다.

이북리더도 구매했겠다, 진짜 사용을 위해 다른 업체에서 진행해보았다.

얘들은 DRM 업체의 솔루션을 구매해서 사용하고 있던데, 이 시스템이 서버와 통신하는 방식이 조금 특이하다

처음 요청을 보내면 라이센스 서버의 인증서와 nonce 를 반환하고, 클라이언트는
1. random 16B 생성, key 로 사용
2. nonce+사용자아이디를 1번의 키로 암호화 = password
3. 1번의 키를 서버가 준 라이센스 서버의 인증서로 암호화 = KEK
4. 이를 서버로 다시 전송
하는 과정을 거친다.

아마 솔루션 자체가 HTTPS 가 대중화되지 않았던 과거에 만들어진 후 아직 그대로 사용하는게 아닐까 싶다.

또 이상한건, 위 업체처럼 기기의 비대칭키와 인증서를 생성하게 되는데, 이 키를 서버에서 생성해서 내려준다..ㅡㅡ;;
암호화된 pkcs8 로 내려주는데,, 이 암호도 요청에 포함이 되어 있고.............

비대칭키 쓸 때 대표적으로 하지 말라는 모델 아닌가,, CSR 같은건 왜 안쓰고.... (물론 위에 처음 뚫어본 업체도 그랬을 수도 있지만,, 확인해보지 않았다)
이런거 역시 옛날에 솔루션이 만들어졌다고 생각하면 클라이언트에서 키 만들기 어려웠던 시절도 있으니까, 일단은 그러려니......

여튼 그러고나면 얘들도 암호화된 .epub 파일과 license 파일을 내려받는다.
license 파일은 비슷한 듯 다른데, 어쨋든 기기의 비대칭키로 복호화할 수 있는 값을 가지고 있다.

얘들은 epub 자체도 자체 기술로 암호화되어 있고, 암호화를 풀면 내부 리소스 중 일부 데이터(주로 텍스트 위주)가 한번 더 암호화되어 있다. 겉 암호화는 풀어서 기기 내부에 저장하고 있으니, 이런 형태를 취했나 싶긴 한데.. 좀 이상하긴 함

아무튼 또다시 자세한건 생략. 이번엔 정당한 이용을 위해(?) 책을 구매하고, 구매한 책의 DRM을 해제하였다.

DRM이 해제되었기에 구매한 이북리더에서의 기본 리더 앱에서도 잘 열린다.

이 고생을 한 자기 합리화일지도 모르겠지만, 역시 기본 내장앱이 더 빠릿하고 쓰기 편한 것 같다ㅋㅋㅋ