That got your attention, didn't it? First post, too.

I have a serious, and legitimate reason to be wanting to do this. Please excuse me whilst I evade telling you exactly why I want to do this, except to say it is for a commercial security product that will be on sale to the general public (eventually).

I have been tasked with developing a piece of security software. The more recognized and official methods as proscribed by Microsoft themselves seems to be open to easy circumvention/tampering. Not ideal.

What I ultimately want to do is write a driver that does this, to make access to it from Userland that bit harder, but as I'm still on a steep learning curve with MASM (I gave up on C++ - just can't get on with it), I wanted to try the things I need seperately first, to see how they work, and get them working, before I lump them all together.

I've already been suspected of being a hacker on another forum. I can assure you I am not, and if the site admin wishes further evidence of who I am, and that I am indeed legitimate, they are free to PM me. What I will not do is post such details in public.

Now I've got that out the way, I wish to also employ other techniques used by viruses/malware/whatever to mask themselves. I would also like to employ anti-debugging techniques, but for now, these are beyond the scope of my capabilities, and I have no interest in them right now.

That is where I am, and where I want to head.

First up, I would like a bit of help in learning how to write a DLL stub to intercept calls, or inject code into a process to do the same.

I appreciate this is heavy for a first post, and that people in the assembly programming world seem reluctant to discuss anything that could be mis-used, but I could say the same thing about the delete key. Perfectly innocent, until pointed at NTLDR.

Apologies for the tone of the post, but I need help, and so far I keep being treated like I'm a 13 year old script kiddy. I'm actually a 27 year old programmer and director of a UK company. I'll say no more about myself than that.

Forum rules aside, there are very real laws on hacking etc.. I have no intention of doing that. I want to perform a specific task, but in such a way as to make it very difficult for it to be attacked or circumvented by people far better than I.

I tried the gently gently approach on another forum - I'm going direct here. Hopefully I can find the help I'm looking for. :)

Thanks in advance.
Astro.
Posted on 2009-07-17 19:38:41 by Astro
I found this which also looks interesting:

http://www.codeproject.com/KB/system/soviet_protector.aspx

Astro.
Posted on 2009-07-17 19:55:49 by Astro
Woodmann's Forum will probably be a more appropriate place for your endeavors, all around.
Posted on 2009-07-17 22:41:24 by SpooK
You say you've been tasked with writing security software, but have given up on C++ and have a very steep ASM learning curve ahead of you. Sorry if this sounds rude, but are you sure you haven't bitten off more than you can chew?
Posted on 2009-07-18 08:38:12 by f0dder
Depends how you look at it.

I think no, because I'm the kind of person who will work through problems to a solution. I haven't been tasked with this and must have results 3 weeks from now. We're very much in the R&D stage, and this is part of that.

I'm not going into this entirely cold; my two big problems are:

1) MASM syntax (I'm getting there quite quickly with it - I've already created a small Windows UI progmatically which is further than I ever got with C++!!!!)
2) Finding my way around Windows from this angle

I've already written a small piece of code in C++, but I was getting stuck with some of the more advanced stuff. I couldn't crack USB enumeration for example (3 months later and still no further on). I'm just about there with it in ASM - not bad considering I started on this 6 days ago.

So, I'm progresssing really quite quickly I think. :)

I'm still researching techniques, but now I'm at a point where I need to start writing some code, and this is where I'm getting a bit stuck.

I found a few things here last night that were very helpful in your tutorials section. Great work!  8)

I also intend to keep learning assembly beyond this project. Whilst it is a not-so-basic project to start off with, it is currently solving a lot of my problems.  8)  I'm very pleased with progress so far.

EDIT: I just had a look at the site you linked to - that is NOT what I want to do thanks. I don't wish to crack or reverse-engineer anything. The part of Windows I wish to hook is already well documented by MS from the point of view of altering its behavior. I just want to do it slightly non-standard.

If I mention MS GINA, I hope you guys won't run away like they did on the other forum.  :sad:

MS suggest writing a stub .DLL, adding your own code where desired, and forwarding requests where you're not interested. They then suggest making 1 alteration to the registry to get Windows to load your stub, and not their GINA, and you're done, but knowing that makes it sound a little too easy to circumvent. Not what we want really.

I'm quite happy with the Win32 API - no probs there - but it's the "small" details like determining offsets for things - I just can't quite "see" how it works yet. I keep reading code and get a feel for it, but I feel a bit like trying to use a torch in room painted black at the moment.  :)  Take for example copying 4 bytes from one memory loocation to a buffer - it would appear you can do this in one instruction, but I can't quite see how that works.

