Owl-Networks Archive

막으려는 자와 뚫으려는 자 - 필터링

| 분류: 이런저런 이야기 | 최초 작성: 2011-06-01 00:34:04 |

웬만한 공유사이트들이나 웹하드 사이트들은 요즘 필터링 전쟁이 한창이다. 막으면 또 뚫고, 막으면 또 뚫고...

처음에는 파일 제목 필터링 같은 단순한 필터링으로 막던 애들이, 공유자들이 파일 이름 요상하게 변경해가면서 필터링을 피해가자(물론 필터링 허술하다고 저작권자들에게 웹하드들이 무더기로 고소당하는 사태까지 겪었으니까), 요즘은 파일 지문까지 생성해 가면서 이름 바꾸고 별짓 다 해도 인식할 수 있게 해놓고 있다. 덕분에, 파일 지문 뜨기 우회를 위해 압축파일에 패스워드를 걸어놓는가 하면, 한동안 머릿속에서 사라지다시피 했던 구석기 시대 압축 포맷들 - .ARJ 라던가, .LZH 같은 것들(.LZH는 요즘도 일본에선 사용되긴 하나 보던데..)이 등장하기도 한다. 한동안 웹하드 업계에 .EGG 파일이 넘쳐났던 이유 중에 하나가, EGG를 웹하드 등의 필터링 툴이 못 풀어냈기 때문이라나 뭐라나.

어제는, 무언가 다운로드 받으러 클럽박스에 갔더니, 어디서 듣도 보도 못했던 요상한 압축 포맷을 들고와서는 그걸로 압축을 풀라고 한다. 확장자를 보니 .ENC 라는 확장자다. 압축 푸는 툴도 일본어로 되어 있는 걸로 봐서 일본 쪽에서 나온 툴인 것 같은데, 파일 확장자로 봐서는 압축툴이라기보단 소스 파일을 사용자가 입력한 SEED(흔히 말하는 패스워드)를 사용해서 암호화하는 것 같다. 어찌 되었거나 필터링 툴이 압축을 못 푸는 이상 필터링은 불가능할 것이니, 소기의 성과는 충분히 거둔 셈이다. 물론 이것도 오래는 못 갈 거다. 막으려는 측에서도 분명히 무언가 대책을 세울 테니.

싸움 구경이 원래 재미있는 거라지만, 참 재미있는 광경이다.

필터링 전쟁을 보면서 얼핏 든 생각이지만, 파일 사이즈와 시간을 생각하지 않는다면, 꽤 유용할 것 같은 필터링 우회 방법이 있다. 바로 Base64를 이용하는 방법이다. 이건 이메일에 파일을 첨부할 때도 쓰이는데, 어떤 파일이건 이 규칙을 사용하여 변환하면 텍스트 파일이 된다. CD이미지건, 동영상 파일이건, 여기를 거치고 나면 모두 길다란 텍스트가 되어버리는 것이다.

3바이트를 읽어서 4바이트로 쓰는 특징 때문에 용량이 3분의 4배(약 1.33배)로 커지고, 다시 ZIP 등으로 압축한다고 해도 원래 파일을 압축하는 것보다는 조금 더 큰 파일이 만들어진다. (변환 시간의 경우, Perl 의 MIME::Base64 모듈을 제대로 사용한 결과 인코드/디코드 모두 200메가바이트 정도 되는 파일에서 1분도 채 걸리지 않았습니다. 2012/04/26 수정. 테스트용 스크립트(Base64 인코딩/디코딩): 다운로드 (크기: 1040Byte)) 그러나 애초에 바이너리 파일이 전혀 형태와 크기가 다른 텍스트 파일이 되어버리는데, 이게 필터링이 될 리가 없지.

