Tag Archives: featured

KT 무선 공유기 커스텀 펌웨어 개발기

이번에 아는 사람에게서 남는 KT 공유기를 받았습니다.

 

딱히 쓸데는 없고 해서 분해해 보았는데, 생각보다 사양이 좋습니다.

이 기기가 그냥 통신사 공유기로 남는것은 아깝다고 생각하여 한번 해킹을 시도해 보았습니다.

 

 

모델명은 DW02-412H 으로 기가인터넷 가입 시 같이 주는 공유기인것 같네요.

IMG_20180106_010051

외형은 별 볼일 없는 평범한 공유기입니다.

 

2018-01-06 01_40_22-GIGA HomeHub

공유기의 주소로 로그인을 해 보면 재미없는 kt 인터페이스가 우리를 반깁니다.

 

2018-01-06 01_42_01-GIGA HomeHub

할 수 있는것도 거의 없습니다.

이제 이 공유기에게 새로운 힘을 줘 봅시다.

IMG_20180106_010738

우선 뒷면을 봅시다.

딱 봐도 고무 밑에 나사가 있게 생겼군요

 

IMG_20180106_010752

고무패킹을 떼고 나사를 풀어줍니다.

 

IMG_20180106_010819

뚜껑을 여니 기판이 보이네요.

 

QCA9557 칩셋과 ESMT사의 1기가비트(128메가바이트) 메모리 모듈이 눈에 띕니다.

해당 칩셋은 720Mhz의 MIPS기반 CPU를 사용합니다.

 

720Mhz CPU에 128MB 램, 128MB 낸드면 공유기로 살기에는 좀 아깝죠.

저가형 iptime 공유기들은 32메가 램에 8메가 낸드 장착 이런것도 흔합니다.

 

가장자리에 수상한 핀들이 보이네요.

보통 이런 핀들이 직렬 연결을 위해 쓰입니다.

전압을 측정하여 각각의 핀이 무슨 핀인지 알아봅니다.

 

어려운거 할필요 없이 전압계 하나면 충분합니다…

IMG_20180106_011946

가장 아래 핀은 3.3v 나오네요. VCC입니다.

 

IMG_20180106_012021

바로 위에 핀은 전압이 계속 바뀌는걸 보니 TX인듯 합니다.

 

맨끝에 핀은 0볼트 나오니 GND이고 중간에 끼인것이 RX이겠죠

 

 

IMG_20180106_012330

정리되었으니 USB 직렬 컨트롤러를 이용하여 컴퓨터와 연결합니다.

 

2018-01-06 01_27_42-COM4 - PuTTY

PuTTY를 쓰니 연결이 되긴 된것 같은데.. baudrate가 틀린지 글자가 깨집니다.

주로쓰는 baudrate인 57600, 115200 등을 적용해서 확인합니다.

 

2018-01-06 01_29_44-COM4 - PuTTY

115200이였네요

이제 부트로더와 콘솔에 접근할 수 있습니다.

uboot를 사용하고 Atheros 사의 ap135 SoC 기반인 것을 알 수 있습니다.

 

 

2018-01-06 01_58_03-COM4 - PuTTY

 

부팅이 완료되니 콘솔로 로그인이 가능하네요. 하지만 알려진 비밀번호를 다 대입해봐도 로그인이 되지는 않습니다.

 

우선 다른 작업에 들어가기 전에 펌웨어를 덤프합니다.

 

2018-01-06 17_47_46-COM4 - PuTTY

일단 bootinfo 명령어가 있으니 시스템 이미지의 정보는 알 수 있습니다.

낸드에 저장된 주소, 사이즈까지 다 알려주니 작업하기 좋네요

 

 

그런데 nand의 정보를 컴퓨터로 마땅히 가져올 방법이 없네요. 부트로더가 tftp 업로드를 지원하지 않습니다.

어쩔수없이 nand의 정보를 터미널에 출력한 다음 수동으로 헥사 파일로 변환해야겠습니다.

 

리눅스를 사용할 때가 왔군요.

 

Screenshot-manatails@W230SS: ~-1

다행히 md 명령어가 있어 시리얼 콘솔로 낸드의 내용을 출력할 수가 있습니다.

 

이를 저장한다음 파이썬 스크립트를 사용하여 바이너리로 바꾸어 줍니다.

Screenshot-manatails@W230SS: ~-Desktop

 

Screenshot-wxHexEditor 0.23 Beta for Linux

이렇게 펌웨어 덤프가 완료되었습니다. 이제 공유기가 벽돌되기라도 하면 이 덤프 파일을 사용해서 원 상태로 복구하는것이 가능합니다.

Screenshot-manatails@W230SS: ~-Desktop-1

binwalk 로 lzma 압축된 시스템 파일을 확인합니다.

0x44 까지는 헤더부분인것 같네요

 

 

Screenshot-manatails@W230SS: ~-Desktop-2

헤더부분을 제거하고 LZMA 압축을 푼 후에 다시 바이너리를 확인합니다.

커널과 루트 파일시스템이 보이기 시작하네요

 

 

Screenshot-manatails@W230SS: ~-Desktop-_ollehfirmware.extracted-1

Unsquashfs를 사용하여 파일시스템을 봅니다…만 파일을 읽을수가 없다네요?

아마 비표준 squashfs를 사용하는 듯 합니다.

그래도 다행히 이런 임베디드 제조사들이 쓰는 비표준 squashfs 규격을 모아놓은 sasquatch가 있습니다.

 

Screenshot-manatails@W230SS: ~-Desktop-_ollehfirmware.extracted

이제 파일시스템의 내용도 다 볼 수 있습니다.

하지만 여기에 시스템의 암호는 없네요. 메모리 어딘가에 감추어져 있는 모양입니다.

 

 

공유기를 싱글유저 모드로 부팅해봅시다.

 

먼저 부팅 이미지를 메모리에 로드 한 뒤 setenv로 커널 파라미터를 수정하고 부팅하면 됩니다.

 

2018-01-09 21_10_47-COM3 - PuTTY

rc를 진행하여 시스템을 마저 준비시키면 passwd 파일을 열 수 있습니다.

섀도 형식으로 되어있네요

 

섀도 파일의 형식은 $Hashid $Salt $Hash value 로 되어있는데

위 파일의 해쉬 형식은 다음 표와 같군요

passwd-5

MD5-crypt 를 사용하여 솔트 없이 암호화되었으므로 어렵지 않게 비밀번호를 알아낼 수 있습니다.

 

2018-01-09-21_23_51-C__Windows_system32_cmd.exe_

올레 공유기의 관리자 비밀번호는 ********였습니다. (KT측 요청으로 마스킹 처리 합니다.)

 

올레 개발자가 이 글을 보고 있다면 화들짝 놀라면서 보안 업데이트를 준비하겠죠

 

2018-01-09 21_32_05-COM3 - PuTTY

관리자 로그인 성공!

 

슬슬 여기에 설치할 새로운 펌웨어를 준비해 볼 시간입니다.

 

Screenshot-manatails@home-linux: ~

OpenWRT는 공유기 등에 설치를 위한 리눅스 배포판의 일종입니다.

 

Screenshot-manatails@home-linux: ~-openwrt-1

필요한 모듈들도 다 준비하고

 

Screenshot-manatails@home-linux: ~-openwrt-3

배포판에서 기본 설정을 가져옵니다.

 

Screenshot-manatails@home-linux: ~-openwrt-4

보드 설정을 들어갑니다.

이 공유기의 기반이 되는 AP135 레퍼런스 보드를 위한 프리셋이 있긴 하네요

선택해줍니다.

이후에 알아낸 일이긴 하지만 AP136-010에 내장 스위치 관련 커널 설정이 들어가있어서 그걸 사용하는게 더 지름길입니다…

 

