AES 256 암호화를 위한 WinCrypt 사용하기

MSDN에서 참고하자니… 너무나도 설명이 장황하고 API 사용에 핵심이되는걸 찾지못하여 example을 구글링하여 여차저차 짜집기하였다. 그중 가장 많은 도움이된 글은 이글이글.

만약 Crypt관련함수들 링크실패하면 헤더나 소스코드에 #pragma comment(lib, "advapi32")를 넣으면된다.

아래는 최소한의 헤더파일

#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
#include <wincrypt.h>

AES 암호화에서 안정성이 보장되는 AES 256을 기준으로 설명한다. 그 하위 AES 암호화는 KEY의 길이가 다르기때문에 필요하다면 32비트 KEY 대신 16비트 키를 사용하면… 될것이다. 나머지는 알고있기로는 동일.

필요한 변수는 아래와같다.

HCRYPTPROV hCryptProv;
HCRYPTHASH hHash;
HCRYPTKEY hKey;

첫번째로 Provider를 얻어야한다.

if (CryptAcquireContext(&hCryptProv, NULL, MS_ENH_RSA_AES_PROV, PROV_RSA_AES, 0) == FALSE) {
    return FALSE;
}

핸들을 해제하는 코드는 아래와같다. 이 핸들은 지속적으로 사용하게된다. 완전하게 사용이 끝났으면 그때 Release 해주면된다. Continue reading AES 256 암호화를 위한 WinCrypt 사용하기

오늘의 랜섬웨어 업데이트 삽질기(…)

오랜만에 윈도우와의 즐거운 삽질이였다(…).

오늘은 떠들석한 랜섬웨어 업데이트 공문이있었다. ‘랜선을 뽑고’ SMB/CIFS를 제거하고 업데이트하라고 되어있지만 아마도 대부분은 이미 인터넷 다 하고 문서를 받은 뒤 늦게서야 SMB/CIFS를 제거했을거같은데… 이미 내부에서 랜섬웨어가 돌고있었다면 업데이트 하기전에 걸려버릴 가능성이 있을거같다.

잡설은 끝내고, 문서를 자세히 안보고(…) Windows Server 2012 R2에서 업데이트 네개를 받았는데 업데이트 내용을 아무리 다시봐도 별반 달라보이는거 없어서 문서를 다시보니 아래 테이블 아래 “1개 이상 패치번호 일치 시 패치완료”라는 문구가있었다. 즉 Windows Server 2012 R2라면 패치번호에있는 네개 업데이트를 전부 해야하는게아니라 그중에 한가지가 있으면 되는거였다(…).

번호 운영체제 패치번호 비고
1 Windows Vista SP2 KB4012598
2 Windows Server 2008
3 Windows 7 KB4012212, KB4012215
4 Windows Server 2008 R2
5 Windows 8.1 KB4012213, KB4012216
6 Windows Server 2012 KB4012213, KB4012214, KB4012216, KB4012217
7 Windows Server 2012 R2
8 Windows RT 8.1 KB4012216
9 Windows 10 KB4012606, KB4013198, KB4013429
10 Windows Server 2016 KB4013429
11 Windows Vista KB4012598 취약OS
12 Windows 8
13 Windows Embedded 8
14 Windows XP
15 Windows Server 2003

인터넷 안되는 PC여서 그간 업데이트 안해서인지 위 보안 업데이트가 안되어 기술문서 찾고찾아보니 결국 해결법은 이전에 삽질했던것과 동일한 이것이였다는건 안비밀.

Qt 5.8.0 WebEngine 모듈 빌드

보통은 그냥 Qt 홈페이지에서 빌드된것을 받아서 설치해도된다. 단, 5.8.0은 배포중인 VS 2017 타겟 바이너리가 없고, 디버깅 시 상황에 따라서는 약간 더 유리하기때문에 직접 빌드하는걸 선호한다. (그리고 그냥 갠적인 취향 약 80%) 이전에 누수를 찾을 수 없어 직접 빌드하여 QtSql의 ODBC 플러그인 메모리 누수 버그를 찾아내고 코드 리뷰에 올리고 커밋하여 아마도 5.6.0버전부터 적용되어있다는건 안비밀(…)

일단 두서없는 글이였지만 이것을 참조하여 OS의 비 유니코드 환경을 영어(미국)으로 바꾸는것이 이롭다.