최악의 경우, 일정 타이밍마다 쓰레기 문자를 끼워넣어두거나, 64개의 문자 대응 배열을 일정한 규칙에 따라 변경할 수도 있겠다. 다운로드 후에 원상태로 디코딩할 때는 해당 쓰레기 문자를 삭제하면서 디코딩하거나, 변경된 규칙에 따라서 디코딩하면 원래의 파일을 얻어내는 데는 문제가 없다. 그러나 자동 필터링 툴 따위가 그런 규칙을 알고 있을 리가 없으니, 자동으로 필터링한다는 것은 불가능에 가깝다. 사람이 일일이 돌아다니면서 블럭을 먹인다면 모르지만..

☞ 태그: 필터링, Base64, .ENC,

☞ 트랙백 접수 모듈이 설치되지 않았습니다.

☞ 덧글이 3 개 있고, 트랙백이 없습니다.

덧글을 남기시려면 여기를 클릭하십시오.

□ 저니리 님께서 2011-06-08 15:37:42 에 작성해주셨습니다.

ENC파일의 구조야 깊이 생각할 것도 없이 CBC-모드 block cipher(AES나 DES와 같은 녀석)로 파일을 암호화 시킨 것임이 틀림이 없을 것이고, 비밀키는 사용자가 입력한 패스워드로부터 PKCS#5에 있는 PBKDF(password-based key derivation function)을 통해 128비트의 안전한 비밀키를 생성하기 위한 것이지. 기본적으로 block cipher는 검색이 안되는 암호문을 생성하기 때문에 검색은 원천적으로 불가능하지. 속도를 위해서 RC5와 같은 steam cipher도 사용될 수 있지만 뭐...

하지만 Base64인코딩은 기본적으로 바이너리 데이터를 사람이 눈으로 인식할 수 있는 텍스트 포멧으로 바꾸기위해서 사용하는 인코딩 방식으로 검색이 아주아주! 훌륭하게 된다네. 왓슨군. 그리고 무슨 짓을 했는지 모르지만, base64인코딩은 block cipher에 비해서 매우매우매우매우(사실 비교조차 해서는 안되는 속도로) 빠르게 동작하기 때문에 한시간 넘게 인코딩이 걸렸다는 것은 자네가 뭔가 잘못한거라는 걸 반증하는 것일세.

⇒ 부엉이 님께서 2011-06-09 09:54:12 에 답글을 작성하셨습니다.

하나는 당연히 Perl 인터널 모듈의 MIME::Base64 쓴 거지. 그리고 다른 하나는 Base64 구현 Perl 스크립트 알코딩이고. 바로 위에 사용한 스크립트 링크 걸려있으니 한번 소스 열어보던가. 나도 당연히 순식간에 변환될 거라고 생각했는데, 그게 아니더라고.

덧붙이자면, 필터링에서의 검색은 옛날 같으면 확장자 체크만 하고 넘어갔겠지만, 요즘이라고 하더라도 일단 파일 형식 체크부터 하고 들어가기 때문에, 파일 형식이 바이너리가 아닌 텍스트 형식이라면 필터링에 예외가 걸리겠지. 이쯤 되면 사용할 만 하지 않을까.

□ 알이된닭 님께서 2011-07-13 10:55:26 에 작성해주셨습니다.

우연히 들리게 되었다가 흥미있는 글을 읽게 되었네요.
저는 < 필터링 >이라고 하는 것 자체에 의문이 있습니다.
웹이라고 하는 공간이다 보니 < 저작권 >을 보호하기 위해서 < 필터링 >을 하는 것인데요. 검색을 막아서 넓게 퍼지는 것을 막겠다. 하는 의도는 충분히 이해를 합니다.

다만, 특정한 어떤 것의 < 저작권 >을 보호한다는 취지에서 그와 무관한 많은 것까지 검색에 제한을 받게 되는 것이 문제죠.
< 저작권 >신청이 되었다고 해서 보호받고 그렇지 않은 것은 공유를 해도 된다고 하는 것은 아니지만, < 저작권 > 신청의 것들이 점점 늘어서 그런지 너무 많은 것들에 대해서 검색어 제한이 걸립니다.

