What does dosbox-pure mount when choosing a .dosz compressed file?

[weniard]

Talking about iOS, does dosbox-pure only mounts the specific dosz file?

I went into command prompt after loading a dosz file and it was the only directory in "C:\" when there were like 50 more dosz in the same directory.

1. So does dosbox-pure only mounts the specific dosz game and nothing else?
2. What are the read/write accesses for the files that are inside the dosz file? Can they read/write other files in outside of the dosz file?

For example: RetroArch\Games\DOS\game1.dosz RetroArch\Games\DOS\game2.dosz RetroArch\file.cfg

Does game1.dosz have any access to game2.dosz or file.cfg? Or can it make or modify other files?

Exclude the RetroArch\saves folder.

Bonus question, can an executable run instructions directly to the cpu if jit is disabled? Or only RA/dosbox-pure instructions can access the cpu of the iPhone?

[schellingb]

For example: RetroArch\Games\DOS\game1.dosz RetroArch\Games\DOS\game2.dosz RetroArch\file.cfg

Does game1.dosz have any access to game2.dosz or file.cfg?

It will only read from game1.dosz, it will only write to RetroArch\saves\game1.pure.zip

Bonus question, can an executable run instructions directly to the cpu if jit is disabled? Or only RA/dosbox-pure instructions can access the cpu of the iPhone?

The question is ill formed. Every app you have runs instructions on the cpu. And every website with javascript you visit runs instructions on the cpu. Jit doesn't change that. Jit also isn't available on RetroArch from the app store because Apple is scared of jail break stuff.

[weniard]

Some people use sideload to enable jit from their pc, that's why I wrote that there is no jit enabled.

So the thing is... when you run an executable using dosbox-pure, the iOS just does everything the executable tells it to? Doesn't that mean that people can hack and jailbreak the device with a custom executable?

Because apple boasts that all the app store apps are virus free, so every executable that is ran through dosbox-pure is potentially an unsupervised ios app that can do whatever it wants using the signature apple gave to RetroArch?

Does that mean that every executable on dos-box is like an unsupervised iphone app? Because from my understanding it runs code to the cpu, and no one signed or reviewed that code.

I am trying to understand how dangerous it is to use dosbox on ios. Not asking for guarantees or anything like that, I want to understand if an executable that is ran on dosbox-pure is basically an unsupervised app that can do whatever it wants on the device.

Like if game.dosz which consists of file1.exe and file2.scr, gets an instruction from file1.exe to call file2.scr, and file2.scr is performing a code that creates new files across the ios or modify other files on the system, or establish internet connection to a host.

Will the operating system blindly do what the file tells it to? I am having difficulties understanding this clearly, what is dosbox-pure/ios approach when a malicious code is being ran from a downloaded game (not asking for guarantees or anything like that).

[schellingb]

Sorry, not going to indulge you on this one again. DOSBox Pure comes with no warranty or guarantees. You use it at your own risk.

Also, a lot of the questions and statements above don't make much sense. The code of the DOSBox CPU emulation is open, feel free to read it. If you think that an emulated DOS program can somehow cause DOSBox's JIT processor to emit instructions that somehow do system calls that break all of Apple's security layers and then do nefarious things, so be it. It'd be best to not use it.

[weniard]

I don't understand much about programming on ios, only windows, so reading the code in github won't help me much. I am not familiar with swift or how ios works internally.

Viruses aside - I will put my question straight to the point - Is an executable that is ran under dosbox-pure is basically like an unsigned app? I am just trying to understand this that's it.

And thank you for creating dosbox-pure, I just wanted to understand what it can and can't do before using it that's it.

[schellingb]

Is an executable that is ran under dosbox-pure is basically like an unsigned app? I am just trying to understand this that's it.

How could it be? DOS programs are compiled for an Intel type CPU from the 90s. iOS runs on ARM CPUs.

[weniard]

Is an executable that is ran under dosbox-pure is basically like an unsigned app? I am just trying to understand this that's it.

How could it be? DOS programs are compiled for an Intel type CPU from the 90s. iOS runs on ARM CPUs.

