I have been studying privilege escalation on windows and came across some powershell script that look up vulnderabilties.
When i run these ( multiple scripts) I get no output while the documentation i find on them and video's all show output. Unless I specifically tell it to output it to a file,
This makes me think it has something to do with my system. I am running windows 7 64-bit on a local standard user.
For example i used:
https://github.com/rasta-mouse/Sherlock
and:
https://github.com/PowerShellEmpire/PowerTools/tree/master/PowerUp
Did you try to check if your current user has changed to Administrator ?Maybe there is a GPO or theses privileges esclations are not working for your version
I am able to use Set-Culture (Powershell as Admin) to set the Current Culture to "en-DE" which is English (Germany). However, when I run the different PS commands to view the Current Culture, I am still getting en-US. I checked my Region (Format) and Location as well.
Do I have to change the system locale as well to Germany (German) ?
This is causing an error in an application, because the datetime format is different from en-DE to en-US and causing the date to be read incorrectly.
When I Set-Culture to de-DE, everything appears to be in working order.
I make sure to run Powershell Console as Administrator, Set-Culture, close console. Open Powershell and run Get-Culture, [CultureInfo]::CurrentCulture, [CultureInfo]::CurrentUICulture and a few more to check and and still getting en-US
Note: Use of en-DE as a culture identifier - i.e., mixing language en (English) with normally unrelated region/country DE (Germany) - requires Windows 10 with release channel 1607 or later or Windows Server 2016, according to Microsoft.
However, there's a bug that prevents use of such mixed cultures, observed on Windows 10 Pro (64-bit; Version 1709, OS Build: 16299.371)
While you can successfully set such mixed-culture values with Set-Culture, subsequent sessions do not recognize it and fall back to en-US (as reflected in $PSCulture, Get-Culture and [cultureinfo]::currentCulture)
This problem has been reported on UserVoice.
Note that PowerShell Core is not affected (but it doesn't support Set-Culture).
The rest of this answer discusses persistently setting the current user's culture in general, irrespective of the bug.
Set-Culture - via the registry - sets the culture for future PowerShell sessions (only), not (also) for the current session.
Get-Culture, by contrast, only ever reports the current session's culture at session-startup time. That is, if you change the culture during a session (see below), it will not be reflected in Get-Culture.
In order to also apply the newly set culture to the current session, run the following in addition to the Set-Culture call:
[cultureinfo]::CurrentCulture = 'de-DE'
Caveat re interactive (command-line) use:
In Windows PowerShell (still as of v5.1), the active culture is reset after every command submitted; e.g.,
[cultureinfo]::CurrentCulture = 'de-DE'; Get-Date works as expected, because it is part of the same command line, but when executing just Get-Date as the next command, the current culture has reverted to the one that was current at session-startup time.
This problem has been fixed in PowerShell Core.
This perhaps surprising asymmetry - Set-Culture only applying to future sessions, but Get-Culture reporting the current session's (startup) culture - is something that may change in future PowerShell Core versions.
Env:
OS. Windows 7 client machine
Powershell v. 4
This could be a duplicate question,but the solution provide to this other question unfortunately did not worked for me.
I tried both in Powershell shell*as administrator and in ISE.
When indeed I run that in PS:
Update-Help -UICulture en-US
I just get another prompt apparently doing nothing.
Same for :
Update-Help -UICulture en-US
Still getting error non in English(my operating system language is in German and I don't have control to change it).
I also tried to include the $ENUS and then invoke it in both profile and machine profile. Same, still having errors in German.
Then I found this, and included in the profile that script, but still without success.
Only thing is that
$PSUICulture
is returning
de-DE
But using (as from official doc) :
Set-Culture -CultureInfo en-US
is giving me an error "Die Benennung "Set-Culture" wurde nicht als Name eines Cmdlet" basically that "Set-Culture" is not a recognised as Cmdlet
At this point seems to me that I cannot change error's language as it takes that of the OS.
Anything I did not considered, checked?
In my Windows 7 Ultimate I created an additional local user,
loaded the English language pack and changed the primary language for that user to English. (these settings still apply after having upgraded to Windows 10 some time ago)
I have bitwise SSH-server and bitwise SSH-client running (free for private use) and login via SSH to the other account on the same machine.
Using PostgreSQL when I connect to a db using \c testdb inside PostgreSQL Database SQL Prompt. I successfully connect to the db but getting the following warning:
postgres-# \c testdb
WARNING: Console code page (437) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
You are now connected to database "testdb" as user "postgres".
testdb-#
What does this warning mean? How to resolve it?
From the psql documentation:
psql is built as a "console application". Since the Windows console
windows use a different encoding than the rest of the system, you must
take special care when using 8-bit characters within psql. If psql
detects a problematic console code page, it will warn you at startup.
To change the console code page, two things are necessary:
Set the code page by entering cmd.exe /c chcp 1252. (1252 is a code
page that is appropriate for German; replace it with your value.) If
you are using Cygwin, you can put this command in /etc/profile.
So to remove that warning you need to execute chcp 1252 before you enterpsql. Using chcp without parameters gives you the current codepage.
The default codepage for CMD.exe is different than the default for postgres... To change for CMD.exe using the REGISTRY try this:
Start -> Run -> regedit
Go to [HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor]
Add new string value named "Autorun" with value "chcp 1252"
Then reopen CMD.exe
To make it even more obvious, the file to which #user3423801 is adding the line
cmd.exe /c chcp 1252
is in the scripts directory where you installed Postgre.
For example, in my case it is
C:\Program Files\PostgreSQL\9.3\scripts\runpsql.bat
Open cmd.exe and run regedit.
Go to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor
New a string value named: Autorun and change the value to be chcp 1252
Done.
Reference: https://stackoverflow.com/a/30100565/8396969
Please don't assume that Unix fixes work for Windows Users. For Windows 10, and PostgreSQL 12, combining the answers by "user3423801" and "numbers longer" worked for me. (The Windows Registry hack would not work. I did not try rebooting yet.) It is better to fix it in the PSQL startup script anyway.
The file location C:\Program Files\PostgreSQL\12\scripts contains the file runpsql.bat, into which you must insert the cmd.exe /c chcp 1252 command in the right location. So the top of your edited file should look like the 5 or 6 lines below.
#echo off
REM Copyright (c) 2012-2014, EnterpriseDB Corporation. All rights reserved
REM PostgreSQL server psql runner script for Windows
cmd.exe /c chcp 1252
SET server=localhost
SET /P server="Server [%server%]: "
The answer of dvdgsng is correct but with code example is more obviously.
#echo off
REM Copyright (c) 2012-2014, EnterpriseDB Corporation. All rights reserved
REM PostgreSQL server psql runner script for Windows
cmd.exe /c chcp 1252
SET server=localhost
SET /P server="Server [%server%]: "
Or you can simply type cmd.exe /c chcp 1252 in the Command Prompt window.
you just go to the power-shell or cmd.exe and type the command chcp 1252 or whatever the page number it wants "the one that is the windows code page". If the problem still persists, just open the console properties 'By clicking the power shell icon on the top left of the console window and choosing properties from the drop-down menu' and change the font to "Lucida Console". It worked for me, But you have to open power-shell as an Administrator.
The answers above are okay, but don't mention anywhere that Windows 1252 encoding is good for English language versions of Windows AND the other Western European Languages. This completes the answer for those people who may get confused about the aforementioned application to German language encoding. Yes it works for English without umlauts and other special characters needed for German, Spanish, French, Italian, Romanian, Hungarian, etc.
https://en.m.wikipedia.org/wiki/Windows-1252
What is Windows 1252 encoding?
Windows-1252 or CP-1252 (code page 1252) is a single-byte character encoding of the Latin alphabet, used by default in the legacy components of Microsoft Windows for English and some other Western languages (other languages use different default encodings).
After much digging for an answer that made sense to me, I found this help email chain at the PostgreSQL site which basically says to run chcp 1252 from inside an open command window.
I was then able to run my PostgreSQL commands without the code warning.
NOTE: this change does not persist so you have to run it every time you open a new command window where you plan to use PostgreSQL commands.
For Postgres 11
"WARNING: Console code page (437) differs from Windows code page
(1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details."
If you aren't an administrator on your machine
Add a line "chcp 1252" to the pg_env.bat script found in the base directory of your postgres installation.'
i.e. "C:\Program Files\PostgreSQL\11"
If you are and Administrator on your machine
you can modify the registry to run the line everytime you run "cmd.exe" as mentioned above.
I couldn't figure out how to set it for Cygwin globally. This seemed to work though in my bash script
#!/bin/bash
cmd.exe /c chcp 1252 && psql -h myserver.postgres.database.azure.com -U myuser#prod-au -d mydatabase
Basically, set your console application encoding from 8-bit to utf-8 Windows 1252.
For git bash users
run the command chcp.com 1252 before running postgres
chcp is a windows console command, so to execute it on git bash you might need to add .com
git bash can't extend chcp to a full executable on its own, so you need to type the full command.
here
On the terminal screen go to the following directory;
C:\Program Files\PostgreSQL\14\bin
note: whichever database version you are using, go to the bin folder of the db version file.
Before creating a user or accessing the database user, you must write the following code;
cmd.exe /c chcp 1252
wmic process get /format:csv
What is wrong with this command in Windows 7?
I get:
Invalid XSL format (or) file name.
It's a bug in the wmic command. It's been suggested to copy XSL files into the %WINDIR%\system32 (or equivalent if 64 bit.) However, the command below works just as well without the need to copy files:
wmic process get ProcessId,Description,CommandLine,ExecutablePath,ParentProcessId /format:"%WINDIR%\System32\wbem\en-us\csv"
Of course, the "en-us" will be different for different locales.
If you want to redirect output to a file add a switch /output:"your filename here" before the process keyword
This is a bug in Windows 7 and Windows Server 2008 (also R2) WMIC. When you use (for example) Dutch regional settings in an English Windows installation, WMIC searches for the xsl files inside C:\Windows\System32\wbem\nl-NL, instead of C:\Windows\System32\wbem\en-US where they are.
Workarounds:
Copy or move the C:\Windows\system32\wbem\en-US\*.xsl files up into the C:\Windows\system32\wbem\ folder.
Change your regional settings to match your Windows language version, log out and back in.
Specify the full path: WMIC process get /format:"%WINDIR%\System32\wbem\en-US\csv".
This is a Windows 7 wmic bug. Change the International setings to English (United States), reboot and test.