Screenshot-manatails@home-linux: ~-openwrt-5

이것저것 컴파일을 거쳐

 

Screenshot-manatails@home-linux: ~-openwrt-6

드디어 완료되었군요

 

부트로더의 tftpboot을 이용해서 새로운 펌웨어를 올려 봅시다.

 

2018-01-08 18_53_34-Tftpd64 by Ph. Jounin

 

부트로더에서 tftp 접속 주소를 알 수 있으 니 부트로더의 환경변수를 보고 그에 맞게 서버를 열면 됩니다.

 

2018-01-08 19_42_44-COM3 - PuTTY

 

그리고 tftp로 펌웨어를 메모리에 올리고 부팅을 시도했는데 체크섬 문제로 실패했네요

 

그러고보니 올레 펌웨어의 데이터 부분이 0x44부터 시작했었죠.

원래 uboot의 헤더 크기는 0x40일텐데…?

 

uboot의 소스코드를 확인해 보았습니다.

2018-01-08 20_37_12-u-boot_image.h at master · EmcraftSystems_u-boot · GitHub

펌웨어 파일의 형식도 확인합니다.

 

2018-01-08 20_49_11-HxD - [C__Users_sub2_Downloads_tftpd_0600A8C0.img]

그림으로 대충 이렇게 나타낼 수 있겠네요

 

 

그리고 올레 펌웨어의 헤더부분을 봅시다.

2018-01-08 20_48_28-HxD - [C__Users_sub2_Downloads_tftpd_ollehfirmware.bin]

중간에 00 02 04 00 이란 이상한 값이 헤더에 포함되어있네요. 중요한 값 같지는 않고 매직넘버의 연장같네요.

 

그래서 원래 헤더를 추출하여 해당 값을 더한 후 다시 다시 CRC를 계산하여 새로운 헤더를 만들어주는 스크립트를 만들어 보았습니다.

Screenshot-manatails@linux16: ~-1

대충 쉘스크립트를 짜고

 

Screenshot-manatails@linux16: ~-2

파일에 헤더를 새로쓰는 처리를 하고

 

2018-01-19 22_36_47-COM3 - PuTTY

커널로 부팅하는데 성공했습니다.

 

2018-01-19 22_38_05-COM3 - PuTTY

하지만 이내 불만을 토로하는군요.

SPI로 작동하는 NOR 플래쉬 메모리를 인식하지 못합니다.

 

기판을 들여다봅시다.

IMG_20180119_224034

ESMT 사의 F25L16PA라는 메모리를 사용중이네요

 

2018-01-19 23_03_50-Microsoft Word - F25L32PA.doc - F25L32P.pdf

데이터시트를 참조하여

 

2018-01-19 23_04_57-manatails@home-linux_ ~_openwrt

커널 NOR 플래쉬 드라이버에 해당 칩셋이 인식될수 있게 칩ID, 섹터크기와 정보를 입력해줍니다.

 

무선 관련 설정 등이 저장되는 ART영역이 NOR플래쉬에 탑재되어있기 때문에 해당 작업이 필요합니다.

 

 

2018-01-08 21_42_38-COM3 - PuTTY

우선 부팅에 성공했습니다. 지금은 initramfs 이미지를 사용하였기 때문에 NAND 플래쉬는 사용하지 않습니다.

NAND도 일단 ECC오류를 발생하는 것을 보아 커널 수정이 필요해 보입니다.

 

Screenshot-manatails@home-linux: ~-openwrt-7

우선 이미지에서 기본 무선 설정을 활성화시킵니다.

 

 

일단 무선 연결로 설정창은 잘 뜨나 유선 연결이 되지 않네요.

아마 스위치 설정이 잘못된것 같습니다.

 

IMG_20180119_234522

스위치 칩셋은 QCA8337(AR8337)칩셋을 사용중이며 위 사진과 같이 포트가 구성되어 있습니다.

 