I assume that codes that create remote connection or delete/write/read are translated too, so the core/app translates the instructions from intel-based to arm.

Old exe tells app what to do → app tells cpu to do that → ios gets impacted?

File.exe → dosbox-pure → retroarch → cpu performs code from file.exe This is what I don't understand.

I am really trying to understand, please don't be upset.

And if my game is game.zip which has file1.bin + file2.cue (cd form), will dosbox pure launch it even though it has no exe/com/scr files extracted? Liberto docs says it supports it but it also says that for the launcher to open there needs to be at least1 executable.

[schellingb]

I think you have the wrong image how CPUs work. CPUs don't have a "File open" instruction.

And if my game is game.zip which has file1.bin + file2.cue (cd form), will dosbox pure launch it even though it has no exe/com/scr files extracted?

DOSBox Pure loads all its files out of the ZIP file without extracting them. Then it mounts CD images (like a BIN/CUE pair) without extracting them. Then it can load programs in that CD image, all without extracting anything. ZIP files are just data, what a program does with it is up to the program.

[weniard]

I think you have the wrong image how CPUs work. CPUs don't have a "File open" instruction.

And if my game is game.zip which has file1.bin + file2.cue (cd form), will dosbox pure launch it even though it has no exe/com/scr files extracted?

DOSBox Pure loads all its files out of the ZIP file without extracting them. Then it mounts CD images (like a BIN/CUE pair) without extracting them. Then it can load programs in that CD image, all without extracting anything. ZIP files are just data, what a program does with it is up to the program.

I know how cpus work, I got 100 in assembly in university (4 years ago). I know instructions and registers, I know what cpus do and how they work. When I talked about open, load, delete, I meant for the code itself of the program, which is complied to binary. I was more referring to the code itself that is being ran, maybe I got it confused while translating it to english. What I was referring to in general is that the same code that was made for 90s dos is translated to modern arm cpu, so code is still being translated by the core. I am oversimplifying things but I do understand how cpus work, I also have to translate everything to english which is not my native language.

But anyway thanks for the answers. I still couldn't understand if a 90s dos exe can go wild and delete/create/remote-connect and contact other files in the system that it is not supposed to, but I feel that you don't really want to answer that question.

I think that the answer to my question is a yes and no, it is not supposed to be able to do these actions even if it is trying to because only the game is mounted and it is sandboxed, unless it finds a way to escape from the emulation. This is what I feel is the answer.

Please correct me if my perception of this is wrong.

[schellingb]

But anyway thanks for the answers. I still couldn't understand if a 90s dos exe can go wild and delete/create/remote-connect and contact other files in the system that it is not supposed to, but I feel that you don't really want to answer that question.

You think answering this question is easy... It is not. I'm not even the author of the code in question. But I'm quite confident that even the author can't or won't definitely answer that question for you. And why would they. It would be a guarantee and you could sue them. It just hasn't been proven either way so far.

You should try to make a DOS program that does remote code execution in DOSBox (on any platform). DOSBox is a fairly popular program but it might not be popular enough for security researchers to attempt something like that. If it is done, DOSBox and all of its forks surely would be very interested in fixing it, if it is possible in the first place.

English is not my native language either, but English isn't what is causing friction between our communication.

[weniard]

But anyway thanks for the answers. I still couldn't understand if a 90s dos exe can go wild and delete/create/remote-connect and contact other files in the system that it is not supposed to, but I feel that you don't really want to answer that question.

You think answering this question is easy... It is not. I'm not even the author of the code in question. But I'm quite confident that even the author can't or won't definitely answer that question for you. And why would they. It would be a guarantee and you could sue them. It just hasn't been proven either way so far.

You should try to make a DOS program that does remote code execution in DOSBox (on any platform). DOSBox is a fairly popular program but it might not be popular enough for security researchers to attempt something like that. If it is done, DOSBox and all of its forks surely would be very interested in fixing it, if it is possible in the first place.

English is not my native language either, but English isn't what is causing friction between our communication.

