.COM executable

[Ycep]

Hi ppl,
Is this enough for loading .COM executables?

Code: Select all

File f;
if(OpenFile(&f, pt))goto t; //Open file at path pt
ReadFile(&f,x,f.size*512);//Read file to buffer x
if(f.flags&0x10)//Check if it is directory
{
	cerror("Could not read a directory!");
	return;
}
_asm
{
	lea edi, [x] //Get address of buffer
	call edi //Call it
}

...But I get GPF.
For now is nothing more than CLI HLT 32-bit executable.
Anybody?

[Ycep]

File contents are OK, and readed contents are OK too.

[bzt]

Not sure of what you mean. Good old DOS' .COM files are real mode executables and such limited to 64k (size of a real mode segment). As far as I can remember they have an entry point at 0 which should be loaded to CS:080h (or CS:100h?) as there's a PSP (program segment prefix) structure recording the memory allocation and also the command line that was used to invoke the .COM file.

Edit: the other thing I can think of is Digital Command Language script file, but it's very unlikely that's what you're after

[Ch4ozz]

You can rename any .exe to .com and it will run just fine on modern windows systems.
You have to specify which COM version/format exactly you meant

[Ycep]

Nah, I meant flat binary.

[iansjack]

What value do CS and DS have?

[crunch]

You shouldn't even need assembly.

Code: Select all

void* (*function) = address_of_buffer;
function();

[Sik]

Not sure of what you mean. Good old DOS' .COM files are real mode executables and such limited to 64k (size of a real mode segment). As far as I can remember they have an entry point at 0 which should be loaded to CS:080h (or CS:100h?) as there's a PSP (program segment prefix) structure recording the memory allocation and also the command line that was used to invoke the .COM file.

At 100h, because 00h~07Fh holds information put there by DOS and 080h~0FFh contains the command line arguments. But yeah they're raw real mode binaries.

You can rename any .exe to .com and it will run just fine on modern windows systems.
You have to specify which COM version/format exactly you meant

That's because Windows looks at the file to see what format it is, the extension is ignored other than to know whether it should attempt executing it or not.

[iansjack]

We seem to be ignoring the fact that the OP is probably executing code stored in a different memory location than that of the code he has loaded. No wonder the result is an exception. Crunch's solution is no safer.

[Ycep]

Address seems to be right and content seems to be right too.

It would execute invalid operation code handler if it was corrupted content or wrong address.
Everything I done is:

Code: Select all

nasm -f bin test.asm

While test.asm contains:

Code: Select all

bits 32
cli
hlt
lea ebx, [str1]
mov eax, 2
int 0x5F
cli
hlt
str1: db "This is a test.",0x00

[iansjack]

As always, use a debugger to track what is happening. The result will surprise you.

[crunch]

Are you trying to execute this in ring 3? CLI is a privileged instruction

[gerryg400]

Cli might be okay depending on the setting of the iopl bits in the flags register. However hlt is always privileged and can never be used in ring 3.

[Ycep]

I'm in ring 0.
It seems that this code work:

Code: Select all

bits 32
x:
nop
jmp x

And these two below release GPF:

Code: Select all

bits 32
cli
hlt

Code: Select all

bits 32
lea ebx, [str1]
mov eax, 2
int 0x5F ;System call
ret
str1: db "This is test.",0x00

[JAAman]

to me, that sounds like you are in fact, in ring 3... since the first one wont cause a #GP in ring3 but the later 2 both could (the first one always will, the 2nd one could depending on your IDT) -- CLI HLT will never cause #GP in ring 0, but will always cause #GP in ring 3

that is, assuming that you really are running the correct code, and not running random memory somewhere else (wrong address, or incorrectly loaded contents)