|
That's what I'm afraid of. This is not a trait of a well-behaved application.
|
|
|
|
|
Michel Godfroid wrote: good rootkit
Oxymoron 
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Individuality is fine, as long as we do it together - F. Burns
Help humanity, join the CodeProject grid computing team here
|
|
|
|
|
The only thing I can think of is for you to put your file into Isolated storage. It's not a perfect solution, and Windows can still get at the file but it's probably going to be the best fit for your application.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
I hope the victim's antivirus can still scan it there.
|
|
|
|
|
I have only good intentions . I'm makein this aplication for my nephw who spends a long time in front of the PC.this should shutdown the system after the a period of time expires:P
|
|
|
|
|
Ah, I knew it was something user-hostile.
Your intentiions don't matter; the other guy's do.
Maybe you could use a database to store a usage log.
|
|
|
|
|
I have found that nephews have a tendency to know more about computers than uncles. Take the power cable, the internet cable, the cell phone, all usb cables, the printer, and the duct tape away and they will still find porn on the internet if left unsupervised.
|
|
|
|
|
There's a Japanese proverb: "The best place to hide a horse is among horses." Using that concept, you could put your XML file in C:\Windows\System32, where no one will ever find it by blind searching.
You could make it even harder to find by changing its name every time you use it, storing the new name encrypted in the Registry.
To protect against deletion, you could store two copies of the file, and if one is deleted, restore it from the other copy. If both are deleted, your program could restore them from the Recycle Bin.
|
|
|
|
|
I'm sure there are many horses in C:\Windows\System32, however modern Windows versions will not let you add to them...
|
|
|
|
|
Create your file. Encrypt it. Name if KE1lSD1.dll, or some other meaningless name, then store it
in Windows\System32. It'll look like any other DLL and no one would ever know. Even if someone
opened it with Notepad it would look like any other DLL they opened with Notepad.
Everything makes sense in someone's mind
|
|
|
|
|
Kevin Marois wrote: it would look like any other DLL they opened with Notepad
No, it won't. Have you opened a .net DLL in Notepad?
|
|
|
|
|
Here's a snippet of a random DLL I found in System32 opened in Notepad. if you encrypt a file, it will look similar to the following:
Q 3À…Òt‹Âë‹U9QtRèúûÿÿ]Â ÌÌÌÌÌ‹ÿU‹ìV‹ñè³ûÿÿöE
tVèÑÿÿY‹Æ^] ÌÌÌÌÌ‹ÿU‹ìƒì ‹MVEìP¾ VèÂçÿÿ…À…Ç
SWEôPV3ÛShP‹pÿuìÿT‹p‹ð;ó…ê EèPEøPEðPÿuôèHØÿÿ‹ð;ó…à 9]ðj^‰]ü†¤ ƒþ…› ‹EèSSSS‰EäEäPÿuøÿuüÿuôÿL‹p‹ð;óuijèÞÐÿÿ;ÃYtÿu‹Èè£Úÿÿ‹øë3ÿ;ûtFjEàPÿuøÿÌ‹pƒÄ P‹Ïè§óÿÿ‹ð;óu‹E;Guÿw ÿu ÿ ‹p…Àtj^j
‹ÏèDãÿÿëj^ÿEü‹Eü;Eð‚\ÿÿÿÿuøSÿ5ä ‹pÿ‹pÿuôÿX‹pƒþ…§ jèDÐÿÿ;ÃYtÿu‹Èè Úÿÿ‹øë3ÿ;û„ƒ j,è Ðÿÿ;ÃYt ÿu‹Èè£Ùÿÿ‹Ø…Ût^ÿu‹Ïÿu èÊñÿÿ…ÀuM‹Ïè&ôÿÿ…ÀuBÿw‹Ëèfûÿÿ‹ð…öu
‹Ëè$ïÿÿ‹ð…öt ‹Ïè7òÿÿ…öu‹MSèãéÿÿ…Àu
…öt j
‹Ëèþÿÿj
‹ÏègâÿÿÿuìÿX‹p_[^É ÌÌÌÌÌ‹ÿU‹ìV‹u‹Îè<áÿÿ…À‰Et EP‹ÎèIáÿÿ…Àt j
‹ÈèIâÿÿƒ} uâ…öt j
‹Îè" ^] ÌÌÌÌÌ‹ÿV‹ñ‹…ÀtPè£ÿÿÿÿvj ÿ5ä ‹pèÏÿÿ^ÃÌÌÌÌÌ‹ÿU‹ìƒìt¡p ‹pSV‰Eü‹EW‹} j,‹Ù‰E˜èöÎÿÿ…ÀYtƒ ƒ` H ‰ ‰H$‰H(ë3À‹ð÷ÞöƒæòƒÆ‰…Ù ‹ÈèÖàÿÿ‹ð…ö…¹ Wè'Ïÿÿ‰C÷ØÀƒàòƒÀ‹ð…ž {¾‹p¥E"P¥j
j ¥h(‹pÿu˜¥ÿT‹p…ÀuijY¾Ø‹p}¬ó¥E¬Pf¥ÿü‹pD ‰EEPE¬PEŒPj j ÿu"ÇEŒ
ÿ8‹p…Àu EœPE¬Pÿü‹p…À|
uœ{¥¥¥¥ÿu"ÿX‹pSÿu˜èuôÿÿ‹ð…öt‹…Ût j
‹Ëèà ‹Mü_‹Æ^[è¿- É ÌÌÌÌÌ‹ÿU‹ìV‹ñèˆþÿÿöE
tVèÜÍÿÿY‹Æ^] ÌÌÌÌÌ‹ÿU‹ìQhH¡‹ph ¡‹pèRÎÿÿ…Àu@é‘ ¡L¡‹pVÿpèÑÿÿ‹ð÷ÞöFulS¾° èÖßÿÿ‹ X¡‹p‹Ëè!ßÿÿ…À‰EütGW‹Eü‹x‹G;EtEüP‹Ëè ßÿÿƒ}ü uáë$‹Ïè/éÿÿ‹ð…öuÿuü‹
X¡‹pè èÿÿj
‹Ïènûÿÿ_è¥ßÿÿ[h ¡‹pÿØ‹p‹Æ^É ÌÌÌÌÌ‹ÿU‹ìQ} ÿ vjWXé† ShH¡‹p» ¡‹pSè†Íÿÿ…Àu@ëm¡L¡‹pVÿpè?Ðÿÿ‹ð÷ÞöFuLW¾° è
ßÿÿ‹=X¡‹p‹ÏèXÞÿÿ‰Eüë‹H‹A;EtEüP‹Ïè\Þÿÿ‹Eü…Àuãë
ÿu èúÿÿ‹ðèüÞÿÿ_SÿØ‹p‹Æ^[É ÌÌÌÌÌ‹ÿV‹ñƒ> tè‡çÿÿF ‰ ‰F$FPÿà‹pƒ& ^ÃÌÌÌÌÌ‹ÿU‹ìƒì ƒeø SV‹ñ‹FƒøWu‹F$ë ƒø
u ‹F$ƒÀ,‰Eü‹Müè±Ýÿÿ‹Ø…Û‰]ôt ‹{‹F;Gv‹MüEôPè°Ýÿÿ‹]ô…Ûuâë‹}ô…ÛtD‹F;Gu<W‹Îè=ùÿÿ…Àt‹G@P‹ÏèÒùÿÿ‰Eøë‹MüEôPèoÝÿÿ‹]ô…Ût‹{ÿFƒ}ø t¸ƒ}ø uJ‹MüVSèçåÿÿ‹ø…ÿu ÇEø ë1ÿvÿvÿvhà‹pÿv ÿ5h ‹pè " …À‰Eøu‰~(ë ‹MüWè0æÿÿ‹Eø_^[ÉÃÌÌÌÌÌ‹ÿU‹ìVWj h€ @jj j ‹ñh Àÿv ÿˆ‹pƒøÿ‰F u
ÿÌ‹p‹øë3ÿ…ÿua‹FH‹}tHuÿw\ÿv è:( ë ÿw\ÿv è( EPh hL‹p‹ÎèXèÿÿ…Àuÿuÿv è' ÿuÿX‹p‹Î‰~$èdþÿÿ‹ø…ÿt‹F ƒøÿt PÿØ‹pƒN ÿ‰~ ‹Ç_^] ÌÌÌÌÌ‹ÿU‹ìƒìD‹MVEðP¾ Vè¢àÿÿ…À…*
WEüPV3ÿWhˆ‹pÿuðÿT‹p…À…
EìPEøPEôPÿuüè+Ñÿÿ…À…Ü EÜM¼‰}¼‰}؉E܉Eà‰Eäè
Üÿÿ…À…² S3Û9}ôvs‹EìWWWW‰EèEèPÿuøSÿuüÿL‹p…ÀuNj,èµÉÿÿ;ÇYtÿu‹Èè8Óÿÿ‹ðë3ö;÷t.ÿuø‹Îè¦õÿÿƒøuM¼ë;Çu
‹M Vè ãÿÿ…Àu ‹Îj
èÅ÷ÿÿC;]ôrM¼è Ûÿÿ;ljE[t'EPM¼è(Ûÿÿ‹ð‹Îè>åÿÿ;÷t j
‹Îè÷ÿÿ9}uÙM¼èÖüÿÿÿuüÿX‹pÿuðÿX‹p_^É ÌÌÌÌÌ‹ÿU‹ìSV‹ñ3Û9^Wt9jèôÈÿÿ;ÃYt
ÿ6‹ÈèºÒÿÿ‹øë3ÿ…ÿtÿv‹ÏèÎëÿÿj
‹Ï‹ØèŠÛÿÿëj[è-Òÿÿ…Ûu9ƒ~ ÿu3ƒ=h ‹pÿt*ÿvÿuè»Ýÿÿ‹ø…ÿtÿv ÿu èwÞÿÿ…Àt
W‹Îè_ýÿÿ‹ØèüÑÿÿ_^‹Ã[] ÌÌÌÌÌ‹ÿU‹ìQ‹Mè Úÿÿ…À‰EütJVW‹M‹øEüPè$Úÿÿÿu‹ðÿu ‹Îè-ÿÿÿƒøu ‹Îè(äÿÿ‹MWè$ãÿÿ…öt j
‹Îènöÿÿ‹Eü…Àuº_^É ÌÌÌÌÌ‹ÿU‹ìƒì Vj,èõÇÿÿ3ö;ÆYtH ‰0‰p ‰ ‰H$‰H(‰Eüë‰uü9uü„ù ‹MüèÛÙÿÿ…À…Ü EôPh VhP‹ph €ÿT‹p…À…Ç EìPEøPEðPÿuôè¥Îÿÿ…À…" S3Û9uðvzW‹EìVVVV‰EèEèPÿuøSÿuôÿL‹p…ÀuSjèPÇÿÿ;ÆYt
‰p‰p‰p ‹øë3ÿ;þt4jEäPÿuøÿÌ‹pƒÄ P‹Ïè<Òÿÿ…Àu
‹MüWè6áÿÿ…Àu j
‹ÏèíÙÿÿC;]ðrˆ_ÿuøVÿ5ä ‹pÿ‹p[ÿuôÿX‹pë
‹Müj
è¬ ‰uü‹Eü^ÉÃÌÌÌÌÌ‹ÿU‹ìQQSè·þÿÿ‹Ø…Ût~‹ËèlØÿÿ…À‰EøtjVWEøP‹ËèwØÿÿ‹ð‹E ÿv‹@Pÿ ‹p…Àu?‹Mè:Øÿÿ…À‰Eüt0‹MEüPèFØÿÿ‹øW‹ÎèoÙÿÿ…Àtÿuÿ6ÿwXÿuèÉôÿÿƒ}ü uЃ}ø uš_^Sè©öÿÿ[É ÌÌÌÌÌ‹ÿU‹ìQSè þÿÿ‹Ø…Ût|‹ËèÒ×ÿÿ…À‰EüthVW‹} EüP‹ËèÚ×ÿÿ‹ðW‹ÎèÙÿÿ…ÀtB‹Mè¥×ÿÿ…À‰E t3‹ME Pè±×ÿÿÿv‹@Pÿ ‹p…Àuÿuÿ6ÿwXÿuè1ôÿÿƒ
Everything makes sense in someone's mind
|
|
|
|
|
The average user doesn't mess around trying to delete random files in places that are hidden by default (on "noob" settings), either, so what does it matter that an average user wouldn't notice the lack of MZ and "!This program can not be run in DOS mode." etc?
The non-average user is just going to open it with CFF Explorer to see what kind of thing the dll does, which will then explode with an error message on the invalid dll. That is assuming he will come across the dll in some way which is rather unlikely if it's in system32.
Other suggestion - use NTFS alternate data streams
|
|
|
|
|
Now look what you have started.
|
|
|
|
|
Moi?! 
|
|
|
|
|
sí señor, usted.
|
|
|
|
|
Impossible since every application that runs does so AS the user that launched it. If the application can read/write the file, so can the user of that application. The two are indistiguishable from each other. When the user launches an app, the app gets a copy of the users security token, therefore, the two are indistinguishable from each other. Also, since a user cannot grant tehemselves more permissions than they already have, neither can the application that is using that users security token.
|
|
|
|
|
Does it have to be on the local file system? Perhaps use a web service to access the file on a remote server. Use encryption if you don't want anybody looking at the data as is crosses the wire. You can use the authentication scheme of your choice to prevent others from accessing the file using the web service.
|
|
|
|
|
|
So you've connected your database now?
|
|
|
|
|
Hi,
Yes Michel I connected to my database thanks to u help. 
Can u help me now Michel to complete my project 
Thanks
|
|
|
|
|
Sorry, list boxes and check boxes are not really my area  . More of a backend and system kinda of person...
Good Luck!
|
|
|
|
|
So I was taking a look into Windows Desktop Sharing and have found an example that I have downloaded and tested on my machine. The issue is the one I downloaded is a client and server that are both Windows Forms (not a service).
So I attempted to try a service.
When I run my service as LOCAL SYSTEM (with access to desktop) it will connect but will automatically go to the black screen with a PAUSE symbol on it. If I run the service as a NETWORK SERVICE I get an error code of 1028... if I run the service as a DOMAIN admin user I get an error of 2308.
Server:
protected RDPSession _rdpSession = null;
private string invitation;
public ITMgmt()
{
InitializeComponent();
}
protected override void OnStart(string[] args)
{
_rdpSession = new RDPSession();
_rdpSession.OnAttendeeConnected += new _IRDPSessionEvents_OnAttendeeConnectedEventHandler(OnAttendeeConnected);
_rdpSession.OnAttendeeDisconnected += new _IRDPSessionEvents_OnAttendeeDisconnectedEventHandler(OnAttendeeDisconnected);
_rdpSession.OnControlLevelChangeRequest += new _IRDPSessionEvents_OnControlLevelChangeRequestEventHandler(OnControlLevelChangeRequest);
_rdpSession.Open();
IRDPSRAPIInvitation pInvitation = _rdpSession.Invitations.CreateInvitation("WinPresenter", "PresentationGroup", "", 5);
invitation = pInvitation.ConnectionString;
using (StreamWriter sw = File.CreateText("c:\\inv.xml"))
{
sw.WriteLine(invitation);
}
}
private void OnAttendeeConnected(object Attendee)
{
IRDPSRAPIAttendee pAttendee = Attendee as IRDPSRAPIAttendee;
pAttendee.ControlLevel = CTRL_LEVEL.CTRL_LEVEL_VIEW;
EventLog.WriteEntry("IT Management", "Connected: " + pAttendee.RemoteName, EventLogEntryType.Information);
}
private void OnAttendeeDisconnected(object Attendee)
{
IRDPSRAPIAttendee pAttendee = Attendee as IRDPSRAPIAttendee;
EventLog.WriteEntry("IT Management", "Disconnected: " + pAttendee.RemoteName, EventLogEntryType.Information);
}
private void OnControlLevelChangeRequest(object pObjAttendee, CTRL_LEVEL RequestedLevel)
{
}
I can't seem to attach visual studio to the service either. Keep saying there is a debugger already attached? I install the service with visual studios command prompt (installutil).
Anyways if you have any idea why this would work as a windows form and not this service please let me know. I do want to point out that you can see I have a event when a attendee connected and it actually fires because my event log does show that the user connected.
OS: Windows 7
VS: 2008
Client & Server on same computer at this point. Works with 2 windows forms this way.
|
|
|
|
|
Services with user interaction are severely deprecated in Vista and 7. Previously the user at the console ran in session 0, and so did the services. In Vista, only system processes and services run in Session 0, so they can't share the desktop anymore with the logged on user.
This change was made to prevent 'shatter attacks', where a non-privileged process ( running as the user ) could send Window Messages to a privileged process (running as LOCAL SYSTEM), possibly exploiting bugs in the privileged process.
So now when a service tries to display anything on the screen, the screen is dimmed, and the user is prompted to deal with the service.
If the user agrees, the desktop is switched to Session 0, and the Service is able to interact with the desktop (but NOT the user's desktop, that will be restored when the services has finished talking to the user.
To make a long story short: this will never work anymore.
|
|
|
|
|
Well that kind of sucks!
So basically I will need to create a Windows applications that runs in the background.. somehow making it where the user cannot close it or anything.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