About the cpu it did, I know how cpu works, I worked a lot with registers. The thing about the cpu got mixed up because I was trying to talk about the code of the program itself and it got scrambled with the cpu, I know that cpu doesn't deal with open/delete and all that, this is where translation and the mixing of cpu and program code got mixed together in one sentence.

And again I wasn't asking for guarantees, I asked from the side of how it is supposed to work on paper, in an ideal situation. I even explicitly said that I ask not for a guarantee or anything legally binding, I think that my question was a very good one, it is just very hard to answer, which is what I think you should have told me from the beginning.

Thank you for your dedication with dosbox-pure , I am trying to get the dos games legally, the issue is that many of these games are not available anymore for purchase legally, sadly some of the game publishers just feel fine with completely killing old dos games.

Anyway you can close the ticket unless you have something to add. Thanks for your time.

[schellingb]

I think (and that's just me guessing, not a guarantee of any sort) if you are running programs made 30 years ago (like DOS games) it probably won't cause any issues on any platform (like it accessing files outside of what you are loading, or it somehow causing system instabilities). If you are running new programs made recently from a source you don't trust, you cannot 100% be sure that it wasn't crafted explicitly to abuse a not yet publicly known security hole in DOSBox's CPU emulation to do remote code execution on the host. Again, not a guarantee of any kind. Running any kind of program (especially a virtual machine like an emulator) can potentially be a risk. If you are worried at all it's best to not use it.

[weniard]

I think (and that's just me guessing, not a guarantee of any sort) if you are running programs made 30 years ago (like DOS games) it probably won't cause any issues on any platform (like it accessing files outside of what you are loading, or it somehow causing system instabilities). If you are running new programs made recently from a source you don't trust, you cannot 100% be sure that it wasn't crafted explicitly to abuse a not yet publicly known security hole in DOSBox's CPU emulation to do remote code execution on the host. Again, not a guarantee of any kind. Running any kind of program (especially a virtual machine like an emulator) can potentially be a risk. If you are worried at all it's best to not use it.

• nothing of what told to me here is taken as a guarantee, you can quote me if you want, I will never point a blaming finger at anyone!

• I am only talking about old 90s games, I want to play my childhood game "Jones in the fast lane" and there is no legitimate way to buy it, no one sell it. So downloading it is always a risk, I will have to rethink about my choices. Worst case scenario I can buy a disc from eBay but who knows, it may be a counterfeit too and contain a virus lol.

It could have been so much easier if old dos games like Jones were available for purchase through steam or other platform, gog misses many of these games, and many of gog dos games are reported to not work under dosbox-pure by others or even flagged by anti viruses.

So it's sad, all I wanted was to play "Jones in the fast lane" on my phone lol.

Don't worry nothing of what you said has any legal-binding, I understand your worries about getting sued by a random person, and I would probably act like you in that situation, but I can only speak for myself that I take full responsibility.

Thank you for your time.

[schellingb]

Good point, if you download content (like game ROMs) for you to load into a program (like an emulator) you are at risk that the content potentially was tampered with to abuse a (known or unknown) security hole in the program.

Even if you bought a original looking CD-ROM from an online store or auction site, it could have been forged to look original and also include tampered data. Only way to be sure is to have your own physical copy from back in the day that you are sure no one besides you has ever touched it since then.

But this isn't exclusive to emulators. You can extend this to any program. Watching a video in VLC can be dangerous (for example https://blog.checkpoint.com/research/hacked-in-translation/). Visiting a website can be very dangerous, remote code execution bugs are frequently found in all web browsers. Operating systems also have frequent issues.

Using computers is difficult, but always has been. Viruses and malware have been with us ever since there are personal computers. I guess it depends on you how likely you feel that someone would find an issue in DOSBox that then no one would notice.

The emulation community frequently compares data dumps of original media via checksum. So if you were to compare your media (however acquired) with one of these verified dumps and it matches, it could give you additional security. For example Jones in the Fast Lane has documented CD-ROM media at Redump (One, Two) and documented Floppy disks at The Good Old Days.

Jones in the Fast Lane is also a favorite of mine, I hope you find ways to play it :-)