I wrote a small download script in the C++ part of my QtQuick2 app. This works just perfectly fine when I'm building the app for Mac OS 10.9.
For testing I download this file and when it's done I verify it against the given md5 check sum b3215c06647bc550406a9c8ccc378756
Only when I build the app on a windows PC the verification fails. On the second look I recognise that the size of the downloaded file differ with each downlaod, while the "size on disk" stays every time the same.
Do you have any idea what might trigger the strange behaviour in windows os?
Thanks in advance.
If it helps to solve the problem, I will show you my download script, but it's a pretty simple "read-all-write-to-file" script which runs every two seconds.
Could binary/text writing mode affects the result?
UPD: If you use QFile with QIODevice::Text it may behave differently depending on platform.
When reading, the end-of-line terminators are translated to '\n'. When writing, the end-of-line terminators are translated to the local encoding, for example '\r\n' for Win32.
Related
I am currently trying to get an executable running in memory. Because it is high likely that someone will ask later: Yes, it will be used for malicious software in order to hide it from AV. It is only for educational purposes, in specific for a school project (will be part of my graduation).
However the question concerns something else. I found a really good source at Github: https://github.com/aaaddress1/RunPE-In-Memory, which works perfectly for my uses (I already changed it for my purposes etc), except for the trojan I want to run. I tried it with several, e.g Darkcomet or Darktrack (It needs to be something old what is already well known to demonstrate how you could reuse them). I thought because Darkcomet it coded in Delphi (which outputs a native?), it would work like any other EXE-File (Like the ones provided at Github), but it just does not start. In Darkcomet there is also an option for making the malicious server file noticeable, so it is safe that I did not fail at any port-forwarding stuff.
My first intention then was to open the EXE in a text editor and look if it is even the same architecture. I can find "PE L" in both binaries, so as far as I know it is both 32bit. A thing what seemed strange to me were the two lines
"This program cannot be run in DOS mode." for the compiled runPE loader
and
"This program must be run under Win32" for the trojan executable.
Furthermore the two Binaries differ in the first chars: MZ and MZP.
After opening up more binaries and testing them, I came to the conclusion that the ones with "This program must be run under Win32" do not work.
As far as i know and also googled, there are DOS and Windows executables. But if there are only these two types, why is there a difference?
"must be run under Win32" == "cannot be run in DOS mode." in my opinion.
I also looked up those two terms , but I only get Threads about people who try to run these Windows-PEs in DOSBox or similar things.
So, my actual two quesions are:
-What is the difference between "This program must be run under Win32"(Type1) and "This program cannot be run in DOS mode."(Type2)
-Why does it not work if I want to push a (Type1)program into the Memory with the (Type2)RunPe-InMemory executable which I made from the Github repository.
What is the difference between ... (Type1) and ... (Type2)
Nothing:
A "PE" executable consists of some MS-DOS EXE file followed by a 32- or 64-bit part.
If you start the "PE" executable under MS-DOS (or any compatible operating system), DOS will ignore the 32- or 64-bit part and execute the MS-DOS EXE file at the start of the "PE" executable file.
A few programs are written in a way that the DOS EXE file at the start of the PE file is doing the same as the Windows part, so you can use the same EXE file both under DOS and Windows.
However, in most cases the DOS part only prints some error message saying that the program cannot be started under MS-DOS.
What you see here are two different MS-DOS programs at the start of the PE EXE files; one program prints the error message "This program must be run under Win32", the other one prints "This program cannot be run in DOS mode."
Furthermore the two Binaries differ in the first chars: MZ and MZP
This is also not a difference:
The third byte of MS-DOS files is one of many bytes describing the length of an MS-DOS program. Because you have different MS-DOS programs, they also have different lengths.
In one case the byte has the value 80, which is shown as "P" in a text editor.
In the other case the byte might have the value 10 (as an example), which is not shown as character in a text editor.
Why does the runPE not work with a specific type of executables?
Not having seen the trojan, I cannot answer this.
However, I have seen many trojans which do not use a correct "PE" file format.
(However, in these cases the "errors" were after the "PE L", not in the "MZ"-part.)
I have a program that extracts text from PDFs. It runs as a scheduled task on Windows Server 2008.
The library I use is ByteScout's PDF Extractor SDK, which is based on Tesseract under the covers.
Since it went live last November, the program has successfully extracted text from over 50,000 PDFs from many different sources.
It recently hung on a single PDF and subsequently on a second one, from the same source in the same visual format.
I am able to recreate the problem using a trivial 12 line program. I sent this program to the vendor but running that program in their environment works (it does not hang).
So I did some experimentation and this is where it gets strange.
The program works on my PC (Windows 7) if I RDP to it, but not if I am directly logged in. This behavior is repeated on other Windows 7 PCs in our environment.
It works on Server 2008 if I am RDPed, but not as a scheduled task.
It works on Windows 10, whether I am RDPed or logged in directly.
If I watch the program in Process Monitor when it is stuck, I can see that it is opening and reading C:\Windows\Fonts\times.ttf over and over again.
If it was only working using RDP, I'd wonder if the cause had anything to do with failing use of graphics acceleration or some such, but given that it doesn't work as a scheduled task where none would be present either, I think that's a blind alley.
Does anyone have any suggestions where to look next?
So ByteScout have fixed the problem. To quote Eugene on the cause ...
The problem is in System.Drawing and GDI+. Sometimes it crashes on text drawing operations that are normal in PDF but causing some internal exceptions in System.Drawing. Moreover, it's behavior varies depending on display device capabilities. That is why it works in RDP session and crashes on a desktop.
We are trying various workarounds on these crashes, attempting to fall back to alternate text drawing ways. The hanging is related to these fallbacks.
I haven't found any answer or clarification on this subject in the internet.
I have a very old program (over a decade old) for windows (portable executable exe). It displays data in my language (hebrew) and uses cp1255 encoding (old, today is obsolete due to UTF-8). now, the thing is - it only displays data on specific types of computers, so long I've only been able to run it on:
x32 bit windows 7
My question is whether I can get it to work on x64 bit windows 7 encoding. On the x64, the program actually launches, but it displays a whole lot of question marks and jibrish instead of hebrew. I conclude this is due to the encoding.
Sidenote: The program loads info to display from unidentified files (their extensions are fabricated and I have tried to recover and types but so long not very successful). They too, have data in hebrew using the old CP1255 encoding and also has some machine code in it (opened it with a notepad, weird symbols along with text)
I've come up with 2 possible solutions for now:
Either somehow make the program support UTF-8, translate the exe to UTF-8 (probably requires special programs or reverse engineering)
OR
make my OS support the old encoding (cp1255 / windows-1255)
I haven't been able to execute either of them.
If you have any more solutions to tackle this problem or know how to solve it with one of the possible solutions, I'd be glad!
-yuval.
Edit: By the way - I have the language installed. I am using hebrew as one of the keyboard languages and I surf the web with it.
You may have already gone down this path, but have you given a try to running in compatibility mode on your x64 machine? Right click on the executable or shortcut, open properties, and go to the compatibility tab. There is a troubleshooter there that could help.
Well, I suddenly missed GW-Basic very much, so I want to install one in my new Ubuntu box. I have a long time not programmed for GW-Basic, so I don't know if there comes new releases. I copied GWBASIC.EXE from my old DOS 3.3 box, but it seems not start using Wine. I guess it's 16-bit so Wine will not support it.
Is there something like 286 emulator? Or should I have to run some expensive VM like Vmware? Oh no.
DOSbox works for running gwbasic, and many old dos programs.
To install it: sudo apt-get install dosbox
To run it: dosbox gwbasic.exe
Caveats: DOSbox emulates the CPU, so it runs apps slower than on Wine or as a native app. However, anything that originally ran on a 486 should run fine with DOSbox.
Speaking of gwbasic, by default it saves the source in a binary format. You can save in a text format with the a (ascii) switch, like this:
save "filename",a
As far as a basic interpreter that runs gwbasic code on Ubuntu, I haven't found one yet, but I am still looking.
PC-BASIC runs your GW-BASIC programs without modification and runs natively on Ubuntu (it's Python-based). Just unpack the tarball and run
pcbasic filename
i installed dosbox from synaptic. and GW basic runs perfectly. in fact i tried many dos based programs in my collection, most worked. Dos box gives perfectly the feel of old dos machine
QB64 runs natively on Linux.
REMLINE.BAS is a program to remove line numbers from Microsoft Basic Programs. It removes only those line numbers that are not the object of one of the following statements: GOSUB, RETURN, GOTO, THEN, ELSE, RESUME, RESTORE, or RUN.
GWBASIC.EXE will run only on a Windows system. You can setup a Windows VM on Ubuntu as mentioned here: http://downloadsquad.switched.com/2008/02/10/run-windows-in-a-virtual-machine-using-ubuntu-and-virtualbox/
I am trying to copy C source files from a vms alpha to a windows machine to allow easier editing of the code. (VMS editor is just a text editor and it would be nice to have syntax highlighting etc)
I can copy this across using Exceed FTP and this handles the issue of duplicate filenames with version suffix that vms has:
File.c;1
File.c;2
Flle.c;3
But when I open a file I've transferred, all the line breaks have been lost and the entire file is just one line.
Can anyone recommend a solution to this or offer any hints?
Thanks in advance
ps. I need to be able to copy the files back to vms and still maintain format.
It may be off interest by now, but in case you still wonder about "one-line" text files after FTP transfer.
The short answer: force the FTP transfer mode to ASCII (or text) in your FTP client. This will make sure that the C-files you transferring (in fac all files) are treated as text, otherwise they're assumed to be binary, so you get a byte-stream.
Long answer: There're 2 FTP transfer modes: ASCII/text and binary/image. The default is sometimes clent or server-specific.
Many clients have Auto-mode that interprets the file extension to set the proper transfer mode (.TXT,.CSV etc..)
When you access the VMS server via FTP client, too often the [Win-based] client is not VMS friendy, so it does not parse the file-list properly. Thus it gets confused by version number appended to the "usual" file-name:
filename.ext;ver ==> file.c;1
So instead of seeing .C (and assuming text), it sees .C;1 and thinks it's binary.
I use Filezilla FTP client to/from VMS and so far it does it properly (though version-support is not as I'd sometimes like).
Copying a file to and from your windows desktop every time you want to edit gets old very quickly.
You may be able to implement a much nicer alternative. There is some software under VMS that permits a VMS directory tree to be treated as a "network disk" under windows. Once you've set it up, and set up your windows to recognize the network disk, you can just open the file with a windows text editor without moving it from VMS to windows. You can also browse the directory tree, which appears like a tree of folders.
When you issue a save from your text editor, the saved copy supercedes the previous version over in VMS land. And it mediates correctly between RMS format and embedded newline format. It's a whole lot more convenient than FTP, for this purpose.
After doing a quick Google search, I think the name of the VMS software is PATHWORKS. But I'm not sure.
A few points I have on this
PATHWORKS is fairly old and (as far as I recall - I dont use it) doesnt work well with recent windows versions, such as supporting Active Directory. Within the last few years HP have ported SAMBA to VMS and this is the way to go if you want to make areas of disk visible to windows machines. Should be easyt to find on HP web site.
If you want to try the FTP/SFTP route I would try SFTP and go for VMS version of at least 8.2. TheTCPIP suite was rewritten (or reported from a Unix version) at this point.
VMS supports a number of formats for text files. As well as the complex record structure described above, there is STREAM_LF which is the same as a unix file and STREAM_CRLF
I found some interesting information about OpenVMS text file structure. That corresponds with a vague memory I have of how VMS handles text files; they're not stored as streams of bytes like Windows and Unix systems, but as a sequence of records (each record is a text line). Records can be either fixed width or variable width. Whatever reads the file is responsible for the "paper control", what we normally call newlines these days.
You might check the options in Exceed FTP to make sure that you're transferring the file in an appropriate ASCII mode. There might be special options you need to set on the FTP server to read and write the files in the appropriate mode too.
I'm no expert - let's get that out and in the open ;)
I have been having similar problems in FTPing files from OVMS Alphaserver to Win7 desktop so I can migrate to SQL.
FTP [Attachmate & WIn CLI] workled fine under WinNT.
I suspect Win7 does not like the name.ext;version format of the OVMS file.
Filezilla - doesn't work.
PuTTY - doesn't work
Window CLI FTP - doesn't work [partial file transfer; times out & truncates file].
Using Attachmate's "Reflections for the Web 2011" to emulate Vax terminal - works fine.
Think I'll have to go back to Attachmate for assistance but partially hamstrung by our [Australian Fed Govt] IT services which has the final say
Some editors, such as BBEdit on the Mac, support directly opening/saving files via FTP/SFTP/etc. (BBEdit also supports various different line endings as used on different platforms, which would help with your other problem). I expect there must be a Windows editor with similar functionality - my Windows-using colleagues all rave about something called CodeWrite (or CodeWright ?) so I guess I would take a look at something like that.