I happy with this for example:

.486
.model flat,stdcall
option casemap:none

include \masm32\include\kernel32.inc
include \masm32\include\masm32.inc

includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\masm32.lib

.data?

t db ?
t2 db ?
temp dword ?

.code

s db " : Test1",10,13,0
s2 db " : Test2",0

start:
;===========================================================
lea eax,s ; get address of s
push eax ; push address of s to stack

mov temp,eax ; store address of s in temp
lea eax,t ; get address of t
push eax ; push address of t - udw2str will write here
push temp ; push temp to stack

call dw2hex ; convert dword to hex string

lea eax,t ; get address of t
push eax ; push to stack

call StdOut ; print address of s2
call StdOut ; print s2
;===========================================================
lea eax,s2 ; get address of s
push eax ; push address of s to stack

mov temp,eax ; store address of s in temp
lea eax,t2 ; get address of t
push eax ; push address of t - udw2str will write here
push temp ; push temp to stack

call dw2hex ; convert dword to hex string

lea eax,t2 ; get address of t
push eax ; push to stack

call StdOut ; print address of s
call StdOut ; print s
;===========================================================
ret
end start


I wrote that myself to get the address of the strings in memory. The main point of the excercise was to get used to the stack, and that things need to be ordered. I'm also happy with the "balanccing the stack", too, if I add or remove something then return, I need to update the stack pointer.

but have given up on C++

Yes. I just can't get on with it. I had too many questions that weren't being answered to my satisfaction. Assembler answered them all within about 30 minutes, and it makes a whole lot more sense to me in general. I really wish I got into x86 assembler sooner (years sooner).

Astro.
Posted on 2009-07-18 09:00:26 by Astro
Hi,

I think I mis-understood you when you posted your link. Sorry.

(Some ;) ) of what is over there is stuff I'll be interested in eventually, but for now I'm just looking for more basic things. :)

Best regards,
Astro.
Posted on 2009-07-18 13:05:09 by Astro

Hi,

I think I mis-understood you when you posted your link. Sorry.

(Some ;) ) of what is over there is stuff I'll be interested in eventually, but for now I'm just looking for more basic things. :)

Best regards,
Astro.


Yeah, it was more like "these" people can help you find all the ways of doing "things" so that you are more prepared for the task at hand. Also, you can bounce ideas off of them to and even have them try to circumvent your efforts to see where you really stand.
Posted on 2009-07-18 21:20:46 by SpooK
My apologies again, and thank you.  8)

Best regards,
Astro.
Posted on 2009-07-19 19:09:39 by Astro
"That got your attention, didn't it? First post, too"

I'm all ears...   Thanks for the intel Astro.
Posted on 2009-07-22 17:17:30 by losser
As for a stub dll, take an example c:\windows\system32\url.dll

If you wanted to hook this dll with a stub dll you would write a dll with the following functions named exactly and with the following prototypes:
AddMIMEFileTypesPS PROTO :DWORD,:DWORD
InetIsOffline PROTO :DWORD
MIMEAssociationDialogA PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD
MIMEAssociationDialog equ <MIMEAssociationDialogA>

MIMEAssociationDialogW PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD
SetInetOffline PROTO :DWORD
TranslateURLA PROTO :DWORD,:DWORD,:DWORD
TranslateURL equ <TranslateURLA>

TranslateURLW PROTO :DWORD,:DWORD,:DWORD
URLAssociationDialogA PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD
URLAssociationDialog equ <URLAssociationDialogA>

URLAssociationDialogW PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD


Your dllmain function would call LoadLibrary on the full path to "C:\windows\system32\url.dll" and GetProcAddress on each of the previously named functions and store them into a call table.

Then taking TranslateURLA for example:
TranslateURL proc pcszURL:DWORD, wInFlags:DWORD, ppszTranslatedURL:DWORD
pushad ;save registers
;do our code before calling the function
popad ;restore registers
push ppszTranslatedURL ;pass the same (or changed) variables
push wInFlags
push pcszURL
mov eax, CallTable ;lookup the real functions address
call eax ;call the REAL function
pushad ;save the registers again
;do our code before returning (such as editing the url)
popad
ret
TranslatedURLA endp