저는 VLAN tagging을 사용하여 LAN과 WAN 포트를 분리했습니다.

switch

그림으로 나타내면 이쯤 되겠네요.

스위치에서 tagging을 이용하여 WAN 과 LAN 포트를 CPU 포트에 연결합니다.

WAN은 eth0.2 LAN은 eth0.1으로 사용하게 됩니다.

 

2018-01-19 23_22_56-manatails@home-linux_ ~_openwrt

위에서 구상한대로 새로 스위치 설정 스크립트를 맞춰줍니다.

 

fae925c2e64fcd010a5f9963d767f6f3

유선 인터넷 연결도 성공하였습니다.

 

이제 다 된건가 생각했었는데… 생각해보니 와이파이가 2.4G만 잡히고 5G가 안잡히네요

 

2018-01-20 00_17_17-COM3 - PuTTY

커널 로그를 보니 5Ghz 칩셋 드라이버인 ath10k_pci가 오류를 내고 있었습니다.

캘리브레이션 정보를 불러오기 실패했네요.

시작에서 잠시 언급했었지만, NOR 플래쉬에 저장되는 정보 중 하나가 이 5Ghz 칩셋의 캘리브레이션 데이터입니다.

 

2018-01-20 00_19_36-manatails@home-linux_ ~_openwrt

NOR 플래쉬의 ART 영역에서 데이터를 추출해서 적용해주는 코드를 추가해줍니다.

 

 

이제 대충 모든 기능은 다 활성화되었고, 배포 가능한 펌웨어를 만들기 위해서 NAND를 활성화시켜 봅시다.

2018-01-20 01_01_34-COM3 - PuTTY

순정상태에서는 ECC오류때문에 NAND읽기가 불가능합니다.

 

사실 이부분이 시간을 가장 많이 썼던 부분이긴 한데,  실패한 시도를 다 생략하니 결국은 몇 줄의 글로 요약되는게 슬프군요.

 

관련 메일링 리스트 정독하고 다른 공유기 소스참조 등 별 시도를 다 했지만 소용이 없었고…

 

커널의 NAND 드라이버가 자동으로 ECC를 활성화 해 주지 않던게 문제였습니다.

 

Screenshot-manatails@home-linux: ~-openwrt-8

커널 수정으로 해결하였습니다.

 

 

자 이제 실제로 설치가 가능한 이미지를 만들기 위해 플래쉬 영역에 대한 구상을 해 봅시다.

기존의 플래쉬 사용은 다음과 같습니다.

 

nand

환경설정은 NOR 플래쉬의 200kb 남짓한 공간에 저장되고

128MB의 NAND 플래쉬는 펌웨어와 백업펌웨어가 차지하는 18MB를 제외한 공간이 전부 빈 공간이였습니다.

이럴거면 128메가짜리를 왜 단건지도 잘 모르겠네요.

nand2

이제 새로운 이미지에서는 뒤에 여분의 공간을 하드디스크처럼 활용하여 프로그램을 설치할 수 있도록 하였습니다.

데이터영역의 포맷은 보통 NAND에서 많이 쓰는 squashfs+jffs2로 할려했으나 그렇게 할 시 96MB에서는 오버레이 마운트 시간이 오래걸려 단일 jffs2만 사용하기로 하였습니다.

 

 

2018-01-20 01_06_00-COM3 - PuTTY

이제 깔끔하게 마운트가 되고 구성이 완료되었습니다.

 

설정이나 설치한 프로그램 등은 전부 NAND에 저장되게 됩니다.

 

 

2018-01-20 15_34_19-OpenWrt - Overview - LuCI

설정 인터페이스

 

2018-01-20 15_48_09-NVIDIA GeForce Overlay

토렌트 서버

 

2018-01-20 15_55_27-phpinfo()

PHP가 적용된 웹서버

 

 

