PDA

View Full Version : Tips on what's going on under the hood


mint77
January 10th, 2013, 23:48
There is a program called reghide.exe that puts a key into the registry that can't be seen.

I would to Re*erse engineer it to find out what exactly it's doing.

I used IDA to get an asm listing, but the listing is very long.

Can someone give me some pointers ?

Kayaker
January 11th, 2013, 00:52
Hi

The download page for reghide (Sysinternals) basically gives the trick up front, but start by checking the IDA xrefs for GetProcAddress to see which Nt* Api's are called, and then dig a bit

mint77
January 11th, 2013, 01:58
Thanks, I'll do some digging.

bilbo
January 11th, 2013, 04:10
Nice trick!
Replace the byte at offset 0x1219 from 0x20 to 0x1E with an hex editor and the value will no more be hidden!

Best regards, bilbo

mint77
January 11th, 2013, 13:16
Thanks bilbo.

I would like to know how the key was hidden.

I am using IDA to study it, but having some difficulties.

I prefer an older version than the 5.0.

It may come in handy to slow down "script kiddies", a term someone else came up with.

Take care,

Andy

blabberer
January 11th, 2013, 15:09
Quote:
The download page for reghide (Sysinternals) basically

is it still avl from sysint ?? dont beat me i m quoting something from memory that it was removed from the site when sysint was merged with ms

@mint

if you find analysing reghide in ida problematic find another program called regdelnull.exe and analyze it in say ollydbg

@bilbo 000070AA: 00 42

Kayaker
January 11th, 2013, 17:51
Not exactly the same phenomenon, but it reminds me of the XP Notepad 'easter egg'. Open a new document in XP notepad and type in the 4-3-3-5 character pattern, without a carriage return
xxxx xxx xxx xxxxx

Now save and close it and open it again, the text has been mysteriously transformed to gibberish!

The popular (thus googlable) example given is
Bush hid the facts
or
This app can break

And yet, for some reason the following doesn't work, now what's going on there?
Bush hid the truth

http://blogs.msdn.com/b/oldnewthing/archive/2004/03/24/95235.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2007/04/17/2158334.aspx

IsTextUnicode is the culprit. Some wag came up with the suggestion they need a second API called IsTextReallyUnicode.



Reghide:
http://technet.microsoft.com/en-us/sysinternals/dd581628.aspx

bilbo
January 12th, 2013, 16:07
IMHO, phenomenon that Kayaker addressed in Notepad is completely different.
In the REGHIDE case, to the Window API used to create a key (RegCreateKeyW) can be passed an Unicode string without problems. But, whilst it can accept just a null-terminated Unicode string, the native counterpart NtCreateKey accept an UNICODE_STRING. This means that the Unicode string length is not determined by the trailing null, but by the value given in field Length of the UNICODE_STRING structure. This way, passing a name including a trailing null to the Windows API RegCreateKeyW is impossible, but it is possible with the native API NtCreateKey. Since REGEDIT uses only Windows API's, it cannot open a key containing a trailing null, created by REGHIDE using the Native API NTCreateKey.
To unhide the key, blabberer suggested to replace the last wide character of the name, 00 00 (at address 0x70AA), with a not-null character (e.g. 00 42); I suggested to shorten the length of the key name by two bytes (one wide character) to remove the trailing null.

mint77, I do not understand what are your difficulties in IDA. If the difficulties are due to a poor assembly knowledge, please single-step the instructions in a debugger and look at the meaning of each instruction in an assembly reference guide; you can start from WinMain. After few hours you will gain a better knowledge of assembly. Anyway, the call to NtCreateKey starts at address loc_4011E5, and the address of NtCreateKey was saved in dword_42216C at the beginning of the program.

Best regards, bilbo