PowerShell $OutputEncoding defaults to ASCII. PowerShell by default represents strings in Unicode. When I create scripts using the ISE, they are created in Unicode.
The following command sends text to a file in Unicode:
echo Testing > test.txt
When I push these files to GitHub, the code view chokes on them because they aren't UTF-8.
I'm confused about the best solution, with the least amount of work during commit.
I know I could convert each file and then commit, but that seems cockeyed to me. Clearly, I can't change how PowerShell represents strings internally, nor would I want to.
What are others doing?
ISE preserves an existing file's encoding but when you create a new file with ISE it is always creates the file with Unicode encoding. This has nothing to do with the $OutputEncoding. IIRC it was deemed a bug late in the dev cycle - too late to fix. Anyway, you can work-around this by going to the command window the first time you save a file and execute:
$psISE.CurrentFile.Save([Text.Encoding]::ASCII)
After that, you can just press the Save button.
Related
I'm having a little problem automating a test with UFT (vbscript). I need to open a csv file, modify it, and then save it again. The problem is that when I open the file in Notepad++, it shows the encoding as "UCS-2 LE BOM". This file is then injected into our system for processing and if I change the encoding to ANSI, the injection will fail because the file seems to lose its column structure, and I'm not sure it is readable for the system anymore.
From what I understand, it's not possible to do it directly with vbscript but any idea how I could do it with powershell for example? Is there a notepad++ command line to change the encoding of a file for example?
Thanks
Unicorn.py generates a string that looks like
powershell -flag1 -flag2 "something " obfuscation; powershell "more gibbrish
Interestingly, if this command is saved in a file filename.txt Windows executes it before opening the file in notepad.txt (by which time the file is empty).
Why is the file executed despite the extension?
What does the script do when it encounters EOF after odd number of quotation marks?
Edited:
Unicorn (https://github.com/trustedsec/unicorn) is a script that "enables privilege elevation and arbitrary code execution". If you know what it means. Of course I did NOT put the actual string, just the key features.
Purely out of IT security interest.
I think that if you read the manual in unicorn.py, at absolutely no time does it say that the script should be left in the txt file.
The PowerShell script is written inside the txt file and called the "payload" (very hacker like). What is left for you is always how to execute this code on the victim's computer.
The manual proposes Word code injection, simply executing the PowerShell in cmd (I quote "Next simply copy the powershell command to something you have the ability for remote command execution."), Excel Auto_Open attack, and so on.
If reading the manual is too much there is always a video. The only time the "hacker" uses a notepad like is on his linux operated system (how ironic)… I watched it because I love this Papa Roach music Last Resort...
For those who are concerned about IT security I recommend this article dosfuscation. This is really instructive about how you have to be extra careful when receiving mails, outside document,... and how humanity can waste so much time spying, deceiving, inventing new twisted strategies... Aren't we great !
Windows like any other system has many system flaw but opening notepad is not one of them. Unless your notepad has been replaced by a hacker using unicorn…
There is an even number of brackets in the obfuscated script. Did you mix up '' with "?
Empty txt file means that you've sent the attack.txt over network to a drive accessible by updated antivirus and antivirus quarantined/deleted file contents. Since you didn't know about this interaction with antivirus your environment is NOT secure. Which means you might have other malware from previous test lurking on your "clean" network.
I am writing an mIRC script for a bot account to read a random line of text from a text file when a user keys in !read. As of now, when any user types !read, absolutely nothing happens. I have other commands set to work on TEXT commands, but this one seems to be the most puzzling, as I'm referencing a document rather than putting everything into the script itself.
on *:TEXT:!text:#: {
$read(C:\Program Files (x86)\mIRC\8Ball.txt,n)
}
My file is titled 8Ball.txt. What could be going wrong here?
Got it.
echo -a $read(C:\Users\Christopher\Desktop\8Ball.txt,n)
Changing the directory ended up doing it...it wasn't liking the location for some reason...I either blame me putting a / in front of echo, or I blame the space in Program Files (x86)
Your best move is to use the relative mIRC dir identifier $mircdir combing it with $qt which adds enclosing quotes.
$qt($+($mircdir,8Ball.txt))
Output:
"C:\Program Files (x86)\mIRC\8Ball.txt"
This way, you won't need to wonder why the script break when you changed the mIRC directory a year after.
I could not find this answer in the man or info pages, nor with a search here or on Google. I have a file which is, in essence, a text file, but it somehow got screwed up upon saving. (I think there are a few strange bytes at the front of the file accidentally.)
I am able to open the file, and it makes sense, using head or cat, but not using any sort of editor.
In the end, all I wish to do is open the file in emacs, delete the "messy" characters, and save it once cleaned up. The file, however, is huge, so I need something powerful like emacs to be able to open it.
Otherwise, I suppose I can try to create a script to read this in line by line, forcing the script to read it in text format, then write it. But I wanted something quick, since I won't be doing this over & over.
Thanks!
Mike
perl -i.bk -pe 's/[^[:ascii:]]//g;' file
Found this perl one liner here: http://www.perlmonks.org/?node_id=619792
Try M-xfind-file-literally in Emacs.
You could edit the file using hexl-mode, which lets you edit the file in hexadecimal. That would let you see precisely what those offending characters are, and remove them.
It sounds like you either got a different line ending in the file (eg: carriage returns on a *nix system) or it got saved in an unexpected encoding.
You could use strings to grab "printable characters in file". You might have to play with the --encoding though I have only ever used it to grab ascii strings from executable files.
CVS has the keyword substitution feature: in a text file you write $Header$ and, when you commit the file, CVS substitutes $Header$ with something like $Header: /repo/src.cpp,v 1.6 2009/03/12 14:53:14 luser Exp $
Is it possible to get the same feature when dealing with a binary Microsoft Word file?
Thank you.
The basic problem you have with a Word file is that it is effectively a binary file (as opposed to a plain-text file), so you cannot be sure a key string like "$Header$" doesn't appear somewhere (VB macro code, for example) by accident. CVS would expand that key string, and suddenly something apparently unrelated (VB macro code, for example...) stops working.
Using CVS? Not likely. Even if $Header$ doesn't appear anywhere in your Word document (as DevSolar suggested it might), where do you place that string? Word stores text in its proprietary binary format, but CVS looks for plain text.
On the other hand, I'm sure you can achieve the effect by using either an XML Word format, or a Word macro.
Seems almost impossible with the traditional .doc format. Some creative work might allow you to create a process for making it happen with the newer XML format. I'm not sure CVS can do the job even then, but using a post-commit hook in subversion might make it more reasonable to pull off.