A forum for reverse engineering, OS internals and malware analysis 

Forum for discussion about kernel-mode development.
 #24964  by Microwave89
 Fri Jan 16, 2015 7:04 am
Ok, I have to say I was kinda busy with school the last two weeks.
Source is going to be released, soon.

@Munsta, Thanks for your input, however, I don't fully understand what you mean by patching BCD?
Should I patch BCD for getting into safe mode?
And why isn't my method too good? (at least it's simple...)

Actually, there are two files involved in boot.. bootmgr & Boot\BCD..
In my opinion, bcd or bootloader patching is only needed when trying to remove watermark.
Test signing of my driver is the most revealing thing.. I will try to address this issue by performing a little memory patch on basebrd.dll or whatsoever in next version.


Best Regards

Microwave
 #24991  by Munsta
 Sun Jan 18, 2015 2:24 pm
@Microwave
Its not for that, its for keyboard handler on F8 Menu. If you apply that patch I posted on NTLDR, you will not be able to navigate to Safe Mode when you enter then F8 Menu and thats my favourite method of "surviving" safe mode. Timer goes out, system starts Normal mode because user can't select anything else.

On Vista/7/8.1 I assume the trick is to patch BCD in the same manner but then you have TouchScreens and problems arive so it might not be smartest method hehe. I just thought its nice idea, similar, you added some keyboard related code in your rootkit anyway.

Its still troll mode over 9000.
Test signing of my driver is the most revealing thing.. I will try to address this issue by performing a little memory patch on basebrd.dll or whatsoever in next version.
Didn't get that one sorry.
 #25124  by Microwave89
 Sat Jan 31, 2015 4:33 pm
Hi munsta

Yes, maybe at some point I will try to patch the BCD..however, at the moment I'm trying some different stuff.

Regarding your answer because of my test signing concerns I will explain it again:

As my driver isn't properly signed it has to rely on test signing mode.
As I told before I managed to circumvent the possibility of letting bcdedit reset my own testsigning entry so direct BCD hive editing is required in order to deactivate the driver.
Hence, although the testsigning cannot be disabled by simply using the documented bcdedit tool Windows still keeps showing the testsigning watermark on the desktop.
And that is the reason (amongst others) why my driver is still very revealing what it after all shouldn't be.
My guess now is that the displayed watermark string can be patched in memory so it will no longer reveal that an actually unsigned driver might be loaded into Windows.

@all:
At the moment I have not the patience to properly explain (comment) my source code..I didn't touch it since new year.
Always ask yourselves if the comment isn't totally pointless as the vast majority of those still reflect the old working principle (V1.0)...

On Windows 10 there is another issue: If the Windows 10 bootmanager is being active and you take an action which leads to rebooting the computer before LogonUI is being loaded the driver isn't written in the system again. This comes most likely due to the fact that when displaying the new Windows 10 boot menu most of the system drivers including mine are already loaded and initialized. However, mine deletes all of it's entries shortly after being initialized and after that waits with reinstalling its file until the LogonUI process is being ran. If you select safe boot or PC repair the PC reboots without ever having launched logonui.exe so the new image file has never been copied over.
If the file rewriting is placed before it waits for logonui.exe it should address this issue.


Best Regards

Microwave89
Attachments
no pwd
(47.7 KiB) Downloaded 114 times
 #25125  by Munsta
 Sat Jan 31, 2015 9:28 pm
Yo Microwave89 :), yes I hope user32.dll.mui patch still works for removing of that watermark. I think there are some tools for that already from old Windows7 activators (non SLIC?) or it was developed for some other purpose.
 #25164  by Microwave89
 Thu Feb 05, 2015 4:53 pm
When I was researching this earlier, I found that the water mark strings were compiled into basebrd.dll.mui and shellbrd.dll.mui or something similar. Iirc, it was not user32.dll related anyhow..
However, at this point it seems to me like those aren't mapped, currently.

Best Regards

Microwave