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,819 other followers

Archive for the ‘CommandLine’ Category

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 »

Boolean Values and Operators

Posted by jpluimers on 2019/09/26

TL;DR from [WayBackAutomating the world one-liner at a time… Boolean Values and Operators:

In PowerShell use the built-in constants $false and $true, as strings will be converted to booleans with results you don’t like

–jeroen

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

 
%d bloggers like this: