I am receiving the following error message when I try to read a Vensim model file (.mdl) using Python's PySD package.
My code is:
import pysd
import os
os.chdir('path/to/model_file')
model = pysd.read_vensim('my_model.mdl')
The Error I receive is:
Traceback (most recent call last):
Python Shell, prompt 13, line 1
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pysd/pysd.py", line 53, in read_vensim
py_model_file = translate_vensim(mdl_file)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pysd/vensim2py.py", line 673, in translate_vensim
entry.update(get_equation_components(entry['eqn']))
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pysd/vensim2py.py", line 251, in get_equation_components
tree = parser.parse(equation_str)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/parsimonious/grammar.py", line 123, in parse
return self.default_rule.parse(text, pos=pos)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/parsimonious/expressions.py", line 110, in parse
node = self.match(text, pos=pos)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/parsimonious/expressions.py", line 127, in match
raise error
parsimonious.exceptions.ParseError: Rule 'subscriptlist' didn't match at '' (line 1, column 21).
I have searched for this particular error and I cannot find much information on the failed matching rule for 'subscriptlist'.
I appreciate any insight. Thank you.
Good news is that there is nothing wrong with your code. =) (Although you can also just include the path to the file in the .read_vensim call, if you don't want to make the dir change).
That being the case, there are a few possibilities that would cause this issue. One is if the model file is created with a sufficiently old version of Vensim, the syntax may be different from what the current parser is designed for. One way to get around this is to update Vensim and reload the model file there - Vensim will update to the current syntax.
If you are already using a recent version of Vensim (the parser was developed using syntax of Vensim 6.3E) then the parsing error may be due to a feature that isn't yet included. There are still some outstanding issues with subscripts, which you can read about here and here).
If you aren't using subscripts, you may have found a bug in the parser. If so, best course is to create a report in the github issue tracker for the project. The stack trace you posted says that the error is happening in the first line of the file, and that the error has to do with how the right hand side of the equation is being parsed. You might include the first few lines in your bug report to help me recreate the issue. I'll add a case to our growing test suite and then we can make sure it isn't a problem going forwards.
Related
C:\Users\sanji\PycharmProjects\pythonProject2\venv\Scripts\python.exe C:/Users/sanji/PycharmProjects/pythonProject2/file.py
Traceback (most recent call last):
File "C:\Users\sanji\PycharmProjects\pythonProject2\file.py", line 1, in
import tkinter
File "C:\Users\sanji\AppData\Local\Programs\Python\Python39\lib\tkinter\__init__.py", line 1769
if self._name in self.master.children:
^
SyntaxError: invalid syntax
Process finished with exit code 1
In the __init__.py file for Tkinter, versions 3.9.2 through 3.9.5 inclusive have that statement appearing only on lines 2556 and 2581. See here, for example.
In the 3.9 variants before that, it's on various similar lines, around 2552 and 2577 give or take a couple of lines for small file changes.
It has never been anywhere near line 1769 in any of the 3.9 releases (including the release candidates).
So, given it's complaining about the file in the path containing ...Python\Python39\lib\..., I don't think we need to look at any other versions. I would say it's a safe bet that the file has become corrupted somehow.
You should check that file for validity and, if there's something wrong with it (probable), you may need to re-install Python to fix it. We can probably only speculate as to how it became corrupted (if indeed it did).
Maybe someone accidentally edited it or maybe you have a problematic disk. It's hard to say without seeing the entire file (or at least some twenty lines around the one the error's reported on).
Abstract:
I am analysing a pcap file, with live malware (for educational purposes), and using Wireshark - I managed to extract few objects from the HTTP stream and some executables.
During my Analysis, I found instances hinting Fiestka Exploit Kit used.
Having Googled a ton, I came across a GitHub Rep: https://github.com/0x3a/tools/blob/master/fiesta-payload-decrypter.py
What am I trying to achieve?
I am trying to run the python fiesta-payload-decrypter.py against the malicious executable (extracted from the pcap).
What have I done so far?
I've copied the code onto a plain text and saved it as malwaredecoder.py. - This script is saved in the same Folder (/Download/Investigation/) as the malware.exe that I want to run it against.
What's the Problem?
Traceback (most recent call last):
File "malwaredecoder.py", line 51, in <module>
sys.exit(DecryptFiestaPyload(sys.argv[1], sys.argv[2]))
File "malwaredecoder.py", line 27, in DecryptFiestaPyload
fdata = open(inputfile, "rb").read()
IOError: [Errno 2] No such file or directory: '-'
I am running this python script in Kali Linux, and any help would be much appreciated. Thank you.
The script expects two args... What are you passing it?
Looks like it expects the args to be files and it sees a -, (dash), as the input file.
https://github.com/0x3a/tools/blob/master/fiesta-payload-decrypter.py#L44 Here it looks like the first arg is the input file and second is the output file.
Try running it like this:
python malewaredecoder.py /Download/Investigation/fileImInvestigating.pcap /Download/Investigation/out.pcap
All that said, good luck, that script looks pretty old and was last modified in 2015.
When i run setup.py as a script i have no issues reading a parameter file.
When i build with pyinstaller and run the same script as a .exe i receive the below error.
>setup.exe
Traceback (most recent call last):
File "setup.py", line 106, in <module>
param_file_info = paramsfx.extract_param_file_info(param_text)
File "app\paramsfx.py", line 64, in extract_param_file_info
s_n = re.search(rc_n, param_file_text)
File "c:\users\xxxxxx\appdata\local\programs\python\python37-32\lib\re.py", line 183, in search
return _compile(pattern, flags).search(string)
TypeError: cannot use a string pattern on a bytes-like object
[21776] Failed to execute script setup
i have read up on other posts how to resolve this error however before changing the code (that is working fine as a script) i wanted to see if anyone had any thoughts as to why it read the parameter differently as a .exe.
Just from looking at this output and not the code I noticed this:
"TypeError: cannot use a string pattern on a bytes-like object"
If this is true, I would recommend doing some python type conversion. Here is a link to help you out
https://www.w3schools.com/python/trypython.asp?filename=demo_numbers_convert
Because I don't know how your code is structured, choosing which form of conversion you choose may affect your results so please be careful with that.
I hope my explanation could have provided some use to you.
I'm currently trying to convert the .binaryproto file here to a usable numpy array. I'm running everything in my python terminal and following some of the guides as given here.
I can make it as far as seen below:
import caffe
blob = caffe.proto.caffe_pb2.BlobProto()
data = open('ucf101_train_mean.binaryproto','rb').read()
blob.ParseFromString(data)
At which point I get the error:
Traceback (most recent call last)L
File "<stdin>", line 1, in <module>
google.protobuf.message.DecodeError: Error parsing message
I've cleared and reinstalled caffe thinking it was an installation problem and it hasn't helped. I printed the data string and checked the length and both seem appropriate.
Or, as an alternative solution - is there another way I could potentially load the values of the .binaryproto file to get a usable mean? Thank you!
>>> import gdata.books.service
>>> service = gdata.books.service.BookService()
>>> results = service.search_by_keyword(isbn='0434003484')
Traceback (most recent call last):
File "<pyshell#4>", line 1, in <module>
results = service.search_by_keyword(isbn='0434003484')
... snip ...
File "C:\Python26\lib\site-packages\atom\__init__.py", line 127, in CreateClassFromXMLString
tree = ElementTree.fromstring(xml_string)
File "<string>", line 85, in XML
SyntaxError: syntax error: line 1, column 0
This is a minimal example -- in particular, the book service unit tests included in the package also fail with the exact same error. I've looked at the wiki and open issue tickets on Google Code to no avail (and this seems to me more apt to be a silly error on my end rather than a problem with the library). I'm not sure how to interpret the error message. If it matters, I'm using python 2.6.5 and the latest version of gdata, namely 2.0.10.
I found I needed to disable SSL in the gdata client for it to work:
...
gd_client.ProgrammaticLogin()
gd_client.ssl = False
...
sje397's answer is the correct one; in your example above, if you do:
service.ssl = False
before running the search_by_keyword method, the result is properly returned. If you don't set SSL to be false, then because the client hasn't properly authenticated, the request is redirected to the main Google homepage (hence what Alex Martelli was seeing errors in was the HTML you get when you go to http://www.google.com ... definitely not well-formed XML).
Hacking around a bit to see the xml string, I notice it has a lowercase <!doctype html> at the start (should be uppercase DOCTYPE) which of course is making the XML parse fail -- definitely a bug in the book service which needs to be reported. As a temporary workaround you could hack the atom/__init__.xml to change line 127 to...:
tree = ElementTree.fromstring(xml_string.replace('doctype','DOCTYPE'))
but while that gets past this bug in the XML it reveals another at column 496 (I think that's in the middle of some javascript code). I guess there's something borken in bookservice in general at this point...:-(