The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,837 other followers

Archive for the ‘PowerShell’ Category

Mad With PowerShell

Posted by jpluimers on 2020/02/19

This is such a cool blog: Mad With PowerShell (Tim Curwick’s PowerShell blog, tips and tricks, tools and techniques, explanations and explorations).

I bumped into it by finding these two:

What I like most is that it gives great insight on how and why the internals of PowerShell work the way they do, and how to use that to your advantage.

–jeroen

Posted in CommandLine, Development, PowerShell, PowerShell, Scripting, Software Development | Leave a Comment »

Mad With PowerShell: FileInfo and DirectoryInfo objects are not populated upon creation in PowerShell

Posted by jpluimers on 2020/01/16

[WayBack] Mad With PowerShell: FileInfo and DirectoryInfo objects are not populated upon creation in PowerShell.

TL;DR:

  • Apart from the FullName property, the other poprerties of FileInfo and DirectoryInfo are populated later than their instance creation
  • A call to their Refresh method populates or re-populates them
  • That method is implicitly called when you request other properties than FullName

Example: see the [Archive.is]fileinfo.cs: Length property

–jeroen

Posted in .NET, C#, CommandLine, Development, F#, PowerShell, Software Development, VB.NET | Leave a Comment »

ρσℓα¢ķ͌͌͌͌͌͌͌͌͌͌͌͌͌͌ on Twitter : “The PowerShell console history file isn’t just useful for DFIR peeps, red team-ers should check it too! 4096 entries by default, here’s the path…”

Posted by jpluimers on 2020/01/15

Not sure why, but I checked a few of my systems and no  file at %userprofile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt

Heck: no ConsoleHost_history.txt files on those systems anywhere.

[WayBack] ρσℓα¢ķ͌͌͌͌͌͌͌͌͌͌͌͌͌͌ on Twitter : “The PowerShell console history file isn’t just useful for DFIR peeps, red team-ers should check it too! 4096 entries by default, here’s the path: %userprofile%\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt”

–jeroen

Read the rest of this entry »

Posted in CommandLine, Power User, PowerShell, PowerShell | Leave a Comment »

Delphi, decoding files to strings and finding line endings: some links, some history on Windows NT and UTF/UCS encodings

Posted by jpluimers on 2019/12/31

A while back there were a few G+ threads sprouted by David Heffernan on decoding big files into line-ending splitted strings:

Code comparison:

Python:

with open(filename, 'r', encoding='utf-16-le') as f:
  for line in f:
    pass

Delphi:

for Line in TLineReader.FromFile(filename, TEncoding.Unicode) do
  ;

This spurred some nice observations and unfounded statements on which encodings should be used, so I posted a bit of history that is included below.

Some tips and observations from the links:

  • Good old text files are not “good” with Unicode support, neither are TextFile Device Drivers; nobody has written a driver supporting a wide range of encodings as of yet.
  • Good old text files are slow as well, even with a changed SetTextBuffer
  • When using the TStreamReader, the decoding takes much more time than the actual reading, which means that [WayBack] Faster FileStream with TBufferedFileStream • DelphiABall does not help much
  • TStringList.LoadFromFile, though fast, is a memory allocation dork and has limits on string size
  • Delphi RTL code is not what it used to be: pre-Delphi Unicode RTL code is of far better quality than Delphi 2009 and up RTL code
  • Supporting various encodings is important
  • EBCDIC days: three kinds of spaces, two kinds of hyphens, multiple codepages
  • Strings are just that: strings. It’s about the encoding from/to the file that needs to be optimal.
  • When processing large files, caching only makes sense when the file fits in memory. Otherwise caching just adds overhead.
  • On Windows, if you read a big text file into memory, open the file in “sequential read” mode, to disable caching. Use the FILE_FLAG_SEQUENTIAL_SCAN flag under Windows, as stated at [WayBack] How do FILE_FLAG_SEQUENTIAL_SCAN and FILE_FLAG_RANDOM_ACCESS affect how the operating system treats my file? – The Old New Thing
  • Python string reading depends on the way you read files (ASCII or Unicode); see [WayBack] unicode – Python codecs line ending – Stack Overflow

Though TLineReader is not part of the RTL, I think it is from [WayBack] For-in Enumeration – ADUG.

Encodings in use

It doesn’t help that on the Windows Console, various encodings are used:

Good reading here is [WayBack] c++ – What unicode encoding (UTF-8, UTF-16, other) does Windows use for its Unicode data types? – Stack Overflow

Encoding history

+A. Bouchez I’m with +David Heffernan here:

At its release in 1993, Windows NT was very early in supporting Unicode. Development of Windows NT started in 1990 where they opted for UCS-2 having 2 bytes per character and had a non-required annex on UTF-1.

UTF-1 – that later evolved into UTF-8 – did not even exist at that time. Even UCS-2 was still young: it got designed in 1989. UTF-8 was outlined late 1992 and became a standard in 1993

Some references:

–jeroen

Read the rest of this entry »

Posted in Delphi, Development, Encoding, PowerShell, PowerShell, Python, Scripting, Software Development, The Old New Thing, Unicode, UTF-16, UTF-8, Windows Development | Leave a Comment »

PowerShell: fixing `Get-HotFix` having empty `InstalledOn` entries

Posted by jpluimers on 2019/11/12

On some systems, Get-HotFix has many entries with an empty InstalledOn column.

This at least shows there is a date-format difference, but now the Source column is empty.:

Get-HotFix | Select-Object Source,Description,HotfixID,InstalledBy,InstalledOn,@{Name="InstalledOnValue";Expression={$_.psbase.properties["InstalledOn"].Value}} | Out-GridView

I contemplated using Microsoft.Update.Session in the scripts below, but it requires WinRM, the server side implementation of WS-Management – Wikipedia:

[ERROR] [DevMachine] Connecting to remote server DevMachine failed with the following
[ERROR] error message : The client cannot connect to the destination specified in the
[ERROR] request. Verify that the service on the destination is running and is accepting
[ERROR] requests. Consult the logs and documentation for the WS-Management service run
[ERROR] ning on the destination, most commonly IIS or WinRM. If the destination is the
[ERROR] WinRM service, run the following command on the destination to analyze and conf
[ERROR] igure the WinRM service: "winrm quickconfig". For more information, see the abo
[ERROR] ut_Remote_Troubleshooting Help topic.
[ERROR] + CategoryInfo : OpenError: (DevMachine:String) [], PSRemotingTr
[ERROR] ansportException
[ERROR] + FullyQualifiedErrorId : CannotConnect,PSSessionStateBroken

This is a reminder to find and document a proper fix for this.

This at least works:

Get-HotFix | Select-Object Source,Description,HotfixID,InstalledBy,InstalledOn,@{Name="InstalledOnDateTime";Expression={[System.DateTime]::Parse($_.PSBase.Properties["InstalledOn"].Value,[System.Globalization.CultureInfo]::GetCultureInfo("en-US"))}} | Out-GridView

Some links that hopefully help with proper documenting it:

–jeroen

Read the rest of this entry »

Posted in CommandLine, Development, PowerShell, PowerShell, Scripting, Software Development | Leave a Comment »

 
%d bloggers like this: