리버스 엔지니어링을 하는 과정들... 3/n

2번째 글을 적고 시간이 많이 지나 버렸네요.

 

지난 번에는 대략적인 HW 구성을 봤습니다.

이번에는 실질적인 통신 분석을 진행 해봅니다.

 

다행히도(?) 컨텍터 부분에 Tx, Rx 라는 명칭이 있어서 시리얼 통신이라는 것을 알 수 있습니다.

컨텍터와 CPU 사이에 다른 신호 변환 부품이 없기 때문에 TTL Level 의 시리얼 통신으로 확인이 됩니다.

 

아래 사진과 같은 방식으로 오고 가는 통신을 가로채서 어떻게, 그리고 어떤 데이터를 주고 받는지 확인을 합니다.

시리얼 통신은 Tx 는 송신만, Rx 는 수신만 합니다.

따라서 저 통신을 모두 가로채기 위해서는 2개의 USB 시리얼 컨버터를 이용해서 Rx 부분에 모두 연결을 해서  가로채는 방식을 써야 합니다.

 

 

적당히 배선을 연결합니다.

보통 구하기 쉬운 USB 시리얼 1개 제품을 사용해도 되지만 저는 4개까지 사용 가능한 제품을 사용했습니다.

사실 이 3번째 글이 늦어진 이유 중에 하나가 저 보드를 어디에 뒀는지 못 찾은게 가장 큰 이유 입니다.

제가 회사에서 팀원에게 시험해보라고 빌려 줬더라구요.

 

이제 차에 연결을 해서 통신을 수집해 봅니다.

시리얼 통신용 분석 프로그램은 개인적으로 만들어서 사용하는 Ya~G 라는 툴을 사용합니다.

 

차에 연결하니 데이터가 수집이 됩니다.

 

통신 속도를 알아내는 가장 쉬운 방법은 오실로스코프를 이용해서 파형을 측정하는 거죠. 

파형의 신호 크기를 역산하면 통신 속도를 알아 낼 수 있습니다.

제 개인용 오실로스코프를 회사에 두고 와서 단순한 방식으로 접근을 해봅니다.

 

보통 사용하는게 저렇게 파는 제품들은 보통 9600, 19200, 115200 정도 입니다. 38400이나 57600등은 잘 사용을 안하죠.

 

속도에 따라 수집되는 데이터가 깨져서도 나오기 때문에 이것이 정상 데이터인지 아닌지는 스코프가 없다면 약간의 노력이 추가로 필요합니다.

우선 3개의 속도를 가지고 수신을 해보면서 덜 깨지는 데이터가 있는지를 봅니다.

 

예를 들면 아래 그림에서 보면 앞 부분에 00등이 많이 보이는 데이터가 115200일 경우, 아래 다른 코드가 많이 보이는 것은 19200 일 때입니다.

 

 

속도가 115200으로 보고 분석을 진행합니다.

 

이제 수집된 데이터에서 눈으로 보이는 패턴을 찾습니다. 55 AA 라는 것들이 규칙적으로 보입니다.

 

이 55 AA 라는 부분은 그냥 속도같은 데이터일수도, 안에서 사용된 명령일수도 있습니다.

그러나 다른 시각으로 보면 이 값이 중요한 값이라는 감이 오게 됩니다.

hex 코드로 55 AA 는 바이너리로 0101 0101 10101010 으로 각각 1과 0이 번갈아가며 나오는 코드입니다.

이 55 AA 가 통신 패킷의 시작일 수 도, 중간일 수 도, 끝 일수도 있겠지요.

 

이제 이 55 AA 라는 데이터를 기준으로 가지고 더 분석을 진행합니다.

 

 

55 AA 는 빠지지 않고 들어가 있네요.

 

이제 통신으로 수집된 것을 가지고 55 AA를 시작하도록 정리를 해봅니다.

 

 

 

 

이렇게 정리를 하니 어떤 규칙들이 눈에 들어옵니다.

1. 모두 55 AA로 시작합니다.

2. 한번에 수신되는 데이터 길이가 모두 같습니다.

3. 5번째 값은 계속 증가를 하므로 통신을 보낼때 마다 증가시키는 Count 라는 것을 알 수 있습니다. 4번째도 Count 에 포함이 되는지는 확인이 필요 하네요.