이번에도 직접 빌드 삽질. 5.7.0과는 다르게 필요한 것들은 다 있는데 configure 후 nmake(or jom)을 해도 웹 엔진이 빌드되지않았다. 영문 문서…에서는 일단 해석도 잘 못하고 그냥 봤을때는 별다른 언급이 없었다. 정말 아무리 찾아봐도 별다른 내용이 없었다. (덕분에 5~6번은 distclean & build 한거같다.)

문서에 Qt 개별 모듈을 받아서 빌드 언급이 잠깐있어서 혹시나하여 소스코드에서 qtwebengine 폴더로 이동 후 qmake & nmake(or jom)을 실행하니 빌드가되었다. 아마도 이게 워낙 오래걸리고 덩치가 커서 기본적으로 skip 처리되어있는거 아닌가 싶다. 하지만 규모가 큰 C++ 프로젝트는 오류 한두개 생기는 법. 그래서 직접 빌드를 해본 내용을 정리.


환경 1
Visual Studio Community 2015 Update 3 (최소 Update 2가 요구된다.)
Windows SDK 10.0.15063.137

환경 2
Visual Studio Community 2017
Windows SDK 10.0.1563.137 (Visual Studio 2017에서 함께 설치되는 Windows SDK 10은 지우고 ISO 파일을 받아서 다시 깔았다. 필요에 의해서였는데 왜인지 기억이 안난다 -_-)


공통
Perl 최신버전 (Qt 문서에서는 Active Perl로 명시되어있지만 Strawberry Perl로도 가능)
Python 2.7.5 or later (Qt 문서에서는 2.7.5 or later로 명시되어있지만 3버전으로 테스트 안해봤음)
메모리는 8기가 이상.. 왠만하면 16기가 이상을 권장한다. 이것역시 WebEngine에서 사용하는 Chromium의 코그가 워낙 방대해서 메모리에 파일캐쉬를 많이 못하면 디스크 IO가 많이발생하여 빌드 속도에도 영향이있다.


Windows SDK 10을 설치하면 mt.exe 파일을 못찾는 경우가 발생한다. 명령줄에서 mt를 쳐서 명령을 못찾는다면 아래처럼 환경변수에 추가해야한다.
32비트 도구 프롬포트 환경
set PATH=%PATH%;C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86
64비트 도구 프롬포트 환경
set PATH=%PATH%;C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64


환경 1에서의 WebEngine 에러 수정
코드 리뷰: https://codereview.chromium.org/2317773002/patch/60001/70005

소스코드 폴더 기준으로 “qtwebengine\src\3rdparty\chromium\device\bluetooth” 경로의 bluetooth_task_manager_win.cc 파일을 열고 OnGetGattEventWin 함수가 정의된 157줄을 void 뒤 CALLBACK 추가하여 void CALLBACK OnGetGattEventWin으로 정의를 변경

환경 2에서의 configure 에러 수정
코드 리뷰: https://codereview.qt-project.org/#/c/177743
이건… 수정할게 좀 많다. 그냥 이 페이지를 참고해서 비교하어 수정하는게 나을것같다. qalgorithms.h파일의 경로는 “qtbase\src\corelib\tools”이다.
만약 직접 수정하기가 좀 그렇고 5.8.0버전의 코드를 빌드한다면 이 주소로 파일을 받은다음 압축을 풀고 이름을 원래대로 수정한다음 덮어씌워도 된다.


아래는 내가 사용한 configure 명령 줄
configure -opensource -confirm-license -prefix D:\OpenSource\Qt5.8.0 -opengl dynamic
opengl 옵션을 지정안하면 es2로 설정되고 5.5부터는 dynamic을 기본으로 사용하는 것 같다. (참고)
prefix는 빌드 후 nmake install 하면 바이너리와 헤더가 설치되는 경로.


configure 명령이 완료된 후 nmake(or jom)을하면 문제없이 빌드 될것이며 이후 nmake install(or jom install)을하면 기본 Qt 모듈들이 복사될것이고, WebEngine을 빌드하려면 소스코드 폴더에서 qtwebengine 폴더로 이동한 후 qmake하고 역시나 nmake(or jom)하여 빌드, nmake install(or jom install)하면된다.

