jacob's blog

송수신자 간의 메시지를 주고받을 때, 메시지가 변조되었는지를 확인할 필요가 있습니다. 원본 메시지와, 전달된 메시지를 비교하여 변조 여부를 확인하는 방식이 MAC(Message Authentication Code)입니다.

해싱과 공유키를 사용한 MAC 기술이 바로 HMAC

HMAC(Hash based Message Authentication Code)은 RFC2104로 발표된 MAC 기술의 일종으로,

원본 메시지가 변하면 그 해시값도 변하는 해싱(Hashing)의 특징을 활용하여 메시지의 변조 여부를 확인(인증) 하여 무결성과 기밀성을 제공하는 기술입니다.

일반 해싱 알고리즘과 HMAC의 공통점은 해싱 알고리즘이 적용된 해싱 함수를 사용한다는 것이고,

가장 큰 차이는, HMAC은 해시 암호 키를 송신자와 수신자가 미리 나눠가지고 이를 사용한다는 것입니다.

송수신 자만 공유하고 있는 키와 원본 메시지를 혼합하여 해시값을 만들고 이를 비교하는 방식입니다.

해시 함수에 사용하는 해시 알고리즘에 MD5, SHA 등을 사용하며, 사용 알고리즘에 따라 HMAC-MD5, HMAC-SHA1, HMAC-SHA2-256 등으로 나누어집니다.

송신자-수신자 간의 HMAC 플로우

HMAC을 사용한 메시지 무결성의 전반적인 프로세스는 다음과 같습니다.

<HMAC을 사용한 메시지 무결성의 전반적인 프로세스>

위 그림을 순서대로 설명해보겠습니다.

1. 송신자와 수신자 사이에 암호화 채널을 사용하여 해싱에 사용할 키(key)를 공유합니다. 
☞ 양쪽이 동일한 key를 사용하니, 대칭키(symmetric key) 방식이라 할 수 있습니다.

2. 송신자는 key를 사용하여 원본 메시지를 해싱합니다. 해싱된 메시지가 바로 MAC입니다.

3. 송신자는 원본 메시지와 그것의 해싱 메시지(MAC)를 수신자에 전달합니다.

4. 수신자는 key를 사용하여 원본 메시지를 해싱하고, 송신자에게 받은 MAC과 비교합니다.

5. 비교한 값이 동일하다면, 원본 메시지는 변조되지 않았고 신뢰할 수 있는 값으로 판단합니다.

6. 만약 해커가 메시지를 변조했다면, 수신자의 MAC과 송신자의 MAC 값이 다른 것을 확인할 수 있습니다.

얼핏 보면, 누군가 엿볼 수 있는 원본 메시지를 그대로 보내는 것이 의아하게 보일 수 있습니다만 해싱은 암호화가 아닌, 무결성을 확인하는 기술이라는 것을 다시 한번 상기해야 합니다. 실제로 암호화와 해싱을 모두 수행하기 위해 HTTPS와 같은 보안 채널을 통해 원본 메시지를 보호하고, MAC과 같이 전달하는 것이 일반적입니다.

Replay Attack에 대한 방어

공격자는 메시지를 변조할 수 없으니, HMAC을 그대로 사용하여 수신자에게 불필요한 호출을  여러 번 공격성으로 보낼 수 있습니다. 이런 공격을 Replay Attack이라고 합니다. 이 공격을 방지하기 위해서는 HMAC과 함께 송신자의 송신 시간에 해당하는 타임스탬프(timestamp) 값을 찍어 보내어, 특정 시간이 지난 후에 메시지 자체가 무효화될 수 있는 로직을 사용하기도 합니다.

지금까지 설명은 원본 메시지를 전달하는 경우의 무결성을 위한 HMAC의 예를 들었지만, 실제로는 HMAC을 단순히 메시지 무결성을 확인하는 경우보다 REST API의 URL 경로에 API Key와 HMAC을 함께 보내어 API 서버가 변조되지 않은 API 호출임을 검증하거나, HMAC으로 만든 인증 코드를 통해 서버에 로그인하는 등의 시나리오에 사용합니다.

참고

: https://brunch.co.kr/@sangjinkang/34

GitHub - Image 올리기 (README, Issue, PR)

GitHub - Image 올리기