이제 올레 공유기는 라즈베리 파이와 같은 사실상 작은 리눅스 컴퓨터라고 보시면 됩니다.

opkg를 이용해 원하는 프로그램을 설치할 수 있고 위의 사진과 같이 웹서버, FTP서버 혹은 토렌트 서버 등 활용성이 무궁무진합니다.

별볼일없던 공유기가 작은 서버가 된 것입니다.

 

iptime과 같은 국내 공유기들은 개발진들의 부재로 이런 커스텀 펌웨어가 거의 없는데, 앞으로 국내산 공유기에도 이런 개발들이 활발히 이루어지길 희망합니다.

장단점이 있긴 하지만 고사양 공유기들이 순정 펌웨어만으로 살아가는것은 자원의 낭비라고 생각합니다.

 

혹시 동일 모델의 올레 공유기를 가지고 있으신 분들을 위해서, 블로그에 커펌 적용법을 올려 놓겠습니다.

 

IMG_20180120_161004

 

매너티는 최고 존엄입니다.

Hacking Pokemon 6th gen Mystery gift server

While receiving the Hoopa gift from the 18th Pokemon movie series, I suddenly felt like hacking into how this entire mystery gift process works.

I looked up on GBATemp and Project Pokemon but interestingly I could not find any technical insights on it. People had pretty much no progress after capturing the encrypted connections.

So, challenge accepted.

1

First, I went down to the basics like everyone else; Packet capture.
I used my laptop as a bogus wifi network to capture the packets from the 3DS

The 3DS was communicating with Nintendo servers with SSL as I expected.

2

I guess that it might be storing the certificate chain in the game file, as far as I know Wii games store their certificates within the game file.
I wasted a day trying to decompile the rom filesystem and searching for any meaningful information using grep. But eventually I found out that the certificates are not stored in the game file but it is embedded within the firmware SSL module.

3

I looked up for the ID of the SSL module and extracted the cia file from nintendo update server.
As all the update cias are encrypted, I needed to decrypt them using a 3DS.

4

Using Decrypt9, I retrieved the decrypted CIA file.
Lets get into the actual data using ctrtool.

5

Extracted the CXI portion from the dumped CIA file.
Now we need to get it splitted into proper partition.

6

I extracted the executable code from the exefs.

Lets take a look…

7

It is compressed with reverse LZ77 so lets uncompress it again.

8

After a bit of skimming I located the actual root certificate used for connection to 3ds-fushigi server.

Thank god Nintendo didn’t use complicated cert chain. As the root certificate is directly used for the communication we replace that and the work here is done.

The format seemed to be DER so I carefully exported the corresponding bytes.

9

Successfully retrieved the certificate in one shot.

Now lets create a certificate that is almost the same except that it will use MY private key.

10

Using OpenSSL I created the copy of the certificate, self signed it and converted it to DER format again.

11

I replaced the certificate in the code binary with the new one then I recompressed the code.bin with reverse LZ77.

12

But the header of the exefs requires the hash of the code.bin file, as I could not find any software that does the job for me I ended up patching the hash myself.

Then I redid the entire CIA decompiling process in the reverse order to create the new modified CIA file.

I installed the new CIA file onto the 3DS using devtool but it half bricked the 3DS upon reboot.

13

This is what a half bricked 3DS looks like. there is no menu on the bottom and it refuses to execute any of the softwares.
Trying to run Camera app using L+R freezes the console.

I wasted another 2 days trying to figure out what is going wrong, then I eventually found out that encrypting the CXI in the CIA file and using a sigpatched firmware could get around the problem.
By the time I worked on this there was no software capable of doing this but now one can use Decrypt9 to encrypt the CXI.

Anyway as the patched certificate is now in position we are moving onto server setup.

I changed the DNS settings of my 3DS and used redirected 3dsX-fushigi.pokemon-gl.com to my server’s IP address.

14

15

I created the certificate for secure https using IIS.

