|
|
Thanks Luc. I think what I'll do is verify the signature of the file that's connecting, and then only allow executables that are signed with my certificate.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Interesting. If that works, it could be a worthy subject for an article...
Luc Pattyn [My Articles]
The Windows 11 "taskbar" is disgusting. It should be at the left of the screen, with real icons, with text, progress, etc. They downgraded my developer PC to a bloody iPhone.
|
|
|
|
|
Richard Andrew x64 wrote: verify the signature of the file that's connecting, and then only allow executables that are signed with my certificate
Keep in mind that process hollowing[^] could still be used by malicious code to connect to the named pipe by masquerading as your binary. Verifying the signature doesn't give you very much. You would be back to share permissions and file system ACLs accessible by the caller.
|
|
|
|
|
Randor wrote: Verifying the signature doesn't give you very much.
Thanks for the tip.
Keep in mind I'm not only verifying that the signature is valid, I'm verifying that it was signed with my certificate. Does what you're saying still apply?
EDIT: OK I read the article about process hollowing, and you're right. My technique wouldn't defend against it.
Is there any other method you would recommend to secure the named pipe?
The difficult we do right away...
...the impossible takes slightly longer.
modified 28-Jan-22 14:06pm.
|
|
|
|
|
Richard Andrew x64 wrote: Is there any other method you would recommend to secure the named pipe?
Unfortunately Windows is designed to allow processes to modify the memory of other processes running at the same integrity level. I don't think there is any way to do remote attestation on a named pipe that includes memory integrity.
The only thing I can think of would be running your client under the protection of 'Protected Process Light' (PPL) combined with verification of the code signature. But it's not a good solution, (it's very restricting) and not offered to the general public.
|
|
|
|
|
I wasnt sure how to phrase the question in the subject, but I am writing a program for work that will do fill calculations for conduit.
I need a way to store wire sizes with the corresponding name of the wire, so that its easy to retrieve, edit or update within the program.
I was thinking of using the Settings.settings, but is that the best way/ method to use?
Suggestions?
Richard
Disable Vet
Grandfather
Pain in the @ss
|
|
|
|
|
It sort of depends on how many different types there are, and whether you need any other information stored with them. A simple JSON or XML file would work for a reasonable sized sample. Both types are fairly easy to manage in .NET.
|
|
|
|
|
I am storing wire types and their outer dia. size.
2 THHN/THWN & its OD of .378
8 THHN/THWN & its OD of .213
10 THHN/THWN & its OD of .161
and so forth. I would be search for the wire type name to get to the OD for the calculations.
Richard
Disable Vet
Grandfather
Pain in the @ss
|
|
|
|
|
I think my suggestions still hold; XML and JSON are common standards so are better than creating your own file format. The only downside is that you need to read all he records into a List<t> before you begin. And unless you have thousands (or even just hundreds) of records then a database is probably overkill.
|
|
|
|
|
If you have it available, an SQL Database is a good approach, because it's easy to share among multiple users and multiple apps - and "basic information" like product / part descriptions have a tendency to grow and get used for other things.
Storing it in a DB means it becomes more readily available company wide, and can thus be used for mreo things.
It really depends on what you are doing, but generally settings is a poor place to keep "general" information - app specific data like where to display it, who logged in last, what colours they prefer, that sort of thing is fine, but once you start with actual data it gets unwieldy.
And while JSON / XML as suggested by Richard are fine, they can get problematic quickly, if they have two or more users / apps processing the same data. Not saying they are bad - I use JSON a fail amount - but I find that they are better for sending "one-time" information rather than as a "updatable" store.
There is also the fun of deciding where to store them: since production software is normally installed in the Program Files folder that can cause problems since it's generally write protected for anti-virus reasons. With a "proper database" the server takes care of that and allows the data to the shared and if necessary updated by multiple sources.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Odds are, unless it's "lots of data" that changes a lot, you're better off creating internal lists and dictionaries; defining them as static; and loading them in static constructors.
At the very least, you'll need a "data repository" in memory, so you should prototype that in code with small sample data instead of sweating input files / databases early on.
It's easier to change your "code model" first, instead of any file / database model; assuming you even need a settings / database file.
In fact, a "database model" can be generated from your "code model" once you have that figured out; if needed, using Entity Framework and SQLite, say. ("Pro" marketing)
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Using Settings would be fine if it's just a handful of wire sizes, but it gets unwieldy pretty fast. Settings is better for recording who logged in last or the last position of a form.
If the number of wire sizes is fairly small (like under 100) and not subject to change, it might be simpler to just enter them into a static dictionary or list. This is especially true if your application doesn't already use a database. In the case of Settings, the key has to be hardcoded, (e.g. Properties.Settings.Default.Wire14Size), but with a dictionary, the key can be a string.
This is from an application that reads PDFs. It can tell the measurements of each page, but how to display the common page-size name?
var paperSizes = new Dictionary<PointF, string>
{
[new PointF(LTRW, LTRH)] = "Letter Port",
[new PointF(LTRH, LTRW)] = "Letter Land",
[new PointF(LEGW, LEGH)] = "Legal Port",
[new PointF(LEGH, LEGW)] = "Legal Land",
[new PointF(TBLW, TBLH)] = "Tabloid Port",
[new PointF(TBLH, TBLW)] = "Tabloid Land"
};Then, somewhere else, some we have a page
PointF thisPage = new PointF(somePage.Width, somePage.Height); To determine the name of size of that page, we do this
if (paperSizes.ContainsKey(thisPage))
{
return paperSizes[thisPage];
}If you need to find out the size of something based on its name, just make the name the key in the dictionary.
|
|
|
|
|
The minute you say more than 1 user can see the data OR the number if wire type/size will need to be added to you will be better serve by implementing a database server (unless you are a VERY small company you probably have one already)
Once you move to a database served solution it open up a myriad of opportunities. Storing calculation results may be a simple one.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Richard A Knox wrote: I need a way to store wire sizes with the corresponding name of the wire, so that its easy to retrieve, edit or update within the program.
1. Where does the data come from in the first place. And how is that source managed right now.
2. How many exactly will there be. 10? 1000? 100,000?
3. How often do they change?
-----------------------------------
So if the above is
1/2. 10. Doesn't actually matter where they come from.
3. With 10 it will be not very often.
Solution: As suggested hard code it.
-----------------------------------
1. it is in a spreadsheet
2. There are more than 50,000
3. They add them weekly.
Solution: You will need a database. Either traditional relational or an object store.
You can create code that extracts if from the spreadsheet but I suspect that is just more work than is needed. For the first load dump the spread sheet to a file and then use a tool to load the entries into the appropriate table. That is probably easier (in some sense) using a traditional relational database.
You would also need a UI to search, update, delete, add entries and you would need to convince the people that do this now to use this instead of the spread sheet. Otherwise you will need to complicate the above process by loading the data on a scheduled basis from the spreadsheet (same process as above.)
|
|
|
|
|
Hy friends i have the fallow code
In the marked place with ** I need a a close command for the generated form!!!!
Visible=false and this.close(); NOT WORK
HELP ME PLS!!!
THX
PROGRAM CODE SCHAME
FORM 1 WITH BUTTON1 =>WHEN I click to button 1 =>generate a new form and button
When I click to close button in then new form i like to close the new form and let just the first form
open
Form 1 Button 1
{
Form tmpform = new Form(); /*TEMPORARY FORM CODE*/
tmpform.StartPosition = FormStartPosition.CenterScreen;
tmpform.Size = new Size(968, 480);
tmpform.Text = "Cyberdesk-Nagyitó";
tmpform.MaximizeBox = false;
tmpform.Show(); /*TEMPORARY FORM CODE*/
TextBox tempbox = new TextBox(); /*TEMPORARY TEXTBOX CODE*/
tempbox.Text = Box_Ugy.Text;
tempbox.Multiline = true;
tempbox.Location = new Point(3, 3);
tempbox.Size = new Size(920, 400);
tempbox.Font = new Font("Calibri", 12);
tempbox.ForeColor = Color.Black;
tempbox.Padding = new Padding(6);
tmpform.Controls.Add(tempbox); /* /*TEMPORARY TEXTBOX CODE*/
Visible = false;
/*TEMPORARY BUTTT*/
Button gergo = new Button();
tmpform.Controls.Add(gergo);
gergo.Text = "Back";
tmpform.Controls.Add(gergo);
gergo.Location = new Point(6, 407);
gergo.Size = new Size(75, 23);
gergo.Show();
InitializeComponent();
gergo.Click += gergo_Click;
tmpform.Controls.Add(gergo);
}
private void gergo_Click(object sender, EventArgs e)
{
********===========>Here i need a form.close()
FO_FRegister firmr = new FO_FRegister();
firmr.Show();
|
|
|
|
|
Member 15512677 wrote: Visible = false;
whose visibility would that be?
Luc Pattyn [My Articles]
The Windows 11 "taskbar" is disgusting. It should be at the left of the screen, with real icons, with text, progress, etc. They downgraded my developer PC to a bloody iPhone.
|
|
|
|
|
I don't know if this helps, but you know that form.Show() doesn't display the form and wait for you to interact with it? Try using form.ShowDialog().
|
|
|
|
|
The problem is that Close will do just that: close the form - and since Form1 is almost certainly the "startup form" when it closes the system automatically closes the application which closes all forms and exits completely.
I'm just guessing here but it looks like you have a login screen or similar which you want to display, then close and remove when the user logs in. That isn't the way I'd do it - particularly since your current code appears to be adding controls and handlers to a different form, which is a bad idea.
Instead, make your "main display" the startup form, and in the Load event use ShowDialog to display the login form. When that exits, the code will continue from that point and you can add your controls to the current form if the login succeeded.
That way, forms don't need to "know" what each other is doing, and closing the main form terminates the app so you don't have to hassle with it!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I am working with EPPlus which generate excel file. now i have to hide range of columns. this code i used to hide range of columns in one go.
var rangecol = ws.Cells["M1:P1"];
var hiddenColumns = rangecol
.Select(cell => cell.Start.Column)
.Distinct()
.Select(rangecol.Worksheet.Column)
.ToList();
foreach (var column in hiddenColumns)
{
column.Hidden = true;
}
the above code is working and hiding columns but if there are 4 columns in range then it is hiding 4 columns individually not hide in one block. i want 4 columns should be hide in one block instead of 4 blocks.
please tell me what mistake is there in my code for which groups of columns are not getting hidden in one block. Thanks
|
|
|
|
|
What do you mean by "hidden in one block"? As far as I can see, at least in Microsoft Excel, there is no behavioural difference a sheet with four adjacent columns hidden one-by-one and a sheet where the four columns were selected and all four were hidden at the same time.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
In VBA it would be (for the columns from D to F):
Columns("D:F").Select
Selection.EntireColumn.Hidden = True
Try to find something similar in C#
|
|
|
|
|
... I Introduction
Imagine you have bright young student sitting down with you, whom you've introduced to Linq, and generics ... and, they've had no problems mastering 'Select and 'Where, 'Aggregate, etc.
You have introduced them to the use of 'yield return' in a method to return an IEnumerable they can turn into an instance of a collection. They "get that," and get use of yield means they can skip direct assignment to a pre-defined, initialized collection, or, a collection instance reference passed in as an 'out parameter.
And you are trying to explain to them the "deferred iteration/evaluation" aspect of IEnumerable, and the way that enables some advanced practices (function chaining).
At that point, you can sense the student is hesitant; you ask her/him what's really on their minds, and, because they trust you, they tell you. They ask interesting questions like:
Is there any real reason to use an IEnumerable ?
What's so useful about deferred evaluation ?
Isn't deferred evaluation dangerous because you have no idea of what might have changed in the time between assembling the IEnumerable and iterating/evaluating it ?
Why can't I test an IEnumerable to see if it's empty, or null; why do I have to trigger iteration with 'Count() to see how many items it has, and, why can I only use 'Any to see if there are no items in it without triggering iteration..
... II Context
I speak of an IEnumerable<T> returned from a Function (C# Func) that is ready be iterated over (has items).
I've had some interesting exchanges with my esteemed colleagues @RichardDeeming and @HaroldAptroot on this subject in this recent thread, here: [^].
I won't recapitulate that thread here, both because I'd like to hear your initial responses, and, I don't want to, possibly, misrepresent Richard or Harold's views.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
modified 22-Jan-22 15:52pm.
|
|
|
|
|
So in terms of teaching...
BillWoodruff wrote: What's so useful about deferred evaluation ?
The data returned is in memory.
Your computer has 32 gig of memory (or whatever it is.)
The IEnumerable returns 32 gig number of entries.
Where does it fit into memory if you did it all at once?
(Of course not saying that would be a good idea, but rather as a thought experiment.)
BillWoodruff wrote: Why can't I test an IEnumerable to see if it's empty, or null; why do I have to trigger iteration with 'Count() to see how many items it has, and, why can I only use 'Any to see if there are no items in it without triggering iteration..
The interface can only do what the interface does. This specific interface is very old and was only designed, very likely, with in memory arrays/lists in mind. Enhancing it now would break everything.
Might want to mention there are other ways to do it that would allow one to do that even for large sets (so not bringing everything into memory.) But also mention that using linq to process large sets in memory is going to be a problem regardless.
BillWoodruff wrote: Isn't deferred evaluation dangerous because you have no idea of what might have changed in the time between assembling the IEnumerable and iterating/evaluating it ?
What if you have the set in memory and the source changes between when you use it and then? How is that not the same problem? There is no such thing as absolute anything in the universe including time. So understand the problem and define the rules to deal with the differences that will occur. Example is ordering something online but while you are ordering something else the first item gets all used up by other people's orders. So when you finally go to pay it tells you it out of stock. When you started it was there but by the time it was needed it was gone.
|
|
|
|
|
jschell wrote: This specific interface is very old
The original non-generic version is based on COM's IEnumVARIANT[^], so it's practically prehistoric. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