GitHub를 사용해서 코드를 관리하다 보면, 가끔 사진(Image) 파일을 올려야할 때가 종종 있다. 예를 들면, 프로젝트의 설명을 작성하는 README.md 파일에 이해를 돕기 위해 프로그램 일부를 캡쳐해서 포함시키거나, 문제를 제기하는 Issue나 문제를 해결했다는 Pull Request를 작성할 때에도 다른사람들이 빠르게 이해할 수 있도록 글 이외에 그림을 넣는 경우들이 있다. 하지만, GitHub는 코드를 관리하기 위한 목적으로 이용되기 때문에, 코드 이외에 사진 파일이나 압축 파일 등의 다른 파일들에 대한 지원을 쉽게 하고 있지 않다. 아래 몇가지 방법으로 Github에서 이미지와 함께 글을 작성하는 방법을 소개한다.

Issue 글을 작성할 때와 Pull Request(PR) 글을 작성할 때 Image 올리기

Issue 글과 PR 글을 작성할 때 Image를 업로드하는 방법은 동일하다. 아래 설명은 Issue 글을 올리는 상황에 대한 설명을 하고 있으나, PR 글을 작성할 때도 동일한 방법으로 글과 Image를 함께 작성하면 된다. 

우선, Issue 글 작성하기를 눌렀다면, 아래처럼 글을 쓰는 공간에 이미지를 복사(Ctrl+C) & 붙이기(Ctrl+V)를 하거나 이미지 파일을 드래그(Drag) & 드롭(Drop)을 하면 된다. 붙이기를 하면 아래 캡처한 화면처럼 사진이 바로 삽입되는 것이 아니라, "![Uploading <업로드할 image>]()" 라는 문자열이 잠깐 동안 삽입이 되는 것을 확인할 수 있다. 이 문자열과 동시에 하단에 "Uploading your files..." 라는 표시가 나온다. 업로드 하는 사진의 용량에 따라 시간이 다르게 나오는데, 이 때, 알아두어야할 점은, png 이미지로 변환해서 올려진다는 것이다. 만약에 올리려는 사진의 확장자가 png 가 아닌 jpg, jpeg 등의 다른 확장자라면 png로 올라갈 것이다. 아마도 Github 에서 Issue와 PR에 올리는 사진은 참고용으로만 작성하는 것이기 때문이라고 가정하고 원본 파일을 올리지 않는 것 같다.

[ upload 진행 중 ]

약 1~5초 정도가 지나면 화면 문구가 "" 형태로 변환될 것이다. 이때, <업로드된 url>은 실제로 주소창에서 호출하면 해당 이미지가 뜨기 때문에 Github는 특정 공간에 저장시키는 것을 알 수 있다. 주소가 내 Git Repository 주소가 아니기 때문에 아마도 시간이 어느정도 지난후 Image를 포함하는 Issue나 PR이 필요없어질 때 쯤? 아니면 Git Repository가 삭제되면? 등의 특정 시간에 제거되지 않을까 생각된다. 하지만, 일반적으로 Issue나 PR은 오랜시간 동안 유지되는 글이 아니기 때문에, 상관없을 것이다.

[ upload 완료 ]

만약, 2개 이상의 사진을 추가하고 싶다면, 앞에서 했던 것과 동일하게 간단히 끌어다 놓으면 된다. 추가된 그림도 일반적인 글처럼 인식한다. 다시 말해서, 그림을 추가한다고 해서 자동으로 엔터가 붙지 않는다. 아래 그림은 세로와 가로로 작성 하는 방법을 나눠놨지만, 간혹 첨부된 이미지 이름이 길기 때문에 아래 그림처럼 내가 엔터를 쳤는지, 치지 않았는지 헷가릴 때가 있다. 따라서, 이미지가 세로로 보이기를 원한다면 그림 + 엔터, 이미지가 가로로 보이기를 원한다면 그림 + 스페이스로 작성하면 된다.

[ 2개 이미지 upload 완료 ]

너무 큰 이미지를 삽입하거나 너무 작은 이미지를 삽입해서 이미지의 크기를 조정하고 싶은 경우가 있다면, 위 첨부한 그림처럼 HTML 태그의 <img> 태그를 사용하면 된다. 앞 설명에서 이미지를 끌어다 놓은 순가 이미 Github에 이미지는 업로드되며 URL이 출력된다고 하였다. 이를 이용하면 <img src="<업로드된 url>">로 변경할 수 있다. 그리고 <img> 태그에서 제공하는 width 속성을 이용하면 삽입되는 이미지의 크기 또한 조절이 가능하다. 아래 화면은 위의 Issue 글이 작성되었을 때의 모습이다.