Then I started the mystery gift from the 3DS to see what happens.

Looking into the log I found that the 3DS was sending a request using a non-standard http format.

2016-02-03 12:07:40 *.*.*.* POST /api/serial.auth – 443 – *.*.*.* – 500 0 64 60

So I coded a secure proxy to dig into the detail.

16

This is the request sent from the 3DS for validating the gift code with Nintendo servers.
It contains the player’s GameSync ID, language settings, rom type, country code and etc.
Also the gift code in plain format, in this case 1111222233330000.

At this point I thought pretty much everything is over… and I was wrong.

17

A simple diagram for non-techy users.
I used a rogue DNS to redirect the traffic to my server and my server is behaving as the Man-in-the-Middle.
But strangely the response from the Nintendo server did not contain any information about the gift Pokemon.

18

This is the original response from the fushigi server.
I used a couple different working keys for comparison and discovered that it only tells the 3DS if the code is correct or the gift number on successful validation.

19

I did the packet capture again to see what it does after getting the response from fushigi server.
After disconnecting from fushigi the 3DS was connecting to npfl.c.app.nintendowifi.net.

But unlike fushigi, npfl server requires client authentication using a clientside certificate.

20

The client SSL certificate resides in a module called ClCertA

Extracting the certificate is done the same way as extracting the root certificate. But unlike the latter the client certificate is encrypted with AES-CBC, but thankfully we have a tool for that purpose.

21

Successfully extracted the certificate and key from the module

22

let’s convert the certificate into a more PC-friendly format.

23

Importing the certificate into the browser now enables us to impersonate as legit nintendo 3DS’s

Now let’s see what the server has to show us.

24

I see that the NPFL server holds the list of available gifts.

If given a gift number it will output the corresponding gift name for that number, if no input is given it shows all the available gifts.

File names are pretty much self-explanatory, although there are a couple of confusing names like M18KO_A, M18KO_HU. Which I guess means Arceus and Hoopa for the 18th Pokemon movie in Korean region.

One interesting thing to note is that when a 3DS connects to this server, it displays “Searching for gift…” message. It is _literally_ doing it.

If NPDL server gives a response and 3DS does find a gift, it will then connect to NPDL server to download the actual gift file.

25

To summarize, The process is like the diagram above.

I coded a program for simulating each of the servers, but I discovered that NPFL server is using a different certificate chain than others. It is authenticated using Nintendo G3 root certificate as opposed to other servers using Nintendo Class 2 cert. I can also replace the G3 certificate in the same way I did for Class 2, but as G3 certificate is also used for connecting to NASC and NPPL server, which is used to authenticate the nintendo 3ds and the cartridge itself everytime it tries to connect to the internet. I couldn’t figure out a way to emulate those servers due to their cryptic response format, so I ended up coding a secure proxy server that redirects all the information to the legit servers.

26

So this is the final diagram.

fushigi, npfl and npdl servers are accessed consecutively, so there is no problem running everything on a single server. But nppl and nasc servers are accessed randomly during connection, somethimes even simultaneously so they must be ran on different machines.

Anyway now I proceed to analyzing the output of the npdl server.

27

Despite so many steps it is still encrypted…

28

It is the BOSS format used in SpotPass, but to this date nobody bothered to document anything about the service.

29

But thankfully the specs for the header are documented, I coded a boss format decrypter from the information.

30

It is encrypted almost the same way as the client certificate execpt that it used AES-CTR and different set of private key. I coded another homebrew that is capable of decrypting AES-CTR from the raw data. the starting bytes of the CTR is the 12 bytes following the header plus 1 in big endian, so for this file the starting bytes will be 58 9A A6 73 5B EA D2 47 99 63 80 42 E7 01 00 00 00.

31

Presto! the gift is successfully decrypted. Although the actual format of the gift I will investigate later.

Now finally we can give ourselves a gift…

32

