#1
|
|||
|
|||
Registry Problem
This program is packed with ZipWorx Secure EXE. It create a key "HKEY_LOCAL_MACHINE\SOFTWARE\ZipWORX\" that I don't succeed in eliminating. Help me!
|
#2
|
||||
|
||||
Hi
I don't really understand what you are trying to do here If the installation writes a registry key, then the program needs that key to run. On the other hand if you are trying to say you have uninstalled the program and the key is still there, well you should be able to delete it. If you can't then there is something in the startup that is writing it. So check what's in the startup group and if there is nothing there to do with the program and you still can't delete it run in safe mode then delete the God darn thing /hobferret |
#3
|
|||
|
|||
Shit ! It use a technology called embed NULL character in registry key, first introduced by RegHide of SysInternals, and used in some rootkit, malware, software.... We can't use RegEdit.exe, RegEdt32.exe to open, view it.
|
#4
|
|||
|
|||
Quote:
I looked at reghide src and see they use native API for access. So... Can use ZwCreateKey (enumerating subkeys) and then ZwDeleteKey to remove bad keys? Don't have time to test this morning but perhaps will code something later this morning to see if success. Google ZwCreateKey & ZwDeleteKey for MSDN reference. Systernals Reghide as TQN mentioned, Source code at: h**p://www.sysinternals.com/Information/TipsAndTrivia.html#HiddenKeys -bg |
#5
|
|||
|
|||
Yes, bgrimm ! We can only use Native Registry API Zw/NtCreateKey, Zw/NtDeleteKey to view and delete hidden registry keys. Do you plan to write this app to remove them ?
|
#6
|
|||
|
|||
Well I hoped to have some working code by now but have not had the time.
I was a bit discouraged to find a lack of assembly/masm examples using ntcreate/deletekey, or much of anything on the native API in assembly. So I will likely have to butcher the sysinternals example code and write something in C with it to do the job. I'm still a bit amazed that windoze would provide an open API using ANSI and a closed (hidden) API providing unicode. Why not have just had functions like RegOpenKeyExW for wide character support. Or just have hade the whole access method unicode from the start... but that's microsoft I guess. -bg |
#7
|
|||
|
|||
We can use RootkitRevealer (SysInternals) to find those keys in our registry. In my machine, I have three keys of my machine:
HKLM\SOFTWARE\Classes\CLSID\{05F7676A-ABD2-42e5-8107-8B00E139D339}\InprocServer32* 04/07/2004 11:51 PM 0 bytes Key name contains embedded nulls (*) HKLM\SOFTWARE\FMS\Total .NET SourceBook\1.1\Lic* 29/06/2004 9:15 PM 0 bytes Key name contains embedded nulls (*) HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ 12/11/2004 3:41 PM 0 bytes Key name contains embedded nulls (*) HKLM\SOFTWARE\ZipWORX\ZipWorx SecureEXE RunTime* 30/06/2005 6:11 PM 0 bytes Key name contains embedded nulls (*) The last key created by test.exe of TheBoss. I will code a prog to view and delete those keys. Regards, TQN |
#8
|
|||
|
|||
Exists one old article about this problem... Seems to be it's found at www.uinc.ru... PS: russian version *only* =)
|
#9
|
|||
|
|||
Very interesting...
What is this "embed NULL character in registry key" tecnology and why it cann't be handled by REGEDIT. Can anybody tell me which one is the related article in www.uinc.ru ,as the search gives a number os Rus. results . Or can anybody pls. translate it..
__________________
{RES} |
#10
|
|||
|
|||
Quote:
Difference is RegEdit using Win32 API ANSI functions, and Native API using UNICODE. So RegEdit cannot process the extra/embedded Null. The Registry key was written with UNICODE NTCreateKey. So all operations on it would have to be using Native API functions. -bg |
#11
|
|||
|
|||
I posted a util on woodmann's a while back you might be interested in. I have attatched it here for your convience. It includes source that you'll want to modify.
Originally, it was written for eLicense, so the base location of where it starts will need to be modified to reflect this protections base. More information can be found by going to woodmanns and looking at the thread "E-license 4.0 unpacking" (page 3, 2-28-2004). Anyway, in main(), replace pwKeyName_ = L"\\Registry\\Machine\\SOFTWARE\\LicCtrl"; with pwKeyName_ = L"\\Registry\\Machine\\SOFTWARE\\ZipWORX"; Hope this helps. |
#12
|
|||
|
|||
Thaks for the tool sgdt...
Quote:
__________________
{RES} |
#13
|
|||
|
|||
I haven't even seen a 9x box since, well, the 90's. The moment I got NT4, that pretty much spelled the end ff 9x for me. Never really looked back... (all my machines have XP and 2K on them, and I still have one NT4 machine).
That said, I'm certain there may be simular call that could be made on a 9x, and if not, then a protection probably won't be able to use the NUL trick on a 9x box. It is not uncommon for protections to fall back to other methods when things don't work. |
#14
|
|||
|
|||
Quote:
I think unicode support only came about in NT systems. -bg |
#15
|
|||
|
|||
Just one small clarification I think should be made.
The problem with the key names that contain NULL is not ANSI vs UNICODE. In Unicode, once the 0x00 0x00 unicode char was reached, this would make the API take it as the end-of-string and not include it in the key name. The problem is that the native version does not rely on a NULL terminator (be it ANSI or UNICODE), but it receives the length of the key name in a separate parameter, thus allowing you to specify a certain length, and in the key name place any garbage you want, including NULLs. There is already a RegCreateKeyW which handles Unicode chars and does not allow these hidden keys, because it also relies on a NULL (0x00 0x00) to detect the end of the key name. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
CRC problem... Alien Registry Viewer | Maltese | General Discussion | 4 | 04-12-2007 13:52 |