I've got a little batch file and it looks like this:
.\batchisp.exe –device at32uc3b1512 –hardware usb –operation erase f memory flash blankcheck loadbuffer G3Pro_USB.hex program verify start reset 0
The whole line is fine and works correctly if I run it straight in PowerShell. However, if I run the batch file, it runs this:
.\batchisp.exe ΓÇôdevice at32uc3b1512 ΓÇôhardware usb ΓÇôoperation erase f memory flash blankcheck loadbuffer G3Pro_USB.hex program verify start reset 0
Which does not work, because as you can see, the -'s have changed into ΓÇô's... Can anybody tell me why this is and how to fix it?
This is because the – marks are not - characters. They are actually endashes. These usually are caused by Word's automatic en/emdashing.
Powershell is smart enough to convert the endashes to dashes as "arguments", but cmd is not.
To fix this issue, replace – with -. A regex search/replace that catches all the alternative dash types that works in notepad++ is: [–—‒] to -.
Related
I am currently working in SQR process, and had encountered an issue during file processing as it results to error due to special character, slanted apostrophe (’). It is a flat file saved as UTF-8. I tried changing it as ANSI and worked well, but how do I make my code work without changing the encoding?
On your open statement, try adding:
ENCODING=UTF-8
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.
Assuming a text file with 7718 characters (e.g. the contents cut and pasted from here)
The command fileread('myfile.txt') fails when I launch matlab with matlab -nodesktop but works in desktop mode.
Does anyone have any idea why?
If the number of characters in the text file is reduced to 1981 it works in -nodesktop mode.
Note:I do not know the exact number of characters at which it stops working.
Finally, I am using Matlab 7.8.0 (R2009a) on Windows7.
I can't reproduce this odd behaviour (Matlab 2010b & 2012b, both on Linux).
You could at least try to "debug" this type of behaviour by restricting the problem. The "fileread" routine does some checks on the file name (ischar, isempty), then opens the file (fopen), reads it (fread) and closes it (fclose) - rather simple basic stuff. For reference, type "edit fileread" into the command line of the matlab desktop and try running down the routine step by step.
If "fread" causes the whole thing to crash and if you're bound to this version of Matlab, try implementing a "fix". "fread" accepts a few more parameters than what is used in "fileread" (the file ID and the precision "char" only): FREAD(FID,SIZE,PRECISION,SKIP,MACHINEFORMAT). Specifying more parameters may help (wild guess but worth a try).
I have a fairly simple question that has me stymied. I am trying to run an executable built from a simple C program using MATLAB as a shell, i.e. using the following MATLAB code:
FileName = ['D:\Users\person\Desktop\MATLAB\GUI','\Program.exe &'];
dos(FileName);
The executable correctly begins running, but crashes giving the error:
Debug Assertion Failed!
Program: D:\Users\person\Desktop\MATLAB\GUI\Program.exe
File: f:\\dd\vctools\crt_bld\self_x86\crt\src\fscanf.c
Expression: (stream != NULL)
The programs opens a text file, reads the input, performs math functions, and writes outputs back to another text file. I assume that this error means there is a problem reading from the text file, BUT-- when I run the executable by itself (i.e. Windows Explorer doubleclick), it executes flawlessly, as I would expect.
So, it's only MATLAB pointing to the file location that is causing the crash. Any ideas? Thank you.
Sounds like relative paths are the culprit. The Matlab command is running from whatever directory you've specified within Matlab; cmd runs from root or something like that (don't know much about Dos). That's why it works when you specify absolute paths. Change your Matlab directory to DOS root, and see if it works as originally coded.
Edit: Note that it's the path to whatever file Program.exe is trying to read that's the problem, not the path to Program.exe itself.
I am new to UNIX and when I was reading a book about UNIX, I came across following two problems that I didn't understand. I would really appreciate your help.
1) Look up the man page for the file command, and then use it on all files in the /dev directory. Can you group these files into two categories?
2) Run the tty command, and note the device name of your terminal. Now use this device name(/dev/pst/6) in the command cp /etc/passwd /dev/pts/6. what do you observe?
Fair question really... it's so easy for us to take so much for granted.
To read the manual page for the command called file, just type...
man file
...which will present a lot of information that will probably be quite confusing, but you'll get used to this stuff pretty quick if you keep at it. Crucially, file is a program that tries to categorise the files you ask it to. If you type...
file /dev/*
...that will do what the question asked, and invoke file with a list of the files in the /dev/ subdirectory. The list is actually prepared by the "shell" program that you're typing into, which then executes the file program and passes it the list. file then outputs some description of the files. On my computer, and where [SHELL-PROMPT] will be different on your computer, I typed file /dev/* and part of the output looked like:
[SHELL-PROMPT] file /dev/*
...lots of stuff...
/dev/cevt: character special (255/176)
/dev/console: character special (5/1)
/dev/core: symbolic link to `/proc/kcore'
/dev/cpqci: character special (10/209)
/dev/cpqhealth: directory
/dev/crom: character special (255/180)
...lots of stuff...
/dev/md8: block special (9/8)
/dev/md9: block special (9/9)
/dev/mem: character special (1/1)
/dev/mice: character special (13/63)
/dev/mouse0: character special (13/32)
/dev/mptctl: character special (10/220)
/dev/net: directory
/dev/nflog: character special (36/5)
/dev/null: character special (1/3)
/dev/parport0: character special (99/0)
...lots of stuff...
There's a filesystem entry for each directory/file combination (known as a path) in the left column, and file is describing the content in the right. Those descriptions may not make a lot of sense, but you can see that some patterns: some entries are "block special", others "character special", some are directory which implies you may find more files underneath (i.e. ls /dev/net/*). The numbers after "special" files are just operating system identifiers to differentiate the files mentioned. The import of this is that input and output from some devices connected to the computer is being made possible as if the device was a file in the filesystem. That "file" abstraction is being used as a general model for input and output. So, /dev/tty for example is tty - or terminal - device. Any data you try to read from there will actually be taken from the keyboard you're using to type into the shell (in the simple case), and anything you write there will become visible in the same terminal you're typing into. /dev/null is another interesting one: you can read and write from it, but it's an imaginary thing that never actually provides data (just indicates and End-of-File condition, and throws away any data written into it). You can keep reading from /dev/random and it will produce random values each time... good if you need random numbers or file content for encryption or some kind of statistical work.
2) Run the tty command, and note the
device name of your terminal. Now use
this device name(/dev/pst/6) in the
command cp /etc/passwd /dev/pts/6.
what do you observe?
By typing "tty" you can ask for the device representing your terminal...
[SHELL-PROMPT] tty
/dev/pts/11
But, I just said /dev/tty is another name for the same thing, so there's normally no need to use the "tty" program to find this more specific name. Still, if you create a couple terminal windows to your host, and type tty in each, you will see that each shell is connected to a different pseudo-terminal device. Still, each shell - and program run from the shell - can by default also refer to its own terminal input and output device as /dev/tty... it's a convenient context-sensitive name. The command...
cp /etc/passwd /dev/pts/6
...where you replace 6 with whatever your tty program really reported (e.g. 11 in my case), does the same thing as...
cp /etc/passwd /dev/tty
...it just reads the contents of the file /etc/passwd and writes them out on your screen. Now, the problem is that /etc/password looks like a lot of unintelligible junk to the average person - it's no wonder you couldn't make sense of what was happening. Try this instead...
echo "i said hello" > /tmp/hello.file
cp /tmp/hello.file /dev/tty
...and you'll see how to direct some specific, recognisable content into a new file (in this case putting it in the tmp "temporary" directory (the file will disappear when you reboot your PC), then copying that file content back to your screen.
(If you have logged on in two terminal windows, you can even go into one shell and copy the file to the /dev/pts/NN device reported by the other shell, effectively sending a message to the other window. You can even bypass the file and echo 'boo' > /dev/tty/NN. You'll only have permissions to do this if the same userid is logged into both windows.)