SKTelecom 의 불편한 DRM 이 너무 짜증나서 한번 분석이나 해 보자는 마음에 일단 파일을 비교해 보았습니다.
원본 MP3 와 DCF 파일의 헤더만 보았습니다.
두 파일의 차이를 지금 당장 알 수는 없습니다만 .. 보여 지는건 일단 변칙적인 헤더를 사용하고 있다는 것 입니다.
물론 저 Encryption-Method:SSE2000-Combined/64-32 라는 게 뭔지를 알아야 하겠습니다만..
분명 복잡한 디코딩을 해야 하는 알고리즘은 아닐 것 입니다 (단말기들의 성능이 그렇게 여유롭지 못할 것이라는 추측 하에 입니다).
MP3 야 이미 인코딩/디코딩 알고리즘이 다 공개되어 있는 상황이니 두 파일의 비교점만 찾아 보면 되겠지요.
01 0B 1D 이 3바이트가 DCF 의 해더 매직인듯 하고 ..
그 이후로 CR (0x0A) 로 헤더내용이 이어 지는군요 ..
개인적으로 저런 헤더는 정말 리소스 낭비라고 보여지는데 ... SKT 의 폐쇄적인 모습에서 보이는 오만함 같습니다.
제가 알고 싶은 것은 ..
암호화 메서드 , 그리고 SSeIID-1 , eCEK 가 가지는 SSKEY-1 이란 것. 각 메소드 들입니다.
변환속도(PC 에서) 및 디코딩 환경(단말)을 고려 해 보면 분명 복잡하진 못할것 으로 보입니다.
제가 즐겨 쓰는 LZSS 인코딩도 MP3 정도면 매우 시간이 걸리는 편 이니까요.
꼭 이놈의 DRM 알고리즘을 파헤쳐 보이겠다는 생각이 드는군요.
요즘들어 네이버 , SK , 2MB ... 다 마음에 안듭니다 -_-
원본 MP3 와 DCF 파일의 헤더만 보았습니다.
DCF 파일 내용
MP3 의 내용.
물론 저 Encryption-Method:SSE2000-Combined/64-32 라는 게 뭔지를 알아야 하겠습니다만..
분명 복잡한 디코딩을 해야 하는 알고리즘은 아닐 것 입니다 (단말기들의 성능이 그렇게 여유롭지 못할 것이라는 추측 하에 입니다).
MP3 야 이미 인코딩/디코딩 알고리즘이 다 공개되어 있는 상황이니 두 파일의 비교점만 찾아 보면 되겠지요.
01 0B 1D 이 3바이트가 DCF 의 해더 매직인듯 하고 ..
그 이후로 CR (0x0A) 로 헤더내용이 이어 지는군요 ..
개인적으로 저런 헤더는 정말 리소스 낭비라고 보여지는데 ... SKT 의 폐쇄적인 모습에서 보이는 오만함 같습니다.
제가 알고 싶은 것은 ..
암호화 메서드 , 그리고 SSeIID-1 , eCEK 가 가지는 SSKEY-1 이란 것. 각 메소드 들입니다.
변환속도(PC 에서) 및 디코딩 환경(단말)을 고려 해 보면 분명 복잡하진 못할것 으로 보입니다.
제가 즐겨 쓰는 LZSS 인코딩도 MP3 정도면 매우 시간이 걸리는 편 이니까요.
꼭 이놈의 DRM 알고리즘을 파헤쳐 보이겠다는 생각이 드는군요.
요즘들어 네이버 , SK , 2MB ... 다 마음에 안듭니다 -_-