5. Count 값이 일관성 있게 증가를 하는 것으로 봐서 현재 수집된 패킷들이 모두 정상적인 것으로 보이네요.

6. 마지막에 어떤 숫자들이 랜덤처럼 보이는데 패킷이 유효한지를 확인하는 체크썸으로 보입니다.

체크섬 앞에 숫자는 00으로 유지되다가 3c 등으로 변경이 되는 것으로 보아 체크섬과는 관련이 없어 보입니다.

7. 3번째 29 가 뜻하는 것은 길이로 보입니다. 0x29 는 41 입니다. count 부터~ 체크섬 앞까지가 41바이트네요.

8. 디스플레이 모듈과 통신 모듈 모두 연결을 했지만 통신 모듈이 디스플레이 모듈에 전송하는 것만 보입니다.

9. 통신 모듈에서는 1초에 2번 패킷을 송신합니다. 500ms 간격으로.

 

이제 정말 이 패킷이 유효한 것인지를 확인해야합니다. 저 체크섬이 어떻게 계산되는 것인지를 찾아야하는 거죠.

 

55 AA 29 00 0E 90 02 00 35 07 32 01 63 00 00 40 00 8D 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 08 00 00 00 06 00 00 00 00 00 1C 

 

이 데이터는 어떻게 해서 마지막에 1C 라는 것이 나오는지를 찾아야 합니다.

이 기능을 위해 제가 사용 중인 Ya~G 에 포함된 체크섬 계산 기능을 사용합니다.

 

 

 

 

아~ 29 부터 체크섬 앞에 까지를 각각 XOR 연산을 한 값이라는 것을 알 수 있습니다.

 

즉 55 AA 로 시작을 하고 데이터 길이를 포함하고 있으면서 마지막은 XOR 를 한 체크섬을 사용한다는 거죠.

 

이제 패킷의 외형은 파악이 되었습니다.

 

남은 것은 내부의 각각이 어떤 값들인지를 찾는 것이죠.

 

주행을 한 기록을 보니 8번째가 속도값입니다.  9-10번째가 RPM 값입니다.

 

그리고 RPM 과 속도가 0이 되면 10초 정도만 기다렸다가 더 이상 패킷을 송신하지 않는다는 것도 확인이 됩니다.

속도나 RPM이 증가를 해도 더 이상 데이터를 송신하지 않습니다.

 

이제 상황을 정리해보면, 

1. 특별한 조작이 있지 않는 이상 통신 모듈이 디스플레이모듈에게데이터를 500ms 간격으로 송신을 한다.

2. 데이터 길이는 고정이다.

3. 속도와 RPM 이 0이면 10초간만 유지하다가 더 이상 통신을 보내지 않는다.

 

이 외에도 전압으로 보이는 부분이 발견되었으나 별 의미는 없을것 같고요. 제가 필요로 하는 부분은 속도와 RPM이라 필요한 부분은 다 찾은 것으로 보입니다.

 

이제 대략적으로 분석된 기능을 기반으로 기능을 모의 할 SW를 만들어 정상적으로 동작이 되는지를 확인 해봐야 합니다.

 

 

Ya~G 라는 툴에 플러그인을 만들어 모의 데이터를 전송하도록 만듭니다.

 

배선을 변경해서 노트북에서 수신을 하는게 아니라 송신을 하도록 수정합니다.

Ya~G에서 모의 데이터를 보내봅니다.

 

동작을 안합니다.

 

뭐가 잘 못 되었을까???

 

다시 차에 연결을 해봐도 동작을 안합니다.???

배선이 잘 못 되었나?

뭐가 잘 못 되었지???

 

하루 종일 붙잡고 원인을 찾다보니.... 

 

 

디스플레이 보드 CPU의 클럭 부품 (오실레이터)에 납이 한덩어리 떨어져있는게 보입니다.

언제 저게 저렇게 되었지?? 배선 납땜 할 때는 멀쩡했는데...

 

집에는 인두기와 납 뿐이라 깔끔하게 제거를 할만한게 없는 상태입니다.

인두기로 적당히 제거를 해봤는데, 안되네요. 

저 모양이 되면서 부품이 나간게 있는거 같습니다.

 

연휴 끝나면 회사에서 살릴 수 있는지 봐야 할 것 같습니다.