[ 2개 이미지 upload 완료 화면 ]

README.md 파일에 Image 올리기

리서치 해본 결과, 아래의 4가지 방법들을 사용해서 Image를 업로드하는 방법을 찾을 수 있었다. 개인적으로 [방법1]과 [방법3]이 사용하기에 적당할 것이라고 생각된다. README.md 파일을 빨리 작성해서 누군가 보여줘야 한다면 [방법1]을 사용하고, 누군가에게 프로젝트를 배포해야한다거나 장기간 안정적으로 유지되어야하는 프로젝트에 작성되어야하는 README.md 파일을 만들어야 한다면 [방법3]을 사용하는 것이 적당할 것이라고 생각된다. 

[방법1] Issue와 PR을 이용해서 Image를 올린 후, 링크를 거는 방법 (=이미지를 Github가 관리하는 어딘가에 보관 / 언제 없어질지 모름)

1. 위에서 설명했던 것처럼 Issue와 PR을 통해 사진을 삽입한 후, 글 작성을 완료한다.

2. README.md에 업로드된 이미지 URL을 링크로 삽입한다.

[방법2] Issue와 PR을 이용해서 Image를 올린 후, 링크를 거는 방법 (=이미지를 Github가 관리하는 어딘가에 보관 / 언제 없어질지 모름)

1. 위에서 설명했던 것처럼 Issue와 PR을 통해 사진을 삽입한 후, 글 작성을 완료하지 않는다.

2. README.md에 업로드된 이미지 URL을 링크로 삽입한다.

[방법3] Git에 직접 Image를 올린 후, 링크를 거는 방법 (=이미지를 Repository에서 직접 보유하는 방법)

1. Image가 사용될 Git Repository에 directory를 생성하고 Image를 올린다.

2. README.md에 업로드된 이미지 URL을 링크로 삽입한다.

[방법4] Git에 직접 Image를 올린 후, 링크를 거는 방법 (=이미지 전용 Repository 생성하는 방법)

1. Image와 관련없는 Git Repository에 directory를 생성하고 Image를 올린다.

2. README.md에 업로드된 이미지 URL을 링크로 삽입한다.

README.md 파일에 이미지를 삽입할 때는 아래처럼 마크다운 포멧으로 혹은 HTML 포멧으로 작성하면 된다.