This is Amaura which my servers are gifting to my nintendo 3DS, with an arbitary gift code of MANATEE.
But as the gift file itself is also signed by nintendo, I guess there will be more stuff to be done before we can start creating our own giveaway pokemon.

The source code of the server emulators and AES-CTR decryptor will be released soon.

트켓몬 3DS 개발기

트켓몬 블랙이 끝난지도 많이 지났고

다음세대의 트켓몬을 만들어보고 싶었습니다.

하지만 6세대 3DS는 에뮬이 없고

사실 에뮬이 있긴있지만 초기단계이므로 사실상 게임플레이는 불가능한수준

대책을 만들어야 했습니다.

그래서 3DS에 캡쳐보드를 장착하고 컴퓨터로 화면 출력을 돌린 다음

컴퓨터에서 내리는 명령을 직접 3DS로 전달해주는 장치를 직접 개발에 착수했습니다.

colbaltblue

일단 닌텐도 3ds를 하나 새로 구입

다행히 캡쳐보드가 장착된 제품을 구할 수 있었습니다. 귀찮게 캡쳐보드부터 달지않아서 다행.

IMG_5973

바로 뚜껑따기에 돌입합니다.

IMG_5974

충전을 화면출력과 동시에 할수 있도록 커넥터 개조가 되어 있습니다.

이제부터 본격적인 작업에 들어갑니다.

IMG_5977

우선 가장자리부터 시작해서 방향패드를 들어냅니다

IMG_5979

기타 방해가 되는 모듈과 선들도 분리

IMG_5981

그리고 캡쳐보드를 필름이 끊어지지 않게 조심스레 들어올린뒤 SD카드 슬롯을 빼내고 안에 숨어있는 나사를 제거합니다.

IMG_5982

아랫면 확보 성공

중앙에 노란 필름은 캡쳐보드로 화면과 소리를 출력해주는 기판입니다.

IMG_5984

극세선을 조심스레 버튼핀에 납땜해줍니다.

n1CKAdbPrHyNPNuW.huge

닌텐도 3DS 버튼 구조는 단순합니다.
각 핀이 그라운드로 연결되면 인식이 되는 구조라

버튼키에서 이어져 나오는 포트에 납땜을 하여 도선을 연장시킵니다.

하지만 그중에 방향키 오른쪽에 해당하는 TP90은 캡쳐보드 필름때문에 바로 납땜이 불가능하여 불가피하게 버튼 자체의 코팅을 찢고 그위 구리부분에 납땜을 하였습니다.

IMG_5985

버튼이야 그냥 무난하군요

IMG_5986

대충 다시 덮어서 케이블을 뺄만한 공간을 찾았습니다.
오른쪽부분은 그냥 삼각줄로 케이스를 깎아냈습니다.

그리고 보통 게임카드 접속을 위해 카드 슬롯 끝부분은 그라운드이므로 그라운드핀은 게임슬롯에 납땜을 하여 이용했습니다.

2016-01-23 15_25_50-Gamecards - 3dbrew

혹시나 해서 확인

IMG_5987

버튼핀과 그라운드핀을 연결했을때 정상적으로 버튼입력이 인식되는것을 확인 하였습니다.

IMG_5991

극세사는 브레드보드 연결에 부적합하므로 끝부분은 다시 강도가 있는 단선을 연결후 절연처리를 하였습니다.

IMG_5992

마이크로 컨트롤러에 연결후 프로그래밍 하였습니다.

원래 집에 많이 있는 ATMega328칩셋으로 쓸려 하였으나 후에 터치스크린 구현에서 필요한 DAC 성능 때문에 틴지보드를 사용하였습니다.

IMG_5993

그리고 감압식 터치패드 입력을 분리합니다.

그런데 터치패드로 연결되는 선이 0.5mm FPC라 납땜으로 연결하기는 불가능한 크기이고 다른 대안을 찾아야 했습니다.