The DLL you create MUST contain EVERY function in the original dll. Even if they are simple wrappers with no pre/post processing. The outputed dll must be named "url.dll" And placed in the same directory as the target program (so it loads first before looking in C:\windows\system32"). As you can see, having to create wrapper dll's for every dll you want to hook is going to take a long time, and then you would have to either copy all the originals from their original location to your backup folder and keep track of them there, or place your files in every directory... Not a good choice for your rootkit. (I use the term rootkit because just as you assume everyone will think you are a hacker, the term rootkit is not always bad. Any decent anti-virus software is a rootkit.)

3 weeks to develop this software is definitely biting off more than you can chew. I would say in 3 weeks, you could start understanding the basics behind win32asm. Another month for figuring out the very basics of driver design. And another year of R&D and crashing computers or emulators testing your driver/ program. This is assuming you work on it full time and are above average with picking up programming. Due to the fact that you have no history with programming concepts, I would say it will take you a bit longer. This is my honest opinion. I like people picking up programming (especially asm) however, large projects always make people new to programming lose interest and give up.
Posted on 2009-07-23 02:46:02 by jakor
jakor: it's wrong calling something non-malicious a rootkit. It might use rootkit-like techniques to hide/protect itself, but the word rootkit is really loaded with malicious intent.

Writing a shimmy DLL is a pretty bad solution, since you need to forward all functions, not just the ones you need... and sometimes additional functions are added to DLLs. A better approach is to use detours or your own hooking library :)
Posted on 2009-07-23 03:13:13 by f0dder
Sony had no malicious intentions, only protecting their own software...
http://en.wikipedia.org/wiki/Sony_BMG_CD_copy_protection_scandal

Realistically, a rootkit could be considered anything which adds an artificial intelligence layer between the computer and user filtering bad output. It's the filter which would be malicious, not the implementation. (Of course this is how I see it, and I do understand where you are coming from...)

And politically correct, hacker != cracker. We only use these terms so that others can understand what we are saying.

(since emotion cannot be reflected in text: I do no mean to drag out an arguement over this, I am only explaining my reasoning behind my terms/post)
Posted on 2009-07-23 04:36:01 by jakor
If this is going to be a commercial security product I suggest freelancing out the design to someone probably better experienced with this kind of work.

That being said, almost any hooking mechanisms can be circumvented unless you explicitly hook the routines used for memory modification and insert checks to prevent modifying the hooks code space. Since what you are looking for is REALLY bordering the sites rules, but the LLC board was designed for things which bordered the rules as we used to be a bit ban-happy with these kinds of questions, I'm not going to get too specific with this.

If it was me, I wouldn't take the approach of hooking the system DLLs. Any malware which gets run on the system post installation of your "security product" will be able to hijack your code by either hooking kernel API's or your code itself. This means to protect your tool you will need to monitor/hook all memory access routines to check for access to your "security product". So not only are you hooking the API's you need for your "security product" to work, you're also having to hook Mm* routines.

What I would do is create a custom interrupt which contains all of my routines then patch the windows IDT to forward specific calls to my interrupt, then finally patching the NMI to protect the current state of the IDT table from modification. It would also be a good idea to have a driver check the NMI state to ensure it hasn't been re-patched by any other software (a lot of viruses will target the NMI). This method is preferred, imho, because the only checkups you will be preforming are done to ensure the NMI doesn't get modified and the NMI patch which prevents the IDT from being changed. It would also be a pretty decent idea, just as a secondary precaution, to prevent DeviceIoControl from using IOCTL_*_INT and/or hook CreateFile and return error if the the first argument is "\\.\InterruptHook". IMHO this method is much better than hooking a bunch of memory functions to check for addresses or setting up flimsy EAT/IAT patches of resident DLLs.

Downside to this method is that it kills of support for other applications having access to update the IDT, which is popular in things like SoftICE. Though you could always set those applications to be loaded before your "security product".

Coding it won't be easy, which is why I suggested freelancing the work out to seasoned system software developers. At any rate, there is a big difference between writing a Windows UI "Hello, World" and creating system drivers/modules that patch system critical interfaces. With kernel memory, one miscalculated address or unchecked arithmetic instruction and your user is looking at a blue screen.

3 weeks to develop this software is definitely biting off more than you can chew. I would say in 3 weeks, you could start understanding the basics behind win32asm. Another month for figuring out the very basics of driver design. And another year of R&D and crashing computers or emulators testing your driver/ program. This is assuming you work on it full time and are above average with picking up programming. Due to the fact that you have no history with programming concepts, I would say it will take you a bit longer. This is my honest opinion. I like people picking up programming (especially asm) however, large projects always make people new to programming lose interest and give up.


