삽질...

최근에 업무 변경이 있어 지난주까지 하던 일을 이관했다.
mobile SNS를 개발하는 일이었는데, 여튼 우찌우찌 동작은 하도록 해서 넘겨주었다.
어제 저녁에 나의 업무를 받은 동료가 테스트 중에 이상한 점이 있다고 도움을 요청했다.
내가 테스트 계정으로 사용하던 facebook의 id와 password로는 접속이 잘 되는데
자신이 만든 개인 계정으로는 접속이 되지 않는다는 거였다.
login process는 자체 AES with PKCS7Padding, Base64 encoding, Url encoding의 세 단계를 거친 결과를 가지고 서버에다가 요청을 하기 때문에 어느 단계에서 오류가 있는지를 찾아야 했다.

당장 필요한 것만 추가해두었던 URL encoder쪽에서 문제가 났겠거니라고 생각하고 퇴근을 해버렸다.
아침에 출근하자마자 Base64 encoding까지 거쳐서 나온 결과물을 봤더니만 / 가 있었다. 역시 URL encoding에서 /를 치환해주지 않아서 발생했구나라는 기쁜 생각으로 / -> %2F  해주는 코드를 추가한 후 자신만만하게 테스트를 했는데 ..
헉.. 같은 오류를 서버가 뱉어냈다.

이때부터는 난감했다. 나머지 두 단계의 경우 input이 들어갔을 때 나와야 되는 제대로 된 결과값을 모르기 때문에 어느 부분이 잘못되었는지 알 길이 없었다.

'DRM 담당자를 불러서 암호화 모듈을 봐달라고 할까?'
'사업자 기능이니깐 영국으로 메일을 보내서 당신네 서버가 이런 에러를 뱉아내고 있는데 뭐가 잘 못 된것 같소!!'
라고 메일을 보낼까...머리가 혼란해지기 시작했다.

자기 일 처리에도 야근을 해야하는 회사 특성상,
괜한 일로 다른 팀에 협조 요청하기도 쉽지 않고
영국 엔지니어에게 지금 상황 다 설명할 영어 편지 보내기도 만만찮고 해서 하나하나 따라가보기 시작했다.
왜 특별한 계정에 대해서만 로긴이 되지 않는 것인가를 찾다가
크...한 군데가 수상했다.
AES with PKCS7Padding 의 결과값을 나온 문자열을 result로 받아서
Base64 encoding ( result, strlen(result) ,... ) 로 넘기는데 암호화를 통한 결과값안에 0이 있는 경우
NULL로 인식해서 strlen의 결과가 택도 없이 작은 값을 넘겨 주고 있었다.
result의 실제 길이가 16인데 중간에 들어 있는 널로 인하여 strlen의 결과로 15가 들어왔다.
크..

정말 운이 없었다면 폰이 출시될때까지 발견되지 않고 나갈 수 있었던 문제인데
초기에 발견되어 천만 다행이다.