shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
리소스만 포함하는 DLL은 리소스 DLL이라고 불릴 수 있다. 예시로는 일반 확장자 codice_4을 가진 아이콘 라이브러리, 그리고 일반 확장자 codice_5 및 codice_6을 가진 글꼴 라이브러리가 있다.
DLL의 파일 형식은 실행 파일(일명 EXE)과 동일하다. DLL 파일과 EXE 파일의 주요 차이점은 운영 체제가 실행을 시작하기 위해 엔트리 포인트를 요구하기 때문에 DLL을 직접 실행할 수 없다는 점이다. 윈도우는 DLL이 노출하는 함수를 실행하기 위한 유틸리티 프로그램(RUNDLL.EXE/RUNDLL32.EXE)을 제공한다. 동일한 형식을 가지므로 EXE도 DLL로 사용될 수 있다. 소비 코드는 DLL을 로드하는 것과 동일한 메커니즘을 통해 EXE를 로드할 수 있다.
마이크로소프트 윈도우의 초기 버전은 단일 주소 공간에서 프로그램을 함께 실행했다. 모든 프로그램은 그래픽 사용자 인터페이스(GUI)가 멀티태스킹하고 최대한 응답할 수 있도록 CPU를 다른 프로그램에 양보하여 협력하도록 되어 있었다. 모든 운영 체제 수준 작업은 기본 운영 체제인 MS-DOS에 의해 제공되었다. 모든 상위 수준 서비스는 윈도우 라이브러리 "동적 링크 라이브러리"에 의해 제공되었다. 드로잉 API, 그래픽 장치 인터페이스(GDI)는 codice_7라는 DLL에 구현되었고, 사용자 인터페이스는 codice_8에 구현되었다. DOS 위에 있는 이러한 추가 레이어는 1메가바이트 미만의 RAM을 가진 컴퓨터에서 윈도우가 작동할 수 있도록 할 뿐만 아니라 프로그램들이 서로 협력할 수 있도록 모든 실행 중인 윈도우 프로그램에서 공유되어야 했다. GDI의 코드는 드로잉 명령을 특정 장치에서의 작업으로 변환해야 했다. 디스플레이에서는 프레임 버퍼의 픽셀을 조작해야 했다. 프린터에 그릴 때는 API 호출이 프린터 요청으로 변환되어야 했다. 제한된 장치 세트(예: 컬러 그래픽스 어댑터 디스플레이, HP 레이저젯 프린터 명령 언어)에 대한 하드코딩된 지원을 제공할 수 있었지만, 마이크로소프트는 다른 접근 방식을 선택했다. GDI는 "장치 드라이버"라고 불리는 다른 코드 조각을 로드하여 다른 출력 장치와 작동하도록 했다.
GDI가 다른 장치 드라이버를 로드할 수 있게 한 동일한 아키텍처 개념은 윈도우 셸이 다른 윈도우 프로그램을 로드하고, 이러한 프로그램들이 공유 USER 및 GDI 라이브러리에서 API 호출을 호출할 수 있게 했다. 그 개념이 바로 "동적 링크"였다.
기존의 비공유 정적 라이브러리에서는 코딩 단계에서 실행 파일이 빌드될 때 호출 프로그램에 코드 섹션이 단순히 추가된다. 두 프로그램이 동일한 루틴을 호출하는 경우, 해당 루틴은 두 프로그램의 링크 단계에서 모두 포함된다. 동적 링크에서는 공유 코드가 단일의 별도 파일에 배치된다. 이 파일을 호출하는 프로그램은 런타임에 운영 체제(또는 윈도우 초기 버전의 경우 OS 확장)가 바인딩을 수행하면서 연결된다.
초기 버전의 윈도우(1.0 ~ 3.11)의 경우 DLL은 전체 GUI의 기반이 되었다. 따라서 디스플레이 드라이버는 단순히 .DRV 확장자를 가진 DLL로, 통합된 장치 드라이버 인터페이스(DDI)를 통해 동일한 드로잉 API의 사용자 지정 구현을 제공했으며, 드로잉(GDI) 및 GUI(USER) API는 단순히 .EXE 확장자를 가진 GDI 및 USER 시스템 DLL이 내보내는 함수 호출이었다.
동적으로 로드되는 라이브러리 컬렉션에서 운영 체제를 구축하는 이 개념은 윈도우의 핵심 개념이며 현재까지 유지되고 있다.
DLL은 공유 라이브러리의 표준 이점인 모듈화를 제공한다. 모듈화를 통해 여러 애플리케이션에서 공유되는 단일 자체 포함 DLL의 코드와 데이터를 애플리케이션 자체를 변경하지 않고도 변경할 수 있다.
모듈화의 또 다른 이점은 플러그인을 위한 일반 인터페이스를 사용하는 것이다. 애플리케이션 자체를 수정하지 않고도 기존 애플리케이션에 이전 모듈과 새로운 모듈을 런타임에 원활하게 통합할 수 있는 단일 인터페이스가 개발될 수 있다. 이러한 동적 확장성 개념은 액티브X의 기반이 되는 컴포넌트 오브젝트 모델에서 극대화된다.
윈도우 1.x, 2.x, 3.x에서는 모든 윈도우 응용 프로그램이 동일한 주소 공간과 메모리를 공유했다. DLL은 이 주소 공간에 한 번만 로드되었으며, 그 이후로는 라이브러리를 사용하는 모든 프로그램이 DLL에 액세스했다. 라이브러리의 데이터는 모든 프로그램에서 공유되었다. 이는 간접적인 형태의 프로세스 간 통신으로 사용될 수도 있었고, 의도치 않게 다른 프로그램을 손상시킬 수도 있었다. 윈도우 95에서 32비트 라이브러리가 도입되면서 각 프로세스는 자체 주소 공간에서 실행되었다. DLL 코드는 공유될 수 있지만, 공유 데이터가 라이브러리에 의해 명시적으로 요청되지 않는 한 데이터는 비공개이다. 그러나 윈도우 95, 윈도우 98, 윈도우 미의 상당 부분은 16비트 라이브러리로 구축되었으며, 이는 출시 당시 펜티엄 프로 마이크로프로세서의 성능을 제한하고 궁극적으로 DOS 기반 윈도우 버전의 안정성과 확장성을 제한했다.
DLL 기술은 윈도우 아키텍처의 핵심이지만 단점도 있다.
DLL 지옥.
DLL 지옥은 잘못된 버전의 DLL이 사용될 때 애플리케이션이 비정상적으로 동작하는 것을 설명한다. 완화 전략은 다음과 같다.
공유 메모리 공간.
DLL의 실행 코드는 호출 프로세스의 메모리 공간에서 동일한 접근 권한으로 실행된다. 이는 사용 시 오버헤드가 적다는 것을 의미하지만, DLL에 어떤 종류의 버그가 있을 경우 호출 프로그램에 대한 보호가 거의 없다는 것을 의미하기도 한다.
업그레이드 가능성.
DLL 기술은 소비 구성 요소를 다시 컴파일하거나 다시 링크할 필요 없이 애플리케이션을 수정할 수 있도록 한다. DLL을 교체하면 다음번에 애플리케이션을 실행할 때 새로운 DLL 버전을 사용한다. 올바르게 작동하려면 DLL 변경 사항이 하위 호환성을 유지해야 한다.
운영 체제도 DLL을 통해 애플리케이션에 노출되기 때문에 업그레이드할 수 있다. 시스템 DLL을 교체하면 다음번에 애플리케이션을 실행할 때 새로운 시스템 DLL을 사용한다.
윈도우 API에서 DLL 파일은 섹션으로 구성된다. 각 섹션은 쓰기 가능 또는 읽기 전용, 실행 가능(코드용) 또는 비실행 가능(데이터용) 등 자체 속성 집합을 갖는다.
DLL의 코드는 일반적으로 DLL을 사용하는 모든 프로세스 간에 공유된다. 즉, 물리적 메모리의 한 곳을 차지하며, 페이지 파일의 공간을 차지하지 않는다. 윈도우는 DLL에 대해 위치 독립 코드를 사용하지 않는다. 대신, 코드는 로드될 때 재배치되어 DLL을 로드하는 첫 번째 프로세스의 메모리 공간에서 사용 가능한 위치에 모든 진입점의 주소를 고정한다. 모든 실행 중인 프로세스가 단일 공통 주소 공간을 차지했던 이전 버전의 윈도우에서는 DLL 코드의 단일 복사본이 모든 프로세스에 항상 충분했다. 그러나 각 프로그램에 대해 별도의 주소 공간을 사용하는 최신 버전의 윈도우에서는 각 프로그램이 DLL 코드를 수용할 수 있는 동일한 가상 주소를 가지고 있는 경우에만 여러 프로그램에서 동일한 재배치된 DLL 복사본을 사용할 수 있다. 일부 프로그램(또는 이미 로드된 DLL의 조합)에 해당 주소가 비어 있지 않으면, 다른 재배치된 진입점 세트를 사용하여 DLL 코드의 추가 물리적 복사본을 생성해야 한다. 코드 섹션이 차지하는 물리적 메모리를 회수해야 하는 경우, 해당 내용은 버려지고 필요할 때 DLL 파일에서 직접 다시 로드된다.
코드 섹션과 달리 DLL의 데이터 섹션은 일반적으로 비공개이다. 즉, DLL을 사용하는 각 프로세스는 DLL의 모든 데이터의 자체 사본을 갖는다. 선택적으로 데이터 섹션을 공유하여 이 공유 메모리 영역을 통해 프로세스 간 통신을 허용할 수 있다. 그러나 사용자 제한이 공유 DLL 메모리 사용에 적용되지 않으므로, 이는 보안 허점을 생성한다. 즉, 한 프로세스가 공유 데이터를 손상시킬 수 있으며, 이는 다른 모든 공유 프로세스가 원치 않는 방식으로 동작하게 할 가능성이 높다. 예를 들어, 게스트 계정으로 실행되는 프로세스가 이러한 방식으로 권한 있는 계정으로 실행되는 다른 프로세스를 손상시킬 수 있다. 이는 DLL에서 공유 섹션 사용을 피해야 하는 중요한 이유이다.
특정 실행 파일 압축기(예: UPX)에 의해 DLL이 압축되면 모든 코드 섹션이 읽기 및 쓰기로 표시되며 공유되지 않는다. 읽기-쓰기 코드 섹션은 개인 데이터 섹션과 마찬가지로 각 프로세스에 비공개이다. 따라서 공유 데이터 섹션을 가진 DLL은 여러 프로그램에서 동시에 사용될 경우 압축해서는 안 된다. 각 프로그램 인스턴스가 DLL의 자체 복사본을 가지고 있어야 하므로 메모리 소비가 증가하기 때문이다.
가져오기 라이브러리.
정적 라이브러리와 마찬가지로, DLL의 가져오기 라이브러리는 codice_9 파일 확장자로 표시된다. 예를 들어, 파일 생성 및 메모리 관리와 같은 윈도우 기본 함수의 주 동적 라이브러리인 kernel32.dll은 codice_10를 통해 링크된다. 가져오기 라이브러리와 실제 정적 라이브러리를 구별하는 일반적인 방법은 크기이다. 가져오기 라이브러리는 실제 DLL을 참조하는 심볼만 포함하고 링크 시간에 처리되므로 훨씬 작다. 그러나 둘 다 유닉스 ar 형식 파일이다.
동적 라이브러리로의 링크는 일반적으로 실행 파일을 빌드하거나 링크하여 생성할 때 가져오기 라이브러리로 링크함으로써 처리된다. 생성된 실행 파일은 모든 DLL 함수 호출이 참조되는 가져오기 주소 테이블(IAT)을 포함한다(각 참조된 DLL 함수는 IAT에 자체 항목을 포함한다). 런타임에 IAT는 별도로 로드된 DLL의 함수를 직접 가리키는 적절한 주소로 채워진다.
시그윈/MSYS 및 MinGW에서 가져오기 라이브러리는 관례적으로 codice_11 접미사를 사용하며, 윈도우 DLL 접미사와 유닉스 ar 접미사를 모두 결합한다. 파일 형식은 유사하지만 가져오기를 표시하는 데 사용되는 심볼이 다르다(codice_12 vs codice_13). GNU 바이너리 유틸리티 도구 체인이 가져오기 라이브러리를 생성하고 링크할 수 있지만, DLL에 직접 링크하는 것이 더 빠르다. MinGW의 실험 도구인 genlib은 MSVC 스타일 심볼로 가져오기 라이브러리를 생성하는 데 사용할 수 있다.
심볼 분석 및 바인딩.
DLL이 내보내는 각 함수는 숫자 서열 번호와 선택적으로 이름으로 식별된다. 마찬가지로 함수는 서열 번호 또는 이름으로 DLL에서 가져올 수 있다. 서열 번호는 DLL 내보내기 주소 테이블에서 함수의 주소 포인터 위치를 나타낸다. 내부 함수는 서열 번호로만 내보내는 것이 일반적이다. 대부분의 윈도우 API 함수는 다른 윈도우 릴리스에서도 이름만 유지되며, 서열 번호는 변경될 수 있다. 따라서 서열 번호로 윈도우 API 함수를 안정적으로 가져올 수 없다.
서열 번호로 함수를 가져오는 것은 이름으로 가져오는 것보다 약간 더 나은 성능을 제공한다. DLL의 내보내기 테이블은 이름순으로 정렬되어 있으므로 이진 검색 알고리즘을 사용하여 함수를 찾을 수 있다. 찾아진 이름의 인덱스는 내보내기 서열 번호 테이블에서 서열 번호를 찾는 데 사용된다. 16비트 윈도우에서는 이름 테이블이 정렬되지 않아 이름 조회 오버헤드가 훨씬 더 눈에 띄었다.
또한 실행 파일을 특정 DLL 버전에 바인딩할 수 있다. 즉, 컴파일 시간에 가져온 함수의 주소를 해결하는 것이다. 바인딩된 가져오기의 경우 링커는 가져오기가 바인딩된 DLL의 타임스탬프와 체크섬을 저장한다. 런타임에 윈도우는 동일한 버전의 라이브러리가 사용 중인지 확인하고, 그렇다면 가져오기 처리를 건너뛴다. 그렇지 않거나 라이브러리가 바인딩된 것과 다르면 윈도우는 일반적인 방식으로 가져오기를 처리한다.
바인딩된 실행 파일은 컴파일된 환경과 동일한 환경에서 실행될 경우 다소 빠르게 로드되고, 다른 환경에서 실행될 경우 정확히 동일한 시간에 로드되므로 가져오기를 바인딩하는 데 단점이 없다. 예를 들어, 모든 표준 윈도우 응용 프로그램은 해당 윈도우 릴리스의 시스템 DLL에 바인딩된다. 응용 프로그램의 가져오기를 대상 환경에 바인딩할 좋은 기회는 응용 프로그램 설치 중이다. 이렇게 하면 다음 OS 업데이트까지 라이브러리가 "바인딩된" 상태로 유지된다. 그러나 실행 파일의 체크섬이 변경되므로 서명된 프로그램이나 파일 버전을 관리하는 데 체크섬(예: MD5 체크섬)을 사용하는 구성 관리 도구에 의해 관리되는 프로그램에서는 수행할 수 없다. 최근 윈도우 버전이 모든 로드된 라이브러리에 대해 고정된 주소를 갖는 방식에서 벗어나면서(보안상의 이유로) 실행 파일을 바인딩할 기회와 가치가 감소하고 있다.
명시적 런타임 링크.
DLL 파일은 런타임에 명시적으로 로드될 수 있는데, 마이크로소프트에서는 이를 단순히 런타임 동적 링크라고 부른다. 이는 codice_14(또는 codice_15) API 함수를 사용하여 수행한다. codice_16 API 함수는 이름으로 내보낸 심볼을 찾는 데 사용되며, codice_17는 DLL을 언로드하는 데 사용된다. 이러한 함수는 POSIX 표준 API의 codice_18, codice_19, codice_20와 유사하다.
명시적 런타임 링크 절차는 함수 포인터를 지원하는 모든 언어에서 동일하며, 언어 구성이 아닌 윈도우 API에 의존한다.
지연 로딩.
일반적으로 DLL의 가져오기 라이브러리에 연결된 애플리케이션은 DLL을 찾을 수 없으면 시작되지 않는다. 윈도우는 애플리케이션이 필요할 수 있는 모든 DLL을 찾을 수 없는 한 애플리케이션을 실행하지 않기 때문이다. 그러나 애플리케이션은 동적 라이브러리의 지연 로딩을 허용하도록 가져오기 라이브러리에 연결될 수 있다.
이 경우 운영 체제는 애플리케이션 시작 시 DLL을 찾거나 로드하려고 시도하지 않는다. 대신, 링커에 의해 애플리케이션에 스텁이 포함되어 있어, 해당 함수 중 하나가 호출될 때 codice_14 및 codice_16를 통해 DLL을 찾고 로드하려고 시도한다. DLL을 찾거나 로드할 수 없거나 호출된 함수가 존재하지 않으면 애플리케이션은 예외를 생성하며, 이는 적절히 처리될 수 있다. 애플리케이션이 예외를 처리하지 않으면 운영 체제에 의해 잡히고 오류 메시지와 함께 프로그램이 종료된다.
지연 로딩 메커니즘은 DLL이 로드될 때 및 DLL 함수가 호출될 때 애플리케이션이 추가 처리 또는 오류 처리를 수행할 수 있도록 알림 훅을 제공한다.
컴파일러 및 언어 고려 사항.
델파이.
소스 파일에서 codice_23 대신 codice_24 키워드가 사용된다. 파일 끝에는 codice_25 절에 내보낼 함수가 나열된다.
델파이는 DLL에서 함수를 가져오기 위해 codice_26 파일이 필요하지 않다. DLL에 링크하려면 함수 선언에서 codice_27 키워드를 사용하여 DLL 이름을 지정하고, 이어서 심볼 이름(다른 경우)을 지정하는 codice_28 또는 인덱스를 식별하는 codice_29를 사용한다.
마이크로소프트 비주얼 베이직.
비주얼 베이직 (VB)에서는 런타임 링크만 지원되지만, codice_14 및 codice_16 API 함수를 사용하는 것 외에도 가져온 함수의 선언이 허용된다.
선언을 통해 DLL 함수를 가져올 때, VB는 codice_32 파일을 찾을 수 없으면 런타임 오류를 생성한다. 개발자는 오류를 잡아 적절히 처리할 수 있다.
VB에서 DLL을 만들 때 IDE는 ActiveX DLL만 만들 수 있도록 허용하지만, 사용자가 각 내보낸 함수의 순서 위치와 이름을 정의하는 .DEF 파일을 포함하도록 링커에 명시적으로 지시할 수 있는 방법이 만들어졌다. 이를 통해 사용자는 Visual Basic (버전 6 이하)을 사용하여 "Declare" 문을 통해 참조할 수 있는 표준 윈도우 DLL을 만들 수 있다.
C 및 C++.
마이크로소프트 Visual C++ (MSVC)는 C++ 표준에 여러 확장을 제공하여 함수를 C++ 코드에서 직접 가져오거나 내보낼 수 있도록 한다. 이러한 확장 기능은 GCC의 윈도우 버전을 포함한 다른 윈도우 C 및 C++ 컴파일러에서 채택되었다. 이 확장 기능은 함수 선언 앞에 codice_33 속성을 사용한다. C 함수가 C++에서 액세스될 때 C++ 코드에서도 codice_34로 선언되어야 컴파일러에 C 링크를 사용해야 한다고 알려야 한다.
codice_33 속성을 사용하여 가져오거나 내보낸 함수를 지정하는 것 외에도, 프로젝트에서 사용하는 codice_36 파일의 IMPORT 또는 EXPORTS 섹션에 나열할 수 있다. codice_36 파일은 컴파일러가 아닌 링커에 의해 처리되므로 C++에만 국한되지 않는다.
DLL 컴파일은 codice_32 및 codice_26 파일을 모두 생성한다. codice_26 파일(가져오기 라이브러리)은 컴파일 시간에 DLL에 연결하는 데 사용되며 런타임 링크에는 필요하지 않다. DLL이 컴포넌트 오브젝트 모델(COM) 서버가 아닌 한, codice_32 파일은 PATH 환경 변수에 나열된 디렉터리 중 하나, 기본 시스템 디렉터리 또는 DLL을 사용하는 프로그램과 동일한 디렉터리에 배치되어야 한다. COM 서버 DLL은 regsvr32.exe를 사용하여 등록되며, 이는 DLL의 위치와 전역 고유 ID(GUID)를 레지스트리에 배치한다. 그러면 프로그램은 레지스트리에서 GUID를 찾아 DLL의 위치를 찾거나 클래스 식별자와 인터페이스 식별자를 사용하여 COM 객체 인스턴스를 간접적으로 만들 수 있다.
프로그래밍 예시.
DLL 가져오기 사용.
다음 예시는 컴파일 시간에 DLL에 링크하기 위해 언어별 바인딩을 사용하여 심볼을 가져오는 방법을 보여준다.
델파이
// import function that adds two numbers
function AddNumbers(a, b : Double): Double; StdCall; external 'Example.dll';
// main program
R: Double;
R := AddNumbers(1, 2);
Writeln('The result was: ', R);
codice_42이 생성되었다고 가정하고 정적 링크 전에 프로젝트에 'Example.lib' 파일을 포함해야 한다. 'Example.lib' 파일은 DLL 컴파일 시 컴파일러에 의해 자동으로 생성된다. 위 문장을 실행하지 않으면 링커가 codice_43의 정의를 찾을 위치를 알 수 없어 링크 오류가 발생한다. 'Example.dll' DLL 파일도 다음 코드에 의해 .exe 파일이 생성되는 위치에 복사해야 할 수 있다.
명시적 런타임 링크 사용.
다음 예시는 언어별 윈도우 API 바인딩을 사용하여 런타임 로딩 및 링크 기능을 사용하는 방법을 보여준다.
네 가지 샘플 모두 DLL 사전 로드 공격에 취약하다는 점에 유의해야 한다. example.dll이 저자가 의도하지 않은 위치로 확인될 수 있기 때문이다(애플리케이션 디렉터리가 시스템 라이브러리 위치보다 우선하지 않고, codice_44 또는 codice_45가 없으면 현재 작업 디렉터리가 시스템 라이브러리 디렉터리보다 먼저 검색됨). 따라서 악성 라이브러리 버전에 취약하다. 마이크로소프트의 안전한 라이브러리 로딩에 대한 지침은 참조를 참조하라. 즉, 애플리케이션 디렉터리와 현재 작업 디렉터리를 DLL 검색 경로에서 제거하려면 의 를 사용하거나, 현재 작업 디렉터리를 DLL 검색 경로에서 제거하려면 의 를 사용해야 한다.
Declare Function AddNumbers Lib "Example.dll" _
(ByVal a As Double, ByVal b As Double) As Double
Debug.Print "The result was: " &amp; Result
AddNumbers:function (a, b: integer): Double; StdCall;
LibHandle:HMODULE;
LibHandle := LoadLibrary('example.dll');
if LibHandle &lt;&gt; 0 then
AddNumbers := GetProcAddress(LibHandle, 'AddNumbers');
if Assigned(AddNumbers) then
Writeln( '1 + 2 = ', AddNumbers( 1, 2 ) );
Readln;
HINSTANCE hinstLib;
hinstLib = LoadLibrary(TEXT("Example.dll"));
addNumbers = (importFunction) GetProcAddress(hinstLib, "AddNumbers");
result = addNumbers(1, 3);
파이썬 ctypes 바인딩은 POSIX 시스템에서 POSIX API를 사용한다.
import ctypes
my_dll = ctypes.cdll.LoadLibrary("Example.dll")
my_dll.AddNumbers.restype = ctypes.c_double
p = my_dll.AddNumbers(ctypes.c_double(1.0), ctypes.c_double(2.0))
print("The result was:", p)
컴포넌트 오브젝트 모델.
컴포넌트 오브젝트 모델(COM)은 DLL 및 EXE 파일에 객체의 구현을 호스팅하기 위한 바이너리 표준을 정의한다. 이는 해당 파일을 찾고 버전을 지정하는 메커니즘과 언어 독립적이고 기계 판독 가능한 인터페이스 설명을 제공한다. DLL에 COM 객체를 호스팅하는 것은 더 가볍고 클라이언트 프로세스와 리소스를 공유할 수 있도록 한다. 이를 통해 COM 객체는 Visual Basic 및 ASP와 같은 간단한 GUI 프런트엔드에 강력한 백엔드를 구현할 수 있다. 또한 스크립팅 언어에서도 프로그래밍할 수 있다.
DLL 하이재킹.
DLL 하이재킹, DLL 스푸핑, DLL 프리로드 또는 바이너리 플랜팅으로 흔히 알려진 취약점으로 인해, 많은 프로그램은 이러한 프로그램이 연 데이터 파일과 동일한 폴더에 포함된 악성 DLL을 로드하고 실행한다. 이 취약점은 2000년에 게오르기 구닌스키에 의해 발견되었다.
2010년 8월 ACROS Security가 이를 재발견하고 수백 개의 프로그램이 취약한 것으로 밝혀지면서 전 세계적으로 주목을 받았다.
안전하지 않은 위치, 즉 다운로드 또는 임시 디렉터리와 같이 사용자가 쓰기 가능한 폴더에서 실행되는 프로그램은 거의 항상 이 취약점에 취약하다.
인도네시아의 행정 구역은 총 38개의 주로 구성되어 있다. 이 가운데 아체주, 욕야카르타 특별주, 자카르타 3개 주와 서뉴기니의 6개 주는 특별주로 지정되어 있다.
안토니 필립스 판 레이우엔훅 FRS( , , 1632년 10월 24일~1723년 8월 26일)은 네덜란드의 미생물학자, 현미경 과학자이다. 미생물학의 아버지로 알려져 있으며 현미경의 발달과 미생물학의 정립에 큰 공헌을 하였다. 그는 스스로 렌즈를 갈아 만든 현미경으로 단세포 생물을 관찰하였다.
네덜란드의 델프트 출신으로 특별한 교육을 받은 적은 없으나, 여러 방면에 천재적인 재능과 흥미를 가지고 있어, 오랜 연구 끝에 현미경을 발명하였다. 그는 자신이 만든 배율 높은 확대경을 사용하여 식물의 종자 및 배(胚)의 구조와 작은 무척추동물을 관찰했을 뿐만 아니라 정자와 적혈구세포를 발견하여 동물 조직학의 창시자가 되었다. 또한 모세혈관의 혈액 순환을 발견하고 설명함으로써 반세기 전에 윌리엄 하비에 의해 시작된 혈액순환 연구를 발전시켰다.
그러나 그의 명성을 가장 높인 것은 미생물 세계의 발견이다. 즉, 그는 오늘날 우리가 알고 있는 원생동물, 조류(藻類), 효모, 세균 등 단세포 미생물을 발견하였으며, 그와 동시대인들은 이러한 단세포 미생물의 세계를 'animalcules(극미동물)' 혹은 'little animals'라 불렀다. 이로써 안토니 판 레이우엔훅은 일반적인 교육도 받지 않았지만 런던 왕립학회의 요청에 따라 이 학회의 회원이 되었으며, ("Proceedings of the Royal Society")에 그의 업적이 기록되었다.
스시() 또는 초밥(醋-)은 일본의 밥 요리이다. 쌀밥에 날생선 등의 해산물이나 달걀 등을 조합한 음식으로, 전통적으로 와사비와 함께 먹는다. 손으로 쥐어 만든 스메시(초를 친 밥)에 생선 등을 얹어 만든 니기리즈시가 대표적이지만, 그 외에도 여러 가지 형태가 있다. 일본의 국민 음식 가운데 하나로 여겨진다.
일본어 "스시()"의 어원은 "시다"는 뜻의 옛 일본어 형용사 "스시()"이다. 현대 일본어에서 "시다"를 뜻하는 말은 "스이()"이다. "스시"는 히라가나나 다른 한자를 사용해 ", ", "" 등으로 표기하기도 한다.
스시의 기원이라고 할 수 있는, 생선과 곡물을 함께 삭혀 보관하는 방법은 농경문화, 더운 날씨와 관련이 깊어 동남아시아에서 민물고기 보존용으로 곡물을 곁들인 것이 시초라고 추정된다.
이후, 스시는 중국 남부에서 일본에 전해진 것으로 여겨지나, 오늘날의 스시와는 다르다. 우리가 오늘날 스시라고 하는 것은 에도시대 중기에 그 전형이 완성되었다. 비와호 주변의 오오미 지방에서는 붕어를 밥에 절이는 방식으로 후나즈시를 만들어 먹고 있다. 단 이때 내장에 채워넣은 밥은 버리고 생선만을 밑반찬으로 먹는다. 한국의 가자미식해도 생선과 곡식(좁쌀)을 함께 염장하는 방식으로 만들어진다. 일본 스시의 시초는 이런 음식에서 출발했다.
간사이 지방에서는 상자에 밥과 생선을 넣고 돌로 눌러 모양을 만든 다음 네모나게 썰어서 먹었다. 돌로 누른다하여 오시즈시 또는 상자에 넣는다 하여 하코즈시라고도 부른다. 현대의 일본 스시는 손으로 쥐어 만들기 때문에 니기리즈시라고 부르기도 하고, 에도에서 만들어졌다하여 에도마에즈시라고 부른다. 스시라는 이름은 본래 발효된 생선에서 신맛이 났기 때문에 붙여졌다는 견해도 있는데(일어로 '스'는 식초를 뜻함), 16세기 이후 양조 식초가 발전하면서 17세기 생선의 발효 대신 식초를 사용하여 숙성과정을 거치지 않은 스시가 만들어졌고 1820년 경에 생선과 스시를 조합시키는 현대식 스시가 생겨났다. 즉 만드는데 2~3일 걸리는 오시즈시를 빠르게 만들기 위해서 식초를 치고 간을 해서 만들어 냈다. 거기에 나무상자에 채워넣고 눌러두는 것조차 기다릴 수 없어 밥을 손으로 눌러 만든 후 조미한 생선을 얹은 하야즈시가 생겨났다. 그러나 지금도 스시를 만든다(츠쿠루)고 하지 않고 젓갈처럼 담근다(츠케루)는 표현을 사용하고, 스시 식당 주방을 '담그는 장소(츠케바)'라고 부르고 있다. 스시에 사용되는 생선은 보통 날 것(활어)이 아니고 숙성된 것(선어)이다.
쌀밥이 젖산 발효되어 신맛을 내게 되는 나레즈시, 이즈시 등과 쌀밥에 식초로 간을 해 신맛을 낸 스메시에 주재료를 조합한 종류가 있다. 식사로 먹는 것은 주로 후자이다.
그 외에도 이나리즈시(유부초밥) 등의 다양한 스시가 존재한다.
인증 제도.
일본 정부 주도로 스시에 대한 인증제도 시행에 있어서 음식 국수주의라는 비판이 있다. 인증제도에 대해 일본 농수성은 "식재료나 조리법이 본래의 일식과 동떨어진 요리를 제공하고 있는 일식 식당이 증가하고 있기 때문"이라고 이유를 밝혔다. 하지만 예산확보 문제로 인해 인증제도 실행여부는 불투명하다.
사시미()는 일본식 회 요리이다. 주로 활어회로 먹는 한국식 회 문화와는 달리 일본은 주로 선어회로 먹는다. 또한 한국식 회 문화에는 초고추장, 간장, 쌈장 등의 양념이 포함되거나 이를 이용한 물회 등이 있지만, 일본의 사시미는 간장과 와사비를 제외한 양념이 포함되지 않는다.
사시미라는 단어는 "찔린 몸"을 의미한다. 즉, "刺身" = 사시미, 여기서 刺 し = 사시(찔린, 찔린 것) 및 身 = 미(몸, 고기)를 뜻한다. 이 단어는 무로마치 시대(1336~1573)부터 시작되었으며 요리 단계인 "切る" = 키루(잘라내기)라는 단어가 사무라이가 아닌 다른 사람이 사용하기에 너무 불길한 것으로 간주되었을 때 만들어졌을 가능성이 있다. 이 단어는 먹는 물고기를 식별할 목적으로 물고기의 꼬리와 지느러미를 조각에 붙이는 요리 관행에서 파생된 것일 수 있다.
이 이름에 대한 또 다른 가능성은 수확의 전통적인 방법이다. "횟감급" 생선은 개별 손으로 잡는다. 물고기가 착지하자마자 날카로운 가시로 뇌를 찔러 슬러리 얼음에 넣는다. 이 스파이킹을 이케지메 과정이라고 하며, 순간적으로 죽는다는 것은 생선 살에 최소한의 젖산이 포함되어 있음을 의미한다. 이것은 생선이 하얗게 변하거나 변질되지 않고 약 10일 동안 얼음 위에서 신선하게 유지된다는 것을 의미한다.
수많은 비일본인들은 사시미와 스시라는 용어를 같은 의미로 사용하지만 두 요리는 뚜렷하고 분리되어 있다. 스시는 식초로 만든 쌀로 만든 모든 요리를 말한다. 날생선은 전통적인 스시 재료 중 하나이지만, 많은 스시 요리에는 조리된 해산물이 포함되며, 다른 것들은 해초와 야채와 같은 재료를 포함하여 해산물이 전혀 없다. 대조적으로 사시미는 항상 자체적으로 제공된다. 일본에서는 오래전부터 생선을 날 것으로 먹는 풍습이 있었지만, 그것을 아름답게 차려낸 요리로 내놓는 아이디어는 아마도 가마쿠라 시대(1185-1333) 무렵 중국에서 온 것으로 생각된다. 1489년에 쓰여진 일본어로 된 초기 요리책에는 날고기를 썰어 식초와 소금, 허브와 같은 조미료와 섞어야 한다고 나와 있다.
고추냉이 또는 일본어식 표현인 와사비(, ) (근데 사실 고추냉이와 와사비는 다른 종류이다)는 배추과의 식물로, 일본 요리에서 뿌리를 갈아서 양념으로 쓴다. 이웃한 배추과의 식물은 겨자무와 겨자 등이 있다. 뿌리를 간 매운 맛은 겨자와 비슷하지만 고추에 들어 있는 캡사이신과는 또 다른데, 혀를 자극하기보다는 증기가 코로 올라오면서 자극하기 때문이다. 시장에서 흔히 볼 수 있는 것은 W. japonica var. Daruma와 Mazuma 두 종류이며 매우 다양한 품종이 있다.
일본어 ‘와사비’의 옛 형태중 가장 오래된 문헌 자료로는 아스카촌에서 출토된 목간에 적힌 ‘委佐俾’와 《》(918)에 기록돼 있는 ‘和佐比’ 등이 있다. 한국어 이름 ‘고추냉이’는 울릉도에서 부르는 이름인 ‘고초냉이’를 바탕으로 붙인 이름이다. 한때 울릉도의 고초냉이는 자생종으로 여겨졌으나 이후 일본에서 도입된 재배종으로 밝혀졌다.
신현철과 김영동은 "Eutrema japonicum"을 ‘겨자냉이’로 부를 것을 제안하였다.
고추냉이의 매운 맛의 성분은 갓 등 배추과 식물이 많이 포함하고 있는 유기당체(油配糖体) 중 하나인 시니그린(sinigrin)이 산소에 접촉하여 세포에 있는 효소와의 반응에 따라 생성되는 이소티오시안산 알킬(Allyl isothiocyanate) 등이며, 살균 효과도 있다. 스시에 쓰이기도 하며, 주로 간장에 섞어서 쓴다.
간장( - 醬, )은 음식의 간을 맞추는, 짠맛이 나는 흑갈색 액체 장으로, 콩을 소금물에 발효시켜 만든다. 장(醬) 또는 장유(醬油)라고도 부른다. 콩 이외에도 다른 곡식이 들어가기도 하며, 발효에 누룩곰팡이 또는 간장누룩곰팡이가 이용된다. 간장은 중국에 그 기원을 두며, 동아시아와 동남아시아에서 조미료로 널리 쓰인다. 대부분 간장은 간을 맞추는데 쓰인다.
간장이란 이름의 기원은 중국의 醬(장)으로 본다. 기원전 2세기 중반에 쓰여진 《주례》에 醬(장)이라는 한자가 처음 기록되었는데, 이때 醬(장)은 염장 발효 조미료를 두루 일컫는 말이었다. 고대 중국 황실의 醬(장)은 고기를 소금에 절여 발효시켜 만들었는데, 이는 현대에 어장을 만드는 방식과 비슷하다. 민간에 전해지면서 고기 대신 콩을 사용하게 되었다.
한국에서는 삼국시대 이전부터 된장, 간장이 섞인 걸쭉한 두장을 담가 먹다가, 삼국시대에 간장과 된장을 분리하는 기술이 생긴 것으로 보인다. 4세기에 지어진 고구려의 고분인 안악 3호분 벽화를 보면 우물가에 장을 담근 장독대가 그려져 있으며, 중국의 《삼국지》 〈위서〉 오환선비동이전 고구려 편에 "고구려가 장양(贓釀: 장 담그기, 술 빚기 등의 발효식품 제조)을 잘한다"는 기록이 있다. 683년 신문왕 3년 2월 봄 《삼국사기》에는 왕이 내물왕 8세손인 일길찬 김흠운의 딸을 왕비로 맞아들일 때 폐백 음식으로 장(醬), 메주(皼, 메주), 해(醢, 젓갈)을 준비했다는 기록이 남아 있다.
조선시대 문헌인 《구황촬요》와 《증보산림경제》에는 각각 조장법(造醬法)항과 장제품조(醬諸品條)에서 장을 잘 담그는 방법을 상세히 제시하고 있으며, 《규합총서》에는 장 제조법 뿐만아니라 장 담그는 날 택일법, 금기사항, 보관관리법 등도 기록돼 있다. 이를 보면 현재의 장 담그기와 같은 방법이 정착된 것을 알 수 있다. 《훈몽자회》에 ""이라는 표기가 나온다.
재래식.
전통적으로 입동 전후에 메주를 쓴다. 콩을 불린 다음에 물을 붓고 큰 무쇠 솥에서 삶아서 절구에 찧으면 메주밥이 되는데, 이 메주밥을 한두 되 정도 둥글거나 네모나게 빚어 서늘한 곳에서 일주일 정도 말린다. 메주가 단단해지면 볏짚으로 엮어 처마 끝에 매달아 띄우거나, 더운 온돌방에서 메주 사이 사이에 볏짚을 한 켜씩 놓아 띄운다. 이듬해 정월 경에 잘 뜬 메주를 겉을 깨끗이 씻어 햇볕에 바짝 말린다.
그 다음에는 장독에 끓인 소금물을 붓고 메주를 담가 두는데, 이때 메주가 소금물에 둥실 뜨면 간이 알맞다. 장을 담글 때 고추와 숯을 띄우기도 하는데, 이것은 숯이 불순물을 빨아들이고 고추가 살균 작용을 하기 때문이지만, 장독에 치는 금줄과 함께 주술적인 의미를 갖기도 한다.
시간이 지나 메주가 잘 발효되었을 때 소금물 안에서 삭은 메주를 꺼내고 나머지 국물을 달인 것이 간장이며, 간장을 떠낸 뒤 삭은 메주를 건져서 으깬 것이 된장이다. 담은 지 한 해가 되지 않은 진하지 않은 간장은 햇간장 또는 청장(淸醬)이라 부르며, 3-4년 묵은 것은 중간장, 5년 이상 묵어 아주 진하게 된 것은 진간장(津-醬)이라 부른다. 진간장은 진장(陳醬), 농장(濃醬), 진감장(陣甘醬)이라고도 부른다.
개량식.
재래식 메주는 콩으로만 쑤어 간장과 된장 겸용으로 먹지만, 개량식 메주는 삶은 콩에 쌀, 보리, 밀 같은 종곡을 첨가해 발효시키고 간장용과 된장용이 따로 있다. 메주에 종곡을 심으면 유기산생산균이 번식하고 효소 역가가 높아지는데, 일본식 미소와 쇼유를 만들 때도 이런 방식을 쓴다.
산분해.
한국의 간장.
한식간장.
재래식 간장으로도 부른다. 현대에는 주로 국에 넣는다 하여 국간장이라고도 부르며, 왜간장과 비교하여 이를 때는 조선간장으로, 양조장 등에서 만든 개량된 간장과 비교하여 집에서 만든 간장을 이를 때는 집간장으로 부르기도 한다.
한국의 전통적인 방법으로 만드는 간장으로, 비교적 색이 연하고 짠맛이 강하다. 콩으로 만든 메주를 소금물에 담가 발효시킨 뒤, 우려낸 국물을 떠내어 솥에 붓고 달여서 만든다. 한식메주를 주원료로 하는 것은 재래한식간장으로, 개량메주를 주원료로 하는 것은 개량한식간장으로 부른다.
개량간장.
한식간장과는 달리 메주를 쓰지 않고 만든 간장으로, 개화기 이후 들어온 일본식 간장이라 하여 왜간장으로도 부른다. 한식간장에 비해 짠맛이 약하고 색이 진하다. 색이 엷은 국간장과 구분해 진간장이라 부르기도 한다.
양조간장.
양조간장()은 대두(콩), 탈지대두(기름을 짜낸 콩) 또는 곡류 등을 증자하고 종국을 첨가한 후 제국실에서 배양하여 얻은 효소 활성이 있는 국을 식염수 등을 섞어 발효와 숙성시킨 후 그곳에서 나온 액체를 가공한 것을 말한다. 이때 탈지대두는 7.0% 이상이어야 하며, 대두 또는 탈지대두를 섞어서 사용하는 경우에는 9.0% 이상이어야 한다.
산분해간장.
단백질을 함유한 원료를 (염산 등의) 산으로 녹여서 가수 분해한 후, 수산화 나트륨 또는 탄산 나트륨으로 중화하여 아미노산을 만든 후 소금과 첨가물을 넣어 제조한 것을 말한다. 화학간장이나 아미노산간장이라고도 부른다.
효소분해간장.
혼합간장.
혼합간장은 여러 가지 방법으로 만들 수 있다. 한식간장 또는 양조간장에 산분해간장 또는 효소분해간장을 적절한 비율로 혼합하여 가공하거나, 산분해간장의 원액에 단백질 또는 탄수화물 원료를 첨가하여 발효, 숙성시킨 액체를 가공한 것은 혼합간장이다. 그 외에 이 원액에 양조간장 원액이나 산분해간장 원액 등을 적정 비율로 혼합하여 가공한 것 또한 혼합간장이라 부른다.
어간장.
어간장()은 어장이나 생선간장이라고도 부른다. 콩으로 만드는 간장과 달리 물고기의 단백질을 사용해 만든다. 영어권에서는 콩으로 만드는 소이소스()와 구별해 피시소스()로 부른다.
다른 나라의 간장.
중화권.
인도네시아에서는 간장 등 소스가 케찹()이라 불린다. 케첩과 어원이 같다. 걸쭉한 단간장()이 기본으로 쓰이는데, 야자설탕이 들어가 당밀 같은 맛이 난다. 달지 않은 짠간장()도 사용되며, 간장 외에 어장()과 우스터셔 소스()를 일컬을 때도 kecap이라는 낱말이 사용된다.
태국에서는 간장을 시이우()라고 부른다. 간을 맞출 때는 흰간장()을 사용하며, 검은간장()은 음식에 색을 내기 위해 쓴다. 단간장()은 음식을 찍어먹을 때 사용한다. 그 외에 "맛내기 소스"라고도 불리는 맛간장()이 있다.
간장의 염분농도는 보통 18‒20%이며, 간장이 갈색을 띠는 것은 아미노산이 분해되어 생기는 멜라닌과 멜라노이딘 때문이다. 간장의 냄새를 구성하는 성분으로는 알코올, 케톤, 알데하이드, 휘발성 산, 에스터, 페놀 등이 있으며, 간장의 고유한 맛은 베타-메틸 메르캅토프로필 알코올에서 나온다. 그리고 간장을 과다하게 섭취할 경우 신장 기능이 약해지고, 대장용종 등 각종 부작용을 일으킬 수도 있다. 그 외에도 짠 맛에 익숙해지게 되므로 암 등 건강을 더 해치울 수도 있게 된다.
두부(豆腐, )는 콩으로 만든 식품의 한 가지로, 물에 불린 콩을 매에 갈아 자루에 넣고 짜서 간수를 넣어 엉기게 한 것이다. 콩물에 간수 등을 넣어 굳혀서 각지게 만든 가공식품이다. 콩물로 두부를 만드는 것은 우유에서 치즈를 얻어 내는 것과 비슷한 기술이다. 아시아 음식이나 채식 음식에서, 튀긴 형태의 밀고기(밀가루의 글루텐으로 고기처럼 만든 음식)가 종종 두부로 오해되기도 한다. 순두부나 연두부는 두부를 만드는 과정을 약간 달리한 것이다. 비지는 두부 생산과정의 부산물이다.
은은한 향이 있어 고소하고 달콤한 요리에 활용하기 좋다. 요리와 맛에 맞게 양념하거나 재워두는 경우가 많으며, 쫄깃한 식감으로 인해 맛을 잘 흡수한다. 이는 동아시아 및 동남아시아 요리의 전통적인 구성 요소이며 중국에서는 2,000년 이상 소비되어 왔다. 현대 서양 요리에서는 고기 대용품으로 취급되는 경우가 가장 많다.
영양학적으로 두부는 칼로리가 낮으면서도 단백질 함량이 비교적 높다. 철 함량이 높으며 제조에 사용되는 응고제(예: 염화칼슘, 황산칼슘, 황산마그네슘)에 따라 칼슘 또는 마그네슘 함량이 높을 수 있다.
두부 제조는 약 2000년 전 중국 한 왕조 시대에 처음으로 기록되었다. 중국 전설에 따르면 이 발명품은 안후이성의 류안 왕자(기원전 179~122년)가 발명했다고 한다. 두부와 그 생산 기술은 나라 시대(710~794)에 일본에 소개되었다. 일부 학자들은 두부가 베트남에 10세기와 11세기에 들어왔다고 믿고 있다.  두부는 동남아시아의 다른 지역으로도 퍼졌다. 두부는 동아시아 불교의 채식 식단에서 중요한 단백질 공급원이기 때문에 이는 불교의 확산과 일치했을 것으로 추정한다. 명나라 때의 이시진은 『본초강목』에 두부를 만드는 방법을 기술했다. 이후 두부는 지역에 따라 생산 방법, 식감, 풍미, 용도가 다양해 베트남, 태국, 한국 등 많은 국가에서 주식이 되었다.
두부의 기원에 관한 세 가지 이론 중 가장 일반적으로 받아들여지는 이론은 두부가 한 왕조의 왕자인 류안 공에 의해 발견되었다는 것이다. 그럴듯하지만, 이 기간 동안 신뢰할 수 있는 출처가 부족하여 이를 최종적으로 결정하기가 어렵다. 중국 역사에서 중요한 발명품은 당시의 중요한 지도자와 인물의 것으로 여겨지는 경우가 많다. 1960년, 동부 한 왕조의 무덤에서 발굴된 석조 벽화는 두부의 한 유래 이론을 뒷받침했다. 그러나 일부 학자들은 한 왕조 시대의 두부는 초보적이었고 두부로 간주되기에는 단단함과 맛이 부족했다고 주장한다.
두부의 제조법은 콩을 삶아 갈아 만든 슬러리에 불순물이 섞인 천일염을 섞어 우연히 발견했다는 설도 있다. 그러한 바다 소금에는 아마도 칼슘과 마그네슘 염이 함유되어 있어서 콩 혼합물이 응고되어 두부 같은 젤을 생성하게 되었을 것이다.
마지막 그룹의 이론은 고대 중국인이 몽골인이나 동인도인의 우유 응고 기술을 모방하여 두유를 응고시키는 방법을 배웠다고 주장한다. 고대 중국 사회에는 선진 문화에도 불구하고 유제품을 재배하고 가공하는 기술이나 지식이 존재하지 않았다. 이 이론에 대한 주요 증거는 수 왕조(AD 581-618)에 요구르트나 부드러운 치즈와 같은 일관성이 있는 요리에 사용된 문자 그대로 "우유 응고"를 의미하는 중국어 용어 로푸(乳腐) 사이의 어원학적 유사성이다. 몽골의 유제품과 생산 방법, doufu(豆腐, "응고 콩") 또는 tofu라는 용어의 영향을 받았다. 흥미롭고 가능성 있는 이야기이기는 하지만 학문적 추측 이상으로 이 이론을 입증할 증거는 없다.
한국에는 언제 들어왔는지 확실치 않으나 고려 말 이색(李穡)의 『목은집』에 두부에 관한 시가 실려 있다. 그리고 두부 만드는 법은 조선 시대의 『임원십육지(林園十六志)』, 『군학회등(群學會騰)』, 『농정회요(農政會要)』에 나와 있다.
두부의 한 형태는 한나라 때 발견되었을 수도 있으나, 송나라(960~1279년)까지는 중국에서 인기 있는 음식은 아니었다.
중국에서는 전통적으로 두부를 죽은 친척의 무덤을 방문할 때 음식으로 사용했다. 귀신이 턱과 턱이 없어진 지 오래되어 두부만이 부드러워서 먹을 수 있다고 한다. 중국에 냉장 보관이 가능하기 전에는 두부가 추운 날씨에도 쉽게 상하지 않기 때문에 두부는 겨울에만 판매되는 경우가 많았다. 따뜻한 계절에는 한번 만든 두부를 하루 이상 보관하면 상하게 된다.
두부는 나라 시대(8세기 후반)에 선불교 승려들에 의해 일본에 소개되었으며 처음에는 "중국 두부"(唐腐, tofu)라고 불렀다. 임진왜란(1592~1598) 이후 한국의 의사이자 전쟁 포로에 의해 오늘날의 고치현인 도사국에 두부의 확고한 변형이 소개되었다. 동아시아에서 두부의 초기 사용의 대부분은 불교 승려, 특히 선불교를 따르는 승려들이 고기와 생선을 대체하는 채식이었다.
두부에 관한 최초의 일본 문서에는 1183년 나라의 가스가 신사에 제물로 바쳐졌던 요리가 언급되어 있다. 에도 시대 1782년에 출판된 두부백친(豆腐百珍)이라는 책에는 두부 요리법 100가지가 나와 있다.
동남아시아에서는 푸젠성에서 온 중국인 이민자들에 의해 두부가 이 지역에 도입되었다. 이는 동남아시아의 많은 국가에서 부드럽거나 단단한 두부를 의미하는 민난 중국어 단어 또는 "tāu-hū" 또는 "tāu"를 사용하여 두부를 언급하는 것으로 입증되었다. 인도네시아, 말레이시아, 싱가포르, 태국, 캄보디아, 미얀마, 필리핀, 베트남에서는 두부가 널리 사용되며 많은 현지 요리에 사용된다.
두부는 인도네시아에서 tahu라고 불린다.
두부는 말레이시아와 싱가포르에서는 타우후(tauhu)라고 불린다. 말레이시아와 싱가포르 인도인들은 인도 미고렝, 로작 파셈보르 등의 요리에 두부를 사용한다. 프라나칸 요리는 락사 피낭처럼 두부를 사용하는 경우가 많다. 인도네시아, 태국, 말레이시아, 필리핀은 두부의 주요 생산국이며 많은 지방자치단체에 공장을 두고 있다.
필리핀의 두부는 아침 식사 간식 타호(豆腐 "tāu-hū") 또는 토카(보통 튀겨지는 건조하고 단단한 두부, 즉 豆干 "tāu-goan")로 널리 먹는다. 이는 주요 식사와 수많은 지역 요리에서 고기를 대체하는 주요 재료이다. 두부는 10~13세기에 송나라 중국 선원과 상인에 의해 필리핀 식단의 주요 음식이 된 다른 많은 음식과 함께 군도에 도입되었다. 두부의 이용과 생산은 처음에는 세부나 톤도 등 영향력 있는 중국 소수민족이 거주하는 도심으로 제한되었지만, 빠르게 외딴 원주민 마을과 섬까지 퍼졌다.
제품이나 생산 규모에 관계없이 두부 생산은 기본적으로 다음으로 구성된다.
낙농동물의 젖을 응고시켜 커드를 만들고 이를 압착, 숙성시켜 치즈를 만드는 방식으로 유제품 치즈를 생산하는 것과 유사하다. 두부를 만드는 일반적인 과정은 콩을 씻고, 불리고, 물에 갈고, 여과하고, 삶고, 응고시키고, 압착하는 과정을 거친다.
삶은 두유에 부유하는 단백질과 기름(유화액)의 응고는 두부 제조에 있어서 가장 중요한 단계이다. 이 과정은 응고제의 도움으로 수행된다. 응고는 복잡한 상호작용에 따라 달라진다. 사용된 대두에 포함된 단백질의 다양성과 비율, 슬러리 조리 온도, 응고 온도 및 기타 요인을 포함하여 많은 변수가 있다.
대두 단백질은 주로 7S와 11S 단백질로 구성된다. 이러한 글로불린의 음전하는 표면 전하로 인해 일반적으로 서로 반발하게 된다. 두유를 가열하면 단백질이 변성되고 일반적으로 글로불린 구조 내부를 향하는 소수성 그룹이 노출된다. 응고제의 양이온은 음전하를 띤 그룹과 결합한다. 단백질 분자의 순 전하가 중화됨에 따라 매력적인 소수성 상호 작용이 반발하는 정전기 전하를 지배하고 단백질 응집체가 형성된다.
두 가지 유형의 응고제(염과 산)가 상업적으로 사용된다.
두부는 단백질 함량이 상대적으로 높아 단단한 두부의 경우 약 10.7%, 부드러운 연두부의 경우 5.3%, 질량 분율로 보면 지방은 각각 약 5% 및 2%이다. 두부 덩어리의 대부분은 물로 이루어져 있으며 일반적으로 76%에서 91% 사이이다.
두부는 콩으로 만들어졌기 때문에 콩류에 알레르기가 있는 사람은 섭취하지 않는 것이 좋다.
한의학의 주장.
두부는 한의학에서 냉각제로 간주된다. 비장에 활력을 주고, 기를 보하고, 양의 공허를 적시고 식혀주며, 몸의 해독작용이 있다고 한다. 그러나 그러한 주장을 뒷받침하는 과학적 증거나 암시된 개념은 없다.
서양과 동양 시장 모두에서 다양한 종류와 맛의 두부를 구입할 수 있다. 옵션의 범위에도 불구하고 두부 제품은 두유에서 직접 생산되는 '생두부'와 신선한 두부를 사용하여 생산되는 '가공두부'의 두 가지 주요 부류로 나눌 수 있다. 두부 생산은 또한 다양한 요리에 사용되는 중요한 부산물을 생성한다.
순두부.
순두부는 매우 부드러운 두부이다. 두유를 왕소금으로 이루어진 해수나 식염수에 섞어 응고시킨다. 이것이 부드러운 상태로 유지된다. 방금 만든 순두부는 양념을 하지 않거나 거의 하지 않고 끓여서 먹는다. 제조된 순두부는 보통 튜브 형태로 판매된다. 순두부찌개의 주 재료이기도 하다.
연두부.
연두부는 물기가 남은 상태를 유지하면서 압착되지 않은 두부의 하나로, 수분량이 매우 많다. 두유를 응고시켜 만든다.
모두부.
건두부.
유부.
두부는 탁한 콜로이드 액체/용액인 두유로 만들어진다. 두부의 구조는 두유 성분, 특히 단백질 입자 및 기름 소구체와 같은 콜로이드 성분과 관련이 있다. 대두의 글로불린 비율이 증가할수록 단백질 입자 함량도 증가한다. 두부 품종은 다양한 농도의 응고제를 첨가하여 만들어진다.
두부 제조에 중요한 대두의 두 가지 주요 구성 요소는 글리시닌을 포함하는 11S 구성 요소와 헤마글루티닌, 리폭시게나제, b-아밀라제 및 β-콘글리시닌을 포함하는 7S 하위 단위이다. 대두 단백질의 65~85%를 구성하는 두 부분의 주요 대두 단백질 성분에는 글리시닌과 β-콘글리시닌이 포함된다. 대두 단백질은 열, pH 및 이온 강도에 민감하고 아미노산 구성으로 인한 친수성 및 소수성 상호 작용으로 인해 가용성 및 미립자 분획 간에 고르지 않게 분포되는 다양한 하위 단위로 구성된다.
회(膾)는 생선이나 조개류, 쇠고기의 살, 간, 천엽, 염통 등을 날것으로 먹도록 만든 음식을 말한다.
유명지.
일찍이 논어에 회는 가늘수록 좋다고 하였고, 지봉유설(芝峰類說)에 따르면 “중국인은 회를 먹지 않는다. 말린 고기라 해도 반드시 익혀 먹고, 조선 사람이 회를 먹는 것을 보고 웃는다.”는 기록이 있는 것으로 보아, 한국에서 예전부터 많이 먹던 요리임을 알 수 있다. (단, 충주시, 괴산군, 서울특별시, 용인시, 수원시, 안성시, 원주시, 전주시, 담양군 등 내륙 지방에서는 거의 먹지 못했다.) 조선왕조실록에는 생선회를 가리키는 어회(魚膾)라는 표현이 등장한다.
치과 의사 모녀 살인 사건(Dentist Mother–Daughter Murder Case (South Korea), 齒科醫師母女殺人事件)은 대한민국 서울특별시 은평구 불광동의 한 아파트에서 치과의사였던 여성과 그 미성년 딸이 숨진 채 발견된 1995년의 살인 사건이다. 사건은 초동수사 절차와 법의학 감정의 한계를 둘러싼 논쟁, 그리고 증거재판주의의 적용을 둘러싼 사회적 논의를 촉발하였다.
사건과 관련해 피해 여성의 배우자였던 외과의사 이도행은 피고인으로 재판에 넘겨졌으나, 1심 사형(1996년 2월)→항소심 무죄(1996년 6월 26일)→대법원 유죄 취지 파기환송(1998년 11월 13일)→파기환송심 무죄(2001년 2월 17일)→대법원 무죄 확정(2003년 2월 27일)의 절차를 거쳐 최종 무죄가 확정되었다.
치과의사 모녀 살인 사건은 대한민국 서울특별시에서 발생한 이중 살인 사건으로, 1995년 6월 12일 은평구 불광동의 한 아파트 욕조에서 30대 초반의 여성 치과의사와 2세 딸이 경부압박으로 숨진 채 발견되었다. 당시 남편 이도행은 외과의사로 사건 당일 오전 병원 개업 준비를 위해 출근한 상태였고, 이후 유력한 피고인으로 기소돼 1심 사형, 2심 무죄, 대법원 파기환송, 파기환송심 무죄, 대법원 재상고심 무죄 확정까지 장기간의 법정 공방이 이어졌다.
배경과 사건 현장.