Hide Registry key

개발을 하다가.  정보를 레지스트키에 저장을했다. 그런데 그거 보여주지 말랜다.

빌어먹을 방법이 없어보엿다. 윈도우는 uac 에 의해 기본 접근통제 원칙이 세워진지 언제인데. 

이런 구시대적인 발상이란 말인가.......

하지만 하랜다. 해야지.. 

새로운 방법이 있어 보엿다. 그거슨. .아래 를 참조하자.

Hidden Registry Keys, you say?

SysInternals says it the best (see below - verbatim from their website):

A subtle but significant difference between the Win32 API and the Native API (see Inside the Native APIfor more information on this largely undocumented interface) is the way that names are described. In the Win32 API, strings are interpreted as NULL-terminated ANSI (8-bit) or wide character (16-bit) strings. In the Native API, names are counted as Unicode (16-bit) strings. While this distinction is usually not important, it leaves open an interesting situation: there is a class of names that can be referenced using the Native API, but that cannot be described using the Win32 API.

How is this possible? The answer is that a name which is a counted as a Unicode string can explicitly include NULL characters (0) as part of the name. For example, "Key\0". To include the NULL at the end, the length of the Unicode string is specified as 4. There is absolutely no way to specify this name using the Win32 API since if "Key\0" is passed as a name, the API will determine that the name is "Key" (3 characters in length) because the "\0" indicates the end of the name.

When a key (or any other object with a name such as a named Event, Semaphore, or Mutex) is created with such a name, any application using the Win32 API will be unable to open the name, even though they might seem to see it.

This is where you can get a copy of RegHide from SysInternals.

뭔소리여 ... 라고 생각해서 잠깐 설명. .  

win32 api 는 ansi 8bit 문자를 쓴다. . regkey 접근 api 를 말하는듯.

근데 Native Api 는 모든 영역을 커버하기위하여 Unicode 를 사용한단말. 

그럼 다음을 이해 할수있다. 위 차이를 이해한다면.

ansi 는 key name 끝에 \0 가 붙어줘여 알아먹고. unicode 상태에서는 \0 가 안붙어도 알아먹는다는말.

그차이로 인해서 우리는  숨겨진 regkey 저장공간을 활용할수있다.  

그렇다면  일반 win32api  로는 접근이 안되니 NTDLL.DLL 을 접근해서 명시적 함수호출을 통하여

native api 위 얍삽이를 쓸수있다는 말이다.

아래그림은  참고.

Differences between Nt...() calls and Reg...() calls

I am going to show you some of the NT Native Registry APIs that CNtRegistry uses (or at least, is ready for use), talk about what makes these different, and how I modified a popular function called "EnablePrivileges" to use the NT Native APIs.

Some Native APIs	Related Win32 APIs	Required Privileges
NtCreateKey	RegCreateKey, RegCreateKeyEx	N/A
NtOpenKey	RegOpenKey, RegOpenKeyEx	N/A
NtDeleteKey	RegDeleteKey	N/A
NtFlushKey	RegFlushKey	N/A
NtSetInformationKey	None	N/A
NtQueryKey	RegQueryInfoKey	N/A
NtEnumerateKey	RegEnumerateKey,RegEnumerateKeyEx	N/A
NtNotifyChangeKey	RegNotifyChangeKeyValue	N/A
NtDeleteValueKey	RegDeleteValue	N/A
NtSetValueKey	RegSetValue, RegSetValueEx	N/A
NtQueryValueKey	RegQueryValue, RegQueryValueEx	N/A
NtEnumerateValueKey	RegEnumValue	N/A
NtQueryMultipleValueKey	RegQueryMultipleValues	N/A
NtEnumerateKey	RegEnumKey, RegEnumKeyEx	N/A
*NtSaveKey	RegSaveKey	SeBackupPrivilege
*NtRestoreKey	RegRestoreKey	SeRestorePrivilege
*NtLoadKey	RegLoadKey	SeRestorePrivilege
*NtLoadKey2	None	SeRestorePrivilege
*NtReplaceKey	RegReplaceKey	SeRestorePrivilege
*NtUnloadKey	RegUnloadKey	SeRestorePrivilege
NtClose	CloseHandle	N/A
NtCreateFile	CreateFile	N/A
NtOpenThread	OpenThread	N/A
NtOpenProcessToken	None	SeCreateTokenPrivilege
NtAdjustPrivilegesToken	AdjustTokenPrivileges	N/A
NtQueryInformationToken	GetTokenInformation	N/A

The parameters used for NT Native Registry APIs are not the same ones you are familiar with. Did you know that there is actually only two (2) Root (main) Keys in the registry? The rest are simply symbolic links. The two Root Keys are "\Registry\Machine (HKEY_LOCAL_MACHINE)" and "\Registry\User (HKEY_USERS)". Look below to see the HKEY and the TEXT equivalent. Where you would normally write a path for a subkey (RegCreateKey) like this "SOFTWARE\MyApp" and also include the HKEY (HKEY_LOCAL_MACHINE), these Native APIs (NtCreateKey) need the entire "full" path to the subkey, like this: "\Registry\Machine\SOFTWARE\MyApp". The CNtRegistry class lets you make the call the way you are used to, but puts it all together for you (internally), simply by calling the two functions (see below) or one that does it both.

알만한 사람들은 알겠지만. userapp. 인 regedit.exe 는  레지스트키 이름을 획득할때 \n 문자를 만나줘야한다.

하지만 실제작성시   name + 2byte 를 추가로 작성해주면  어떻게 되느냐 이거다 .

user level 에서 사용하는 reg api 는 byte char 이기때문에 +2byte 를 할수없다. 

이미 읽을때 byte 단위 확인을 하기때문에 알아서 정리해버림. 그래서 

unicode Ntapi 를 통해서만  regkey 숨기기  얍삽이를 쓸수있다.