마크다운 포멧으로 작성
![<이미지 이름>](<업로드된 이미지 URL>)
![sample](https://...../sample.png)

HTML 포멧으로 작성
<img src="<업로드된 이미지 URL>">
<img src="https://...../sample.png">

참고

: https://caileb.tistory.com/201

구조화 프로그래밍, 모듈화 프로그래밍

1990 년대초에 객체지향 프로그래밍(Object-Oriented Programming)이라는 방법이 나타나기 전까지는 파스칼 또는 C를 중심으로한 구조화/모듈화 프로그래밍(Structured/Modular Programming)이 전세계를 지배하고 있었습니다.

2002 년을 보내고 있는 현시점까지도 웹프로그래밍 언어인 PHP에서는 구조화/모듈화 프로그래밍의 지배를 받고 있지요. 그러나 구조화/모듈화 프로그래밍에는 많은 문제가 있기 때문에 PHP도 객체지향 프로그래밍쪽으로 점점 무게가 실리게 될 것입니다.

어쨌든지간에 현재까지도 PHP를 지배하고 있는 구조화/모듈화 프로그래밍에 대하여 먼저 알아보고 그 다음에 과연 구조화/모듈화 프로그래밍을 할 때도 과연 객체지향 프로그래밍의 도구인 클래스를 사용해야 하는가에 대하여 숙고해 보도록 하겠습니다.

그럼 우선 클래스의 필요성을 살펴보기 전에 구조화/모듈화 프로그래밍에 대하여 살펴보도록 하겠습니다.

1970 년대에 제안된 구조적 기법(구조화/모듈화 프로그래밍)을 통하여 프로그래머는 체계적인 방법으로 보다 쉽게 프로그램을 작성할 수 있을 뿐만 아니라, 일단 작성된 프로그램은 누구나가 쉽게 읽고 이해할 수 있어서 이후에 프로그램을 쉽게 수정할 수 있었습니다.

구조화 프로그래밍(Structured Programming)

프로그램이 커지고, 기능이 복잡해지면 개발 뿐만 아니라 수정과 유지 보수에 오히려 더 많은 시간과 노력이 필요하게 됩니다. 이러한 문제에 대처하기 위하여 프로그램의 구조를 순차, 선택, 반복 제어 구조만으로 설계하여 처리 절차를 간단하고 명료하게 표현할 수 있는 구조화 프로그래밍 기법이 나타나게 되었습니다.

▶순차 처리
▶선택 처리
▶반복 처리

그 옛날 BASIC에서의 Go To문과 같은 분기를 허용하지 않고 일의 순서에 따라 시작부터 끝까지 한 방향으로 진행하도록 처리하는 것이 "순차 처리"이며, if 또는 switch 문과 같이 주어진 조건에 따라 명령문을 선택하여 처리하는 구조가 "선택 처리"이며, while, for next 문과 같이 주어진 조건을 만족할 때까지 일정한 범위의 명령문들을 반복 수행하는 구조가 "반복 처리" 구조입니다.

구조화 프로그래밍은 프로그램의 구조가 논리적으로 구성되어 있어 아래와 같은 특징을 가지게 됩니다.

▶코딩이 쉽다(분석,설계,제작)
▶프로그램을 읽기 쉽게 한다(가독성)
▶테스트를 쉽게 한다(테스트)
▶수정하기 쉽다(유지 보수)

모듈화 프로그래밍(Modular Programming)

프로그램을 작성할 때 큰 프로그램을 한번에 작성하는 것이 아니라 기능별로 나누어 우선 부분별 작성을 한 다음, 각각의 작은 프로그램들을 서로 연결시켜 하나의 완성된 프로그램을 만드는 방법으로 기능별로 나누어진 각 모듈은 각각 이 하나의 기능을 수행하며 그 기능을 수행하기 위하여 필요한 모든 코드와 변수를 포함하도록 하는 프로그래밍 방식입니다.

프로그램 덩치가 큰 프로그램을 모듈별로 나누지 않고 단지 구조화 프로그래밍만을 이용하여 하나로 작성하기는 무척 어렵습니다. 그러나 구조화 프로그래밍을 적용하기 전에 먼저 모듈화 프로그래밍을 적용한 후에 각 모듈별로 구조화 프로그래밍을 적용하게 되면 그 구현이 매우 쉽게 됩니다.

모듈화 프로그램밍은 아래와 같은 특징을 가짐으로 말미암아 구조화 프로그래밍과 마찬가지로 프로그램의 구조가 논리적으로 구성되어 있어 프로그램의 작성/수정이 용이하고, 이해하기가 쉽습니다.

▶하나의 모듈은 유일한 하나의 입구(Entry point)와 유일한 출구(Exit point)를 갖는다.
▶하나의 모듈은 독립적인 구조를 갖는다.
   (프로그램내에서 하나의 독립적인 기능을 수행)
▶모듈은 개별적으로 테스트가 가능하다.

참고 

: phpclass닷컴

gethostbyname() 함수

도메인(문자열) 정보로 ip, 별칭 등 host에 대한 정보를 구하는 함수.

#include <netdb.h>

struct hostent *gethostbyname(const char *name);

서버 이름 또는 도메인(예. www.it-note.kr)으로부터 주소정보(IP Address)를 얻습니다. 주소 정보는 local computer의 /etc/hosts 파일 또는 DNS 서버로 부터 주소 정보를 얻습니다.

struct hostent 구조체

struct hostent {
    char  *h_name;            /* official name of host */
    char **h_aliases;         /* alias list */
    int    h_addrtype;        /* host address type : AF_INET 또는 AF_INET6 */
    int    h_length;          /* length of address */
    char **h_addr_list;       /* list of addresses */
}

#define h_addr h_addr_list[0] /* for backward compatibility */ 

파라미터

name
    - IP 주소를 얻으려는 서버 이름 또는 서버에 대한 도메인명

RETURN

NULL
    - 오류가 발생하였습니다.

NULL 아님
    - struct hostent *를 return하며, 주소는 h_addr 멤버 변수에 저장되며, 
      그 주소의 길이는 h_length에 저장됩니다.
    - h_addr의 format은 network byte order의 주소이며, 
      인터넷 표준 점표기법으로 표시하려면 inet_ntoa( )로 변환이  필요합니다.

활용 예제

Sample

#include <stdio.h>
#include <errno.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>

#define SERVER_PORT   6905
#define SERVER_NAME   "www.it-note.kr"

......

int main(int argc, char **argv)
{
    struct hostent *he;
    struct sockaddr_in server_addr;
    int  sock;

    ......

    if((he = gethostbyname(SERVER_NAME)) == NULL) {
        fprintf(stderr, "%s는 등록되지 않은 서버명입니다.\n", SERVER_NAME);
        return -1;
    }

    memset(&server_addr, 0x00, sizeof(struct sockaddr_in));
    server_addr.sin_samily = AF_INET;
    memcpy(server_addr.sin.sin_addr, he->h_addr, he->h_length);
    server_addr.sin_port   = htons(SERVER_PORT);

    if((sock = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
        fprintf(stderr, "Socket 생성 오류: %s\n", strerror(errno));
        return -1;
    }

    if(connect(sock, (struct sockaddr *)&server_addr, sizeof(struct sockaddr_in)) == -1) {
        fprintf(stderr, "Connection Error: %s\n", strerror(errno));
        close(sock);
        return -1;
    }

    ......
}

참고 :
https://www.it-note.kr/22

basename() 함수 - 파일 이름 반환

1. basename - 역할

주어진 경로에서 파일 이름만 반환하는 함수.

1.1. 구문형식

basename(경로 , 접미사)

- 접미사가 입력되면 파일 이름에서 해당하는 접미사는 제거됨

2. basename - 예제

2.1. 코드

<body>
<?php
    
    $test_path = "/home/work/menu/test.php";
    
    echo basename ($test_path);
    echo "<br>";
    echo basename($test_path,".php");
?>
</body>

2.2. 결과화면

2.3. 설명

test_path는 경로를 나타내고 있고 basename() 함수를 통하여 파일 이름만 반환하고 있다.

참고 :

https://devjhs.tistory.com/211

[VB6.0] 내부함수 __vbaStrCopy

__vbaStrCopy 함수는 값을 복사해오는 함수로 보인다.

__vbaStrCopy

​

[int] __vbaStrCopy( BSTR* Source, BSTR* Destination );

​

This routine copies a BSTR from one memory location to another.

The Source BSTR is placed in EDX, the Destination BSTR is placed in ECX.

The return value is an integer in EAX which is a duplicate pointer to the Destination.

​

Code Example:

​

.text:00401961 mov edx, offset aString ; "STRING"

.text:00401966 lea ecx, [ebp-1Ch]

.text:00401969 mov [ebp-1Ch], esi

.text:0040196C call ds:__vbaStrCopy

.text:00401972 mov eax, [ebp-1Ch]

​

​

Explanation of code example:

​

You can see the string being moved into EDX and then a stack location into ECX. The copied string is then at both [ECX] and [EDX] and the return value in EAX is the same pointer as [ECX].

​

​

(c) 2004 Telos & SneakCharm

​

한글 번역

__vbaStrCopy

​

[int] __vbaStrCopy( BSTR* Source, BSTR* Destination );

​

이 루틴은 한 메모리 위치에서 다른 메모리 위치로 BSTR을 복사합니다.

Source BSTR은 EDX에 배치되고 Destination BSTR은 ECX에 배치됩니다.

반환 값은 목적지에 대한 중복 포인터인 EAX의 정수입니다.

​

코드 예제 :

​

.text:00401961 mov edx, offset aString ; "STRING"

.text:00401966 lea ecx, [ebp-1Ch]

.text:00401969 mov [ebp-1Ch], esi

.text:0040196C call ds:__vbaStrCopy

.text:00401972 mov eax, [ebp-1Ch]

​

​

코드 예제 설명 :

​

문자열이 EDX로 이동한 다음 스택 위치가 ECX로 이동하는 것을 볼 수 있습니다. 그러면 복사된 문자열은 [ECX]와 [EDX]에 모두 있으며 EAX의 반환 값은 [ECX]와 동일한 포인터입니다.

​

​

(c) 2004 Telos & SneakCharm

​

​

추가 ++)

BSTR에 대해... BSTR이란 무엇인가??

http://golbeng.egloos.com/86921

문자열을 표현하는 방법에는 다음과 같은 두가지 방법이 있다.

​

1. 일련의 문자들을 기록한 뒤, 맨 끝에 문자열의 끝을 나타내는 특별한 식별자를 기록한다.

2. 맨 앞에 문자열을 나타내는 총 바이트 수를 기록한 뒤, 일련의 문자들을 기록한다.

​

1번의 경우에 해당하는 대표적인 경우가 C/C++의 문자열이다.

C/C++에서는 문자열의 끝을 나타내기 위해 널(NULL) 문자를 사용한다.

​

2번의 경우에 해당하는 경우는 베이직이나 파스칼의 문자열이다.

​

우리가 다루고자 하는 BSTR도 바로 2번과 같은 형태를 가진 문자열이다.

자, BSTR에 대해 알아보자.

​

BSTR 타입은 마이크로소프트의 비주얼 베이직 개발팀에 의해 만들어 졌다.

비주얼 베이직은 포인터를 지원하지 못했기 때문에, 기존의 가상함수 테이블을 이용한

함수 호출이 불가능하였다. 이에 비주얼 베이직 개발팀은 IDispatch 인터페이스를

고안해 내었다. 비주얼 베이직과 COM 객체가 원활히 통신하기 위해서 COM에서 비주얼

베이직의 문자열 타입을 지원하게 되는 결과를 낳았는데, 그것이 바로 BSTR이다.

​

그래서, 이름이 BSTR(Basic STRing의 약자이다!)이기도 하다.

​

또한, BSTR는 COM에서 유니코드(Unicode) 문자열을 나타내는데 자주 사용된다.

​

비주얼 베이직(BSTR)는 개념적으로 2개의 필드로 구성된다.

​

첫번째 필드는 4바이트(unsigned long)로 구성되고, 실제 문자열의 총 바이트 수를 나타낸다.

(유니코드 문자들의 총 개수가 아니라, 바이트 수임에 명심하라!)

​

두번째 필드는 실제 문자열이며, NULL로 끝난다.

(다른 형식의 문자열과 호환성을 위해서 NULL로 끝나는 것 같다.)

(첫번째 필드에 기록된 총 바이트 수는 NULL 문자를 제외한 것임에 또한 명심하라!)

​

또한, 두번째 필드에 기록되는 문자들은 2바이트로 구성된다. 유니코드 문자이기 때문이다.

​

이렇듯 BSTR는 실질적으로 두 개의 필드로 구성되어 있다.

​

그러나, BSTR 타입은 표준 유니코드 문자 포인터에 지나지 않는다.

(실제로 BSTR 타입은 typedef OLECHAR __RPC_FAR* BSTR 로 정의되어 있다.

OLECHAR __RPC_FAR* 를 나타내는 타입인 것이다. OLECHAR은 결국 wchar_t의

다른 이름일 뿐이다.)

​

BSTR 포인터는 BSTR 타입 데이터의 두번째 필드, 즉 실제 문자열 부분을 가리킨다.

BSTR는 이렇게 정의되기 때문에 두 개의 필드로 구성됨을 알 필요없이,

보통의 유니코드 문자열과 똑같이 다룰 수 있는 것이다.

​

또한 BSTR 문자열은 COM에서 대표적으로 사용되는 유니코드 문자열이고,

COM은 다른 프로세스, 다른 컴퓨터 사이에서 사용될 수 있다.

그러므로 BSTR 문자열을 위한 메모리 할당/해제를 위해서 언어 종속적인

기능(new/delete, malloc/free ...)을 사용해서는 안된다.

​

COM이 제공하는 메모리 할당기로부터 할당/해제되어야 한다.

​

COM의 메모리 할당기를 사용하면서, 사용하기 편하게 하기 위해서

COM은 BSTR 문자열에 관한 API들을 제공한다.

​

SysAllocString(), SysFreeString(), SysReAllocString, SysStringLen()가 같이

"Sys.."로 시작하는 함수들이 그러한 COM이 제공하는 API 함수이다.

참고 : 

https://blog.naver.com/huangha/221738850374