‘처음’ Windows 설치 파일을 ‘배포’하는 개발자들을 위하여


이 글에서는 처음으로 설치 파일을 웹에 배포하는 과정 그리고 예상하지 못했던 난관에 대하여 설명해보려 합니다.

앱 개발을 완성하고 설치 파일까지 만들었다고 모든 것이 끝났다고 생각하시면 안됩니다. 별 생각 없이 설치 파일을 웹에 게시하고 웹페이지에서 다운을 받으면 다음과 같은 화면들을 만나게 됩니다.

스크린샷 2015-11-10 오후 6.35.09<이 파일은 위험해!>

alert<Windows 설치 때 한 번 더 뜨는 경고..>

스크린샷 2015-11-17 오후 3.16.01<Chrome도 예외는 아닙니다>

만약 사용자들이 이런 메시지를 본다면 기껏 열심히 만들어 놓은 앱이 악성 프로그램 취급받게 될 것입니다. 자, 앱 개발은 끝났을 지라도 앱 배포는 이제부터 시작입니다. 이 배포에 걸리는 시간은 생각하는 것보다 오래걸립니다.

 

전자 서명

배포를 하기 위하여 제일 먼저 해야할 것은 전자 서명입니다. 전자 서명의 원리 설명은 네이버 개발자 블로그에 친절하고 자세히 나와 있습니다. 간략하게 설명을 하자면, 코드 서명 인증서(Code Signing Certificate)를 가지고 서명한 파일은 내가 만든 파일임을 인증해주는 원산지 표시와 비슷합니다. 예를 들어 해커들이 리멤버와 똑같이 생긴 악성 설치파일을 만들어서 리멤버인 것처럼 배포를 하여도 드라마앤컴퍼니가 만들었다는 인증서가 없으므로 사용자들은 위험한 파일임을 알 수 있습니다.

전자 서명을 하기 위해서 처음으로 해야 할 일은 코드 서명 인증서를 구하는 일입니다. 아쉽게도 전자 서명은 무료가 아니라 유료로 Symantec과 같은 인증서 발급 업체에서 회사 혹은 개인 정보를 인증받고 코드 서명 인증서(Code signing certificate)를 구매해야 합니다.

인증서 종류도 표준(Standard)과 EV로 두 가지 종류가 있습니다. MSDN에서 표준과 EV 인증서의 차이, 그리고 구매 방법들에 대하여 읽어보실 수 있습니다. EV 인증서가 가격이 더 비싸며 대부분의 경우에는 표준을 사용하셔도 무방합니다.

이제 구매한 인증서와 MS에서 제공하는 SignTool.exe를 가지고 우리가 만든 프로그램을 서명합시다. SignTool에서는 다양한 인자들을 제공하는데 API 문서를 읽어 보시고 필요한 부분들을 사용하시면 됩니다. 저의 경우에는 다음 인자들을 사용했습니다.

이렇게 서명을 완료하면 다음과 같이 뭔가 부족해 보이던 설치파일이

unsigned_installer

다음과 같이 든든하게 변합니다.

signed_installer

스크린샷 2015-11-17 오후 4.12.27

<올.바.른. 인증서입니다.>

그렇다고 이제 끝일까요? 저도 여기서 끝이라고 생각했습니다.. 이렇게 파일을 다시 서버에 올려서 다운 받아도 마찬가지로 IE와 Chrome은 여전히 우리의 파일을 위험하다고 얘기합니다. 서명이 잘못되었나.. 설마 비싼 인증서 잘못 구매한 건가.. 하루 종일 구글링을 하고 이곳 저곳에 수소문해봐도 명쾌한 답이 나오지 않았습니다. 그러다 결국은 설마 했던 ‘명성이 부족하다’라는 결론을 내리게 되었습니다.

 

명성치