이런 웹의 필터링도 게임 속의 필터링처럼 변화가 되어서 또 다른 < 외계어 >를 낳게 될 것 같더군요. 뭐랄까 이런 느낌은 꼭 < 벼룩 > 잡자고, 초가삼간 불지르는 것 같아서요. < 저작권 >중요한 것이긴 하나, 단순히 < 필터링 >을 막는다고 해서는 근본적인 해결이 되는 것이 없으니 시대의 흐름에 맞추어서 현재의 흐름에 맞는 형태에 대한 대책으로 발전을 하면 좋겠더군요.

⇒ 부엉이 님께서 2011-07-14 00:12:47 에 답글을 작성하셨습니다.

현재 이루어지고 있는 필터링 자체는, 어떻게 보면 업계가 자발적으로 진행하게 된 것이라기보다는, 공권력의 저작권 침해 방조 수사 압박과 저작권 관련 단체의 소송제기에 의해 떠밀리다시피 도입된 측면이 없지 않습니다.

어찌 보면 현 시점에서 검색어 기반의 필터링은, 실제로 그것이 저작권 침해를 막을 수 있을지는 의문시되는 반면, 그에 부수하여 너무 심한 불편을 낳고 있다는 생각이 듭니다. 애초에 설계를 잘못 한 거죠. 필터링 될 필요가 없는 컨텐츠들까지 과잉 필터링이 되고 있는 현실.. (게다가 잘 뚫리죠. 사실 검색어 필터링, 몇몇 업체들의 경우 뻥뻥 뚫리고 있는 게 현실 아닌가요? 가끔은 업체가 검색어 필터링 뚫으라고 방조하는 게 아닌가 싶은 생각이 들 때도 있을 정도입니다.)

이미 업로드 된 파일을 분석해서 저작권 파일 유무를 가리는, 일종의 디지털 지문 기술이 필터링에 도입된 상태이기 때문에, 사실 필요 없는 기술이라고도 할 수 있을 것입니다. 그럼에도 불구하고, 아마 업체들이 검색어 필터링을 없애진 않을 겁니다. 사실은 쓸모 없는 기술임에도 불구하고, 그것을 없앰으로써 저작권 침해 보호 수준을 약화시켰다는 저작권 관련 단체의 공세를 당해낼 재간이 없기 때문이죠.

□ Kitty 님께서 2012-04-24 17:55:15 에 작성해주셨습니다.

검색하다가 우연히 글을 읽게 되었습니다.
350메가 인코딩이 한시간 걸린다......
뭔가 잘못 작성하신 거라고 확신합니당.
Base64는 기본적인 몇 가지 비트 연산만 사용하기 때문에
파일을 읽고 쓰는 속도보다 절대로 느릴 수가 없습니다.
혹시 전체를 메모리상에서 인코딩 하면서 strcat() 같은 것을
잘못 사용하면 모를까, streaming으로 read/encode/write 바로
진행한다면 2분 안쪽으로 끝날 것 같은데요.
설마 2011년에 386 컴퓨터를 사용하고 계시진 않을 테고......

⇒ 부엉이 님께서 2012-04-26 08:12:09 에 답글을 작성하셨습니다.

프로그램을 다시 짜서 테스트를 해 봤는데, 버전을 바꾸고 모듈을 새로 써서 그런지, 아니면 기존의 코드에 어떤 문제가 있었는지, 307메가바이트 정도 되는 ISO 파일을 인코드/디코드 하는 데 1분도 채 걸리지 않는군요. 파일을 통째로 메모리에 올리는 방식에 문제가 있었을 가능성이 크네요. 차제에 글 좀 고쳐놔야겠습니다. 감사합니다.

[489] < [398] [394] [392] [391] [390] ... [388] ... [387] [386] [372] [366] [361] > [19]