I really gotta say I agree with this statement in this context. I helped a young associate of mine, who actually did have past programming experience, learn to develop system software with MASM and it took him about 2 days to work his way up to basic services but 6 months to finally get to where he could write drivers without killing his PC on a regular basis.

None-the-less, good luck with your project and I hope you drop back in 3 weeks from now to let us know how it turned out.

Regards,
Bryant Keller
Posted on 2009-07-23 05:14:11 by Synfire
Sony installed it's rootkit not to protect the user, but to protect it's own interests - without informing the user. Furthermore, their software was badly written and could be exploited by malware. Thus, a lot of people (including me) find their crapware bordering malicious.

As for hacker vs. cracker, in these days and times (unless you're a GPL hippie), a cracker removes software protection and a hacker breaks into other people's systems.

Anyway, enough off-topic from me :)
Posted on 2009-07-23 05:15:33 by f0dder
Idt/ memorymanager hooking really is the best way to go about setting yourself up from a security (non proof of concept) standpoint. Breaking into the private kernel functions would only offer a slight bit more protection for allowing other security programs to work (until the fu2 scanner is released anyways.)  There should be someway to whitelist programs to access the idt (i'd make it a hash plus file length on the image at least) then you could write protect the whitelist.

Ah the list of things to accomplish while dealing with kernel-land... I really should mess around with it some more... I gave up my drivers a while ago... always seemed like I made weeks of busy work for the 10 minutes or so of fun code I got to write. :-\
Posted on 2009-07-23 07:18:28 by jakor
jakor: a lot of the kernel-based stuff is pretty useless anyway, imho, because of x64 and patchguard. I find it a bit problematic that MS hasn't made some official & guarded hook locations, and rather insist on protecting everything.

Malware can attempt to subvert patchguard, but that's not a viable route for legit software.
Posted on 2009-07-23 07:48:51 by f0dder
Hi,

Since I statred this thread, I have this working:

Export function redirection.

Stub DLL:

.386
.model flat,stdcall

.code

DllEntry proc hInstDLL:DWORD, reason:DWORD, reserved1:DWORD
       mov eax,1h
ret 0Ch
DllEntry endp

CheckForDevice proc
CheckForDevice endp

end DllEntry


Exports:

LIBRARY CheckDevice
EXPORTS
CheckForDevice=CheckDevice2.#1


I re-wrote the "real" DLL in asm and exported the functions as ordinals only (NONAME) as a test. Ordinals or function names - either work as re-directors.  8)

I'm not a novice - been writing software for years, just not at this level. Because I quit with C++ doesn't mean I didn't learn something.

I suspect you think I just started out - no. :)

I appreciate this kind of question might be very close to breaking forum rules, and it was for this reason they suspect(ed) I'm a hacker over at the other forum. I guess they didn't consider the other (legitimate) uses for this kind of programming.

I tend to do things a bit different anyways.

So... with all that said - thanks for the above. I'm getting on really well with assembler, and I'm ready to go intercept a call or two from msgina (in a VM of course) to see where best to put my code.

I will want to write a driver, and already looked at the basics, but not yet ready to tackle that yet. In the meantime I've yet to research how to enumerate the USB. I thought I had it figured out but kept hitting a brick-wall with C++ which I hope won't be there when I re-visit it using assembler instead.

Best regards,
Astro.
Posted on 2009-07-23 14:40:21 by Astro
Using only export forwarding, I have a working GINA.dll stub. Tested in a VM.

Best regards,
Astro.
Posted on 2009-07-23 17:54:52 by Astro

...
Stub DLL:

.386
.model flat,stdcall

.code

DllEntry proc hInstDLL:DWORD, reason:DWORD, reserved1:DWORD
       mov eax,1h
ret 0Ch
DllEntry endp

CheckForDevice proc
CheckForDevice endp

end DllEntry


Exports:

LIBRARY CheckDevice
EXPORTS
CheckForDevice=CheckDevice2.#1

...
I'm not a novice - been writing software for years, just not at this level. Because I quit with C++ doesn't mean I didn't learn something.

I suspect you think I just started out - no. :)
...


What languages have you used? Vb?

There are things missing such as a return from the checkfordevice call that are needed. What is the purpose of exporting by ordinal in this case? There is also no need for the 0Ch after ret. Export hooking is opening up the pe file and traversing through the structures and tables until you find the address of a function in a table and overwritting that with a pointer to your function loaded into the same address space.