MS의 SmartScreen filter는 인증서들에 대한 자체적인 white list DB를 관리하며 해당 인증서가 안전한지 아닌지 판단합니다. 새로 등록된 인증서로 만들어진 파일이 일정 횟수 이상, 일정 기간 이상 동안, 일정 사용자들에게 다운로드 되고, 신고 건수가 없어야 안전한 파일로 white list에 등록합니다(SmartScreen filter는 원래 IE에 존재하던 기능이었다가 Windows 8부터는 OS 자체 기능으로도 추가되었습니다). Google의 Chrome도 이와 비슷한 로직을 가지고 있습니다.
즉, 일정 수준을 명성을 쌓기 전까지는 위험한 프로그램 취급을 하여 사용자들에게 경고 메시지를 보여 줍니다. 하지만 여기서 답답한 부분은 필요한 ‘다운로드 수’, ‘다운로드 인원’, ‘처리되는 기간’ 등 중요한 정보들이 공개 되어있지 않다는 것입니다.
저희는 회사 직원(약 25명)에게 Chrome과 IE로 다운로드 요청을 몇차례에 걸쳐서 했습니다. IE의 SmartScreen은 처음 전사원이 받은 후 이틀 뒤에 통과됐습니다. 그리고 다시 전사원이 다운로드를 받았고 약 1주일 뒤에 Chrome에서 통과했습니다.  그 이후로는 일부 사용자들에게 미리 공개를 하여 받게 했습니다. Windows 8 이상부터 생긴 OS자체의 ScreenFilter는 꽤 오랜 시간이 걸렸던 것 같습니다. 확실한 방법과 시간은 알 수 없지만 여유롭게 약 2~3주간 소수의 베타 테스터들에게 뿌려야 하는 시간을 염두해야 할 것 같습니다(누군가 위험판 프로그램이라고 신고를 하지 않는다는 가정하에).

 

마무리

주위에 Windows 개발자 분들도 찾기 힘들지만 ‘최초로 인증서를 발급받아 배포를 경험’해본 분은 더더욱 찾기 힘들어서 많은 애를 먹었습니다. 사실 아직도 불확실한 시간에 무작정 기다려야 한다는 것 자체가 매우 마음에 들지는 않습니다. 그리고 인증서가 만료되어 새로운 인증서를 발급받으면 이 과정을 똑같이 한 번 더 거쳐야 하므로 이왕이면 유효기간이 긴 인증서를 사용하지 게 좋을 것 같습니다. 마지막으로 저희는 이렇게 인증을 받았지만, 이 방법을 제가 잘못 알고 있는 것이라면 꼭 알려주시면 감사하겠습니다 🙂 (개인적으로는 꼭 더 효율적인 방법이 있었으면 합니다).

 

참고 링크

MSDN 블로그의 스마트 스크린과 코드 서명 이야기

http://blogs.msdn.com/b/ie/archive/2012/08/14/microsoft-smartscreen-amp-extended-validation-ev-code-signing-certificates.aspx

‘Chrome도 몇 일 기다리면 된다’ 라는 토의 thread

http://blogs.msdn.com/b/ie/archive/2012/08/14/microsoft-smartscreen-amp-extended-validation-ev-code-signing-certificates.aspx


http://blog.dramancompany.com/블로그 펌



'Windows > SSL' 카테고리의 다른 글

응용프로그램 인증  (0) 2017.12.20
윈도우 부팅순서