그와중에 집에있는 구형 PSP가 FFC케이블을 사용하던게 생각나서 바로 적출했습니다.

IMG_5995

가장자리에 4선을 제외하고 오려서 사용을 시도해보았는데

결과는 패망

대충 커넥터에 접속은 되나 극세사랑 연결시 납땜을 하면 케이블이 바로 녹아버립니다.
FFC의 한계를 체험

이런걸 주문제작으로 살려 하면 주문제작으로 최소 몇천개는 세트로 구해야하기때문에 너무 비효율적이고 시간도 오래 걸립니다.

그러던와중에 서랍에 넣어둔 옛날 NDS를 발견

바로 분해에 들어갔습니다.

IMG_5996

액정을 들어내니 같은 종류의 커넥터를 사용하고 있었습니다.

IMG_5998

조심스레 액정 커버와 터치패널, 액정을 분리합니다.

IMG_5999

터치패널에서 커넥터부분을 떼어내고

IMG_6001

알코올로 접착제를 긁어낸뒤 극세사 납땜을 해줍니다.

IMG_6002

접촉이 잘 되었는지 확인을 위해 시험삼아 한번 꽂아 보았습니다.

IMG_6006

나머지 부분도 납땜후 대충 전류를 흘려주니 어떻게 입력이 되긴합니다.

2016-01-23 16_08_49-HOW DOES IT WORK - HOW DOES IT WORK.pdf

데이터시트를 통해 알아보니 NDS/3DS는 이 방식을 사용하는 듯 합니다. VCC는 1.8V이였습니다.

볼트미터로 전압을 측정해보니 3DS는 대충 Y+ X+ X- Y- 의 순서로 핀이 배열된듯 합니다.

2016-01-23 16_04_34-4-Wire and 8-Wire Resistive Touch-Screen Controller Using the MSP430 (Rev. A) -

자 이제 대충 컨셉은 알겠습니다.

3DS의 VCC는 1.8V인데 틴지보드는 3.3V입니다. 버퍼를 사용할 수도 있지만 터치스크린을 아예 안 쓸 예정이므로 그냥 볼트미터로 아날로그 1.8V 출력이 가능한 값을 찾아서 그 값에 비례하여 줄이는 방법을 사용 하였습니다.

3DS의 경우 Y+가 GND로 연결되어 터치 인터럽트가 발생되면 바로 0.0005초 후에 X+ 전압을 읽어내고 Y+ 이 입력모드로 전환후 0.0002초동안 Y+ 전압을 측정하는 방식으로 작동합니다.

이젠 엄청나게 정밀한 타이밍이 요구됩니다.

우선 X+ 핀은 시간적 여유가 있으므로 PWM 으로 연결하고 Y+는 ADC에서 출력하는 방식으로 코드를 짰습니다.

mwlpq

오실로스코프에선 대충 이렇습니다.

그리고 좀 귀찮은 노가다끝에 정확한 타이밍을 맞추는 코드를 작성할 수 있었습니다

심지어 머신코드 최적화 컴파일러가 타이밍을 틀어버리는바람에 매우 귀찮은 반복의 연속이였습니다.

IMG_6008

드디어 완벽한 정사각형을 그려내는 컨트롤러의 모습입니다.

IMG_6015

나머지 선들을 전부 연결후 마무리 하였습니다.

극세선들이 매우 복잡하긴 하지만 귀찮으므로 정리는 하지 않습니다.

이제 컴퓨터로 화면 출력과 동시에 게임을 할수 있는 장비가 완성되었습니다.

어제 새벽에 전체적인 시험을 거친 후 채팅 처리 프로그램을 업데이트 하였습니다.

국내판 콘솔에 국내판 소프트웨어로

인터넷 접속도 가능하도록 하였습니다.

3DS 콘솔이 있으신분은 본인 포켓몬과 교환도 가능.

모험의 시작은 오늘 6시 정각입니다

http://twitch.tv/manatails