You seem to understand some terminology, but writing a dll skeleton with errors doesn't make you look any less new to programming. Masm come with iczlions tutorials if I were you i'd look up the tutorial of dll's there is a decent beginners tutorial that would create an acceptable dll skeleton to start off with.

As far as driver development, learning userland is tough with the lack of knowlege online(for assembly). Many old topics covering assembly are not relevant but contain good knowlege if you already know assembly basics and can apply the theories to new code. Kernel land however suffers from far less information plenty of restricted rules on what and how to do things. You also need to write a service to talk to and control the driver. Plenty of requirements to use undocumented or slightly documented functions and structures.

Hooking dll functions is a very *VERY* simple task compared to 1/4 of you project. If you are serious about learning assembly, you must run through the iczlion tutorials. Even tasks which you think may be unimportant such as reading and writing a file are very basic and necessary for talking to drivers.

Unless you are autistic, the ammount of time for things to stick in your head is far more than you have given for your time limit. The only way I can think you could do this is by ripping code from many places and rigging it to work. The flaws and issues you would run into will take more time to track down solutions for than just learning the language first.

This is my last plea to just learn assembly (or whatever language you settle on) first and start piecing your project together over a much longer time.
Posted on 2009-07-24 14:10:28 by jakor
Quite a reply there...

I'm not autistic - just smart, and I put in the effort to learn. I also take from experience and my education.

Yes, I do have stuff to learn regarding assembler, but I learn it as I go (and I don't mean a cursory glance). It's my learning style, and how I pick stuff up so quickly.

There are things missing such as a return from the checkfordevice call that are needed.

No - it is a forwarding export.  :)  This function simply acts as a place-holder. It doesn't  actually do anything beyond providing for the entry in the table so it doesn't throw the linker error "unresolved external reference". If the code actually did anything (see WlxInitialize below) then the usual rules apply to that specific function in the DLL and the export definition file.

What is the purpose of exporting by ordinal in this case?

Required for my GINA stub (which is now 100% operational including my intercept of the WlxInitialize function for my own purposes - not a mean feat in itself for someone who appears to be so.......new to programming, less assembler, hmm?). There are 28 functions in msgina.dll that are exported only by ordinal. I need to copy this exactly otherwise my DLL will fail, and with it, Windows. I exported it by ordinal in my code above purely to test it worked, with known code.

There is also no need for the 0Ch after ret.

After much research, yes there is. In fact, not doing so in my intercept for GINA crashes the system. It is required. My app posted above would leak memory without (to be specific, it would leak stack memory).

Export hooking is opening up the pe file and traversing through the structures and tables until you find the address of a function in a table and overwritting that with a pointer to your function loaded into the same address space.

Thankyou. I shall research this further.

Masm come with iczlions tutorials if I were you i'd look up the tutorial of dll's there is a decent beginners tutorial that would create an acceptable dll skeleton to start off with.

Yes - I'm already going through those. I wrote the above "on my own" as it were as it is only through making mistakes do you learn anything.

Kernel land however suffers from far less information plenty of restricted rules on what and how to do things. ... Plenty of requirements to use undocumented or slightly documented functions and structures.

Yes - I'm still researching this.

You also need to write a service to talk to and control the driver.

No problems there. Looks easier in asm than in either C++ OR VB.NET.

If you are serious about learning assembly, you must run through the iczlion tutorials.

Already doing that.

Even tasks which you think may be unimportant such as reading and writing a file are very basic and necessary for talking to drivers.

Agreed. I'm still researching...

the ammount of time for things to stick in your head is far more than you have given for your time limit.

It seems people latched onto my comment about 3 weeks, and missed the word "NOT" that preeceded it. I have several MONTHS to do this (I've been a year at this already). My problem now is not so much what I want to do (that is sorted out) but just finding a language I can use to do it with. Assembler is my dream come true. I'm not new to it either - only new to it on the x86. No idea why I didn't think to try it before, to be honest.

The only way I can think you could do this is by ripping code from many places and rigging it to work.

I won't do that - it only hurts me.

The flaws and issues you would run into will take more time to track down solutions for than just learning the language first.

I completely agree with you there.

This is my last plea to just learn assembly (or whatever language you settle on) first and start piecing your project together over a much longer time.

I am learning as I go. Unfortunately I don't have the luxury of unlimited time to learn - I have a contract to fulfill and money to make. I do however have the capacity to do what I'm doing otherwise I would not have taken it on - it does me no good professionally to take something on that I can't handle.

Best regards,
Astro.
Posted on 2009-07-24 18:15:42 by Astro