지금에서야 컴퓨터포렌식이 아닌 모든 디지털기기를 다룬다는 의미의 디지털포렌식이라는 용어를 사용하지만 시작은 컴퓨터 시스템(데스크탑 or 서버 등)이었다. 따라서 디지털포렌식에서 컴퓨터의 기본을 이해하는 것은 매우 중요하다. 흔히 내공이라 불리는 기본 지식과 상식들은 진정 자신의 가치를 대변해주곤 하기 때문이다.
윈도우 운영체제에서 컴퓨터를 부팅시키기 위해 전원 버튼을 누르고 나면 간단한 하드웨어 체크 후에 윈도우 로그온 화면으로 넘어간다. 흔히들 골뱅이라 불리우는 진행바가 몇번 왔다갔다 한 후 윈도우 운영체제의 쉘인 explorer.exe 가 실행되어 바탕화면이 보이게 된다. 언듯 보기에는 간단해 보이지만 내부적으로는 더 많은 과정을 거치게 되는데 지금부터 그 과정에 대해서 알아보자.
  1. 처음 전원버튼을 누르게 되면 Power Supply는 외부로부터 들어온 전압을 검사하여 현재 시스템에서 사용할 수 있는 전압으로 변환한다. 변환된 전기적 흐름은 CPU로 전달되어 CPU가 가지고 있는 이전의 값들을 지우고 CPU 레지스터인 Program Counter(PC)를 초기화시킨다. 초기화되는 값은 보통 0xF000 값을 가지는데 이 값은 메인보드에 위치한 ROM BIOS의 부트 프로그램(boot program or bootstrap)의 주소 값을 가르킨다. 따라서 이후에는 부트 프로그램에 정의한 작업이 수행된다.
  2. 부트 프로그램은 먼저 CPU 이상 유무를 테스트한 후 POST(Power On Self-Test) 작업을 수행하기 위한 기본적인 테스트를 수행한다. 만약 테스트 결과가 ROM BIOS에 저장된 값과 일치하면 POST 작업을 수행한다.
  3. POST의 첫 번째 단계으로 CPU는 System Bus가 정상적으로 동작하는지 테스트하기 위해 System Bus로 특정 시그널을 보낸다. 테스트가 이상이 없다면 다음 단계로 넘어간다.
  4. 다음 단계로 RTC(Real-Time Clock; or system clock)을 테스트한다. RTC는 시스템의 전기적 신호를 동기화하기 위한 클럭으로 CMOS를 구성하는 장치에 칩 형태로 존재한다. RTC 테스트가 이상이 없다면 다음 단계로 넘어간다.
  5. 다음 단계로 시스템의 비디오 구성요소들(비디오 메모리 등)을 테스트한다. 이 과정이 완료된 후에야 비로소 표준출력을 이용해 부팅과정에서 정의된 출력을 볼 수 있다.
  6. 다음 단계로 RAM을 테스트한다. RAM을 테스트 하는 장면은 컴퓨터 부팅 과정에서 모니터 화면을 유심히 본 사람이라면 누구나 한번 쯤 보았을 것이다. 현재 RAM에는 ROM BIOS와 비디오 BIOS에서 읽어들인 데이터가 존재할 것이다. 따라서 해당 데이터가 정상적인지 테스트를 하게 된다.
  7. 다음 단계로 키보드가 정상적으로 연결되어 있는지 혹은 눌려진 키가 없는지 테스트 한 후 이상이 없으면 다음 과정으로 넘어간다. 부팅 과정에서 키보드의 키가 눌려져 있는 경우 삐익~!@ 하는 연속적인 비프음 소리를 들어본 경험이 있을 것이다. 또한 POST 과정에 키보드에 대한 테스트 과정이 포함되기 때문에 키보드가 연결되지 않은 시스템은 POST 과정을 완료하지 못하고 부팅되지 않는 것을 경험해 봤을 것이다.
  8. 다음 단계로 시스템에 연결된 모든 드라이브(플로피, CD, 하드디스크 등)에 신호를 보내 정상적으로 동작하는지를 테스트한다.
  9. 다음 단계로 앞서 수행한 POST의 결과가 CMOS(RTC/NVRAM)에 저장된 값과 일치하는지 검사한다.
  10. 다음 단계로 SCSI BIOS와 같은 추가적인 BIOS를 RAM에 로드하고 Plug and Play를 실행하여 운영체제 로드를 위한 기본적인 구성을 RAM에 로드한다.
  11. 다음 단계로 부트 프로그램은 운영체제를 로드하기 위해 인식한 드라이브 내에서 첫 번째 섹터를 읽는다. 드라이브의 첫 번째 섹터에는 MBR(Master Boot Record)이 위치한다. MBR 섹터의 마지막 2바이트는 정상적인 MBR을 알려주는 시그니처 “0x55AA” 값을 가진다. MBR의 앞부분 446 바이트의 16비트 부트 코드를 수행하다가 오류가 발생하면 적절한오류메시지를 출력한다.
다음의 그림은 MBR의 내용을 확인한 것이다. “Invalid partitons table.”,  “Error loading operationg system.”, “Missing operating system” 와 같은 오류메시지를 확인할 수 있다.
 
  1. 다음 단계로 MBR에서 부팅 가능한 파티션을 찾는 작업을 수행한다. MBR의 오프셋(offset) 446~509까지 64바이트가 파티션의 정보를 나타내는데 각 파티션은 16바이트를 사용한다. 따라서 기본적으로 4개의 파티션에 대한 정보 저장이 가능하다. 각 파티션의 첫 번째 바이트는 부팅 가능한 파티션인지를 나타낸다. 값이 0×80을 가지면 부팅 가능하고 0×00이면 부팅 가능한 파티션이 아니다. 만약 파티션이 부팅 가능하다면 해당 파티션의 시작 위치로 이동한다. 이동하게 되면 MBR과 유사한 형태의 첫 번째 섹터가 나온다. 이 섹터를 VBR(Volume Boot Record)라고 한다. 이때 부터는 운영체제에서 정의된 부팅 과정이 수행된다. 앞서 파티션이라고 언급했는데 볼륨 부트 레코드라고 하는 것에 다소 오해가 있을지 모르겠지만 일반적으로 볼륨 당 하나의 운영체제의 부팅이 가능하기 때문에 VBR이라고 한다. 이해가 가지 않는다면 볼륨과 파티션의 관계를 다시 한번 확인해보기 바란다.