단지 주의할것으로는 perl, python명령이 실행되는지, flex, bison, gperf명령이 실행되는지 확인하는것이 좋다. Qt 소스코드 내 gnu 명령어들이 있으니 아래처럼 환경변수를 변경하여 재공되는거로 쓰는게 이로울거같다. (소스가 “D:\OpenSource\qt-everywhere-opensource-src-5.8.0″에 있다는 가정)

set PATH=%PATH%;D:\OpenSource\qt-everywhere-opensource-src-5.8.0\gnuwin32\bin;D:\OpenSource\qt-everywhere-opensource-src-5.8.0\qtbase\bin

환경변수가 잘 설정되었다면 아래와같이 각각의 버전정보를 볼 수 있다.

D:\OpenSource\qt-everywhere-opensource-src-5.8.0>python --version
Python 2.7.13

D:\OpenSource\qt-everywhere-opensource-src-5.8.0>perl --version

This is perl 5, version 24, subversion 1 (v5.24.1) built for MSWin32-x64-multi-thread

Copyright 1987-2017, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.


D:\OpenSource\qt-everywhere-opensource-src-5.8.0>bison --version
bison (GNU Bison) 3.0
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

D:\OpenSource\qt-everywhere-opensource-src-5.8.0>flex --version
flex 2.5.37

D:\OpenSource\qt-everywhere-opensource-src-5.8.0>gperf --version
GNU gperf 3.0.1
Copyright (C) 1989-1998, 2000-2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Douglas C. Schmidt and Bruno Haible.

뭐… 갠적으로는 webengine을 사용할 일이 없지만 왠지 5.7 빌드할때와 달라서 불필요한 삽질을 한거같다(…)

Objective-C와 Swift에서 NSData(Data) 데이터 단순 탐색

Objective-C 코드 (bytes는 NSData 클래스 객체에서 bytes를 호출하여 얻은 데이터 포인터)

for(uint32_t i = 0; i < dataSize - 4; i++)
{
    uint32_t startCode = *(uint32_t *)(bytes + i);

    if(startCode == 0x01000000)
    {
        [points addObject:[NSValue valueWithPointer:bytes + i]];
        [nalSizes addObject:[NSNumber numberWithInt:4]];
        
        i += 3;
    }
    
    if((startCode & 0x00FFFFFF) == 0x00010000)
    {
        [points addObject:[NSValue valueWithPointer:bytes + i]];
        [nalSizes addObject:[NSNumber numberWithInt:3]];
        
        i += 2;
    }
}

 

Swift 코드 (3.0으로 빌드, streamData는 Data 클래스의 객체)

streamData.withUnsafeBytes { (p8: UnsafePointer) in
    while i < count
    {
        if p8.advanced(by: i + 0).pointee == 0 && p8.advanced(by: i + 1).pointee == 0
        {
            if p8.advanced(by: i + 2).pointee == 0 && p8.advanced(by: i + 3).pointee == 1
            {
                offsets.append(i)
                nalSizes.append(4)
                
                i += 4
                
                continue
            }
            if p8.advanced(by: i + 2).pointee == 1
            {
                offsets.append(i)
                nalSizes.append(3)
                
                i += 3
                
                continue
            }
        }
        i += 1
    }
}

 

H264에서 NAL 헤더를 찾는 코드이다. 어쩌다보니 기존에 Objective-C로 코드를 만들어놓은걸 Swift로 옮기다보니... 생각보다 삽질을 많이하게되었다. 프레임워크는 동일하지만 Swift는 기본적으로 포인터 연산을 지원하지않기때문에 C에서의 구조체, 바이너리 데이터를 int형식으로 형변환하여 비교하는 등의 연산에서 자유롭지않아보인다. 동일한 LLVM에서 컴파일되고 1:1 호환 가능하다고는하지만 위와같은 사항 외에도 언어의 특성이있어서 목적은 동일하지만 결국은 코드의 구조는 달라졌다.

딱봐도 Swift의 코드가 비효율적으로 보이지만 초당 1메가정도의 데이터에서 CPU점유율을 보면 1~2%정도만 더 Swift에서 많이 사용한다. 아직 릴리즈 빌드는 찾아본적없어서 export하게되면 또 차이날지는 모르겠지만... 현재로서는 약 2~3시간 삽질을 한 결과 위 코드가 Objective-C의 코드와 가장 근접한 CPU 사용률을 보이는 코드이다.

아래는 순서대로 Objective-C, Swift 코드에서의 CPU 사용률