check code signature from unix - perl

Does anyone know if there's a way to validate the signature of a Windows program under Unix? In a similar way like with signtool under Windows?
Thanks in advance!
T.

There are different signature algorithm possible, and Windows could have written their own in which case you might be out of luck.
You can use "md5" or "sum". You could validate the code in Windows and if validated, calculates it's "md5" signature and use that for Unix (and from that point, also use if for Windows if you want).
I would first investigate what kind of algorithm that windows tool uses, then you could see if the equivalent is available under Unix. If it is not MS proprietary code, a Unix equivalent likely already exists.

Related

Is there a perl OpenSSL EVP Key Derivation Function with MD5 support?

Background
Yahoo Finance recently (Nov-2022?) started encrypting their returns from queries such as: curl --silent --output - https://finance.yahoo.com/quote/t.
I found some Python code that will decode this in https://github.com/ranaroussi/yfinance/blob/main/yfinance/data.py#L49
Since Python is an Algol-like language, I was hoping it would be a quick port.
Here is where I hit a snag: https://github.com/ranaroussi/yfinance/blob/main/yfinance/data.py#L82
I was hoping for some relief from an existing perl module, such as Crypt::OpenSSL::FASTPBKDF2.
I know just enough about cryptography to hurt myself.
My question(s):
Is there a straightforward port for the Python function EVPKDF? It seems so close, except for the hashAlgorithm="md5" portion of EVPKDF(password, salt, keySize=32, ivSize=16, iterations=1, hashAlgorithm="md5").
The Crypt::OpenSSL::FASTPBKDF2 module doesn't seem to support md5. I know that md5 was defeated over a decade ago, but it seems to be what Yahoo is dishing out, based on the Python code.
Any thoughts are welcome.
My goal is to get the data, and I am not above using a system("openssl kdf..."); call. Not this time, anyway.

Powershell - how to replace OS Version number with other OS Version (2008R2 becomes a 2016)

I need you'r help, I searched everywhere but couldn't find anything on the subject.
ACTUAL
A programm check my server version with this command :
[System.Environment]::OSVersion.Version.Major
6
The result is 6, this is perfectly good because it's a 2008R2 server.
EXCPECTED SITUATION
[System.Environment]::OSVersion.Version.Major
10
I need this same command to give a result equivalent to 10.
The objective is to deceive the program to make it believe that the server is a windows server 2016 but it is a windows 2008R2 server.
I don't need to just replace the string or other non persistant solution.
I need to change this value with a powershell script (or other non executable script) before launch the program that checks the OSversion.
The value is stored here, it seems to be directly related to the Common Language Runtime, i think i need to modify
So I think we should be able to modify a value in the CLR, but I don't know how to do it, and even if it is possible.
enter image description here

Using Perl, is there a difference between Win32API::File::MoveFile and CORE::rename on MSWin32?

I see that Win32API::File supports MoveFile(). However, I'm not sure how CORE::rename() is implemented in such a fashion that it should matter. Could someone juxtapose the difference -- specifically for the Win32 Environment -- between
CORE::rename()
File::Copy::move()
and, Win32API::File::MoveFile()
rename is implemented in a broken fashion since forever; move too, since it uses rename.
Win32::Unicode::File exposes MoveFileW from windows.h as moveW, and apparently handles encoding in a sane fashion, whereas Win32API::File leaves that to the user AFAICS from existing example code.
Related: How do I copy a file with a UTF-8 filename to another UTF-8 filename in Perl on Windows?

Possible to use Powershell to type a command into a third-party command line program?

I have an old, third party, command line, proprietary program which I'm calling from PowerShell.
Once started, this program accepts commands typed in followed by enter (like any other program), but it's very basic. It doesn't have flags, doesn't accept piped in arguments, etc. You have to start the program, type your command, hit enter and parse the results.
Is there a way I can use PowerShell to type in a command and get the resulting output? Right now the best solution I have is to call SendKeys.Send in a background job, but I'm not sure this will work.
Is there a better way?
check out this to see if it would work for you: http://wasp.codeplex.com/
legacy programs are hard to tell, however. this works with standard windows programs.

How to discover command line options (if any) for an undocumented executable of unknown origin?

Take an undocumented executable of unknown origin. Trying /?, -h, --help from the command line yields nothing. Is it possible to discover if the executable supports any command line options by looking inside the executable? Possibly reverse engineering? What would be the best way of doing this?
I'm talking about a Windows executable, but would be interested to hear what different approaches would be needed with another OS.
In linux, step one would be run strings your_file which dumps all the strings of printable characters in the file. Any constants chars will thus be shown, including any "usage" instructions.
Next step could be to run ltrace on the file. This shows all function calls the program does. If it includes getopt (or familiar), then it is a sure sign that it is processing input parameters. In fact, you should be able to see exactly what argument the program is expecting since that is the third parameter to the getopt function.
For Windows, you can see this question about decompiling Windows executables. It should be relatively easy to at least discover the options (what they actually do is a different story).
If it's a .NET executable try using Reflector. This will convert the MSIL code into the equivalent C# code which may make it easier to understand. Unfortunately private and local variable names will be lost, as these are not stored in the MSIL but it should still be possible to follow what's going on.