지금부터는 Windows NT/2000/XP 에서의 부팅 과정에 대한 내용이다.
  1. VBR에 클러스터크기, MFT 위치, 전체 섹터 등 해당 볼륨의 추가적인 정보 외에도 부팅에 필요한 시스템 파일의 위치와 실행할 수 있는 코드가 포함되어 있다. 이러한 코드는 NT Loader(NTLDR)에 의해 로드되어 실행된다. 먼저 NTLDR은 부팅 옵션 및 부팅 메뉴가 정의되어 있는 BOOT.INI 파일을 로드한다. 이후 윈도우 이외의 다른 운영체제와 듀얼 부팅을 한다면 BOOTSEC.DOC 파일을 로드한다. 또한 SCSI 드라이브가 장착되어 있다면 해당 드라이브 실행을 위한 NTBOOTDD.SYS 파일을 로드한다.
  1. 이후 NTLDR은 NTDETECT.COM을 로드하여 설치된 하드웨어와 관련 구성 파일들을 찾아 실행하도록 한다.
  2. NTDETECT에 의해 수행된 결과는 NTOSKRNL.EXE(NT OS KERNEL)에 적용된다. 이후 NTOSKRNL.EXE은 커널(Kernel), HAL(Hardware Abstraction Layer), 시스템 레지스트리 정보를 로드한다.
  3. 다음으로 TCP/IP와 관련된 네트워크 드라이버들을 로드하고 로그온 화면을 보여준다. 사용자가 로그인에 성공하면 사용자에 대한 레지스트리 정보를 가져와 사용자 환경을 구성한다.
  4. 로그인 과정에서 Plug and Play에 의해 새로운 장치가 발견된다면 DRIVER.CAB 파일에서 관련 드라이버를 로드하여 해당 장치를 마운트 시킨다. 관련 드라이버가 없다면 드라이버 설정하는 다이얼로그를 보여주게 된다.
  5. 이러한 과정이 지나면 윈도우의 쉘인 explore.exe 가 실행된 화면을 보게 된다.
 

12단계 까지의 부팅 순서는 동일하지만 12단계 이후부터는 윈도우 운영체제에서도 각 버전에 따라 많은 차이를 보인다.


'Windows > 기타' 카테고리의 다른 글

윈도우 부팅순서  (0) 2017.12.12
윈도우 로그온 유형  (0) 2017.12.12
HTTP 통신시 서버에서 보내주는 응답코드  (0) 2017.12.12

  1. 로그온 유형 2 (Logon Type 2) : 대화식

    콘솔에서 키보드로 로그인 (LogMeIn, TeamView, KVM 포함)


  2. 로그온 유형 3 (Logon Type 3) : 네트워크

    네트워크를 통한 원격 로그인. (파일 공유, IIS 접속 등)


  3. 로그온 유형 4 (Logon Type 4) : 자동실행(스케줄)

    스케줄에 등록된 배치 작업 실행시 미리 설정된 계정 정보로 로그인


  4. 로그온 유형 5 (Logon Type 5) : 서비스

    서비스가 실행될때 미리 설정된 계정 정보로 로그인


  5. 로그온 유형 7 (Logon Type 7) : 잠금해제

    화면보호기 잠금 해제시


  6. 로그온 유형 8 (Logon Type 8) : 네트워크 (평문암호)

    유형 3과 비슷하지만 계정 정보를 평문으로 전송시 발생 (ASP 기본 암호설정)


  7. 로그온 유형 9 (Logon Type 9) : 새 자격

    실행(RunAs)에서 프로그램 실행시 /netonly 옵션을 줄때


  8. 로그온 유형 10 (Logon Type 10) : 원격 대화식

    터미널 서비스, 원격 접속, 원격지원으로 로그인


  9. 로그온 유형 11 (Logon Type 11) : 캐쉬된 대화식

    PC에 캐쉬로 저장된 암호로 자동 입력 로그인시


'Windows > 기타' 카테고리의 다른 글

윈도우 부팅순서  (0) 2017.12.12
윈도우 로그온 유형  (0) 2017.12.12
HTTP 통신시 서버에서 보내주는 응답코드  (0) 2017.12.12

+ Recent posts

티스토리 툴바