| |
| |
| |
|
Page: 1 2 3
Comments:
<0> cyrix didn't run for 10 years ;)
<1> i wonders if the ***umption that "aam 16" clears AF holds true everywhere...
<1> (well, on 386+ at least, i know v20/v30 didn't support anything but "aam 10" anyway
<1> i had a nec v30... long time ago :)
<1> my first encounter with x86 actually
<1> i think i know how to fix it
<1> code will depend do be in the first 256 bytes of CS but i think i can squeeze out one or two more bytes that way too
<2> anybody know RedGhost ?
<1> (right now i'm at 41 bytes for puts, putc, putb & putw :)
<3> Hello.
<4> hi Dacicus
<4> flexo: you crazy, crazy guy
<3> There's something that's been puzzling me for a while: Linux, Windows, and DOS all (can) run on x86 CPUs, right? However, only the last one allows you hardware access through ***embly. Is that because the others are protected-mode, or some other reason?
<4> in all three, programs run directly on CPU.
<4> and your ***embler is indeed the exact same thing that comes to CPU
<4> however, all modern systems use so-called protected mode
<4> which basically means that, while your code is interfacing with the bare CPU core, it cannot execute some priviledged instructions.
<4> nor access some protected areas of memory
<5> doesn't the OS expose the system level calls to the hardware?
<4> cipher: what do you mean?
<5> and only those system calls are priviledged and therefore can touch the hardware directly
<5> ?
<4> yes. only kernel code runs in 'priviledged' mode of cpu. therefore, while all code executes directly on cpu, only kernel has absolute power.
<1> it would be leet if i find at least one opportunity to save a byte by doing a misaligned jump
<3> um, so the short answer to my question is yes?
<4> depends on what you mean by 'hardware access'.
<1> Dacicus: no, the short answer would be no
<5> well not exactly then, Dacicus, all 3 should allow access to the hardware, but since you're talking to the kernel to get access to the hardwre
<5> then it does depend on the OS? atleast that's my current interpretation.
<1> you can get pretty direct hardware access on linux with the right permissions
<5> and that's because of the kernel, right?
<4> you cannot talk directly to your hard disk's register from windows nor linux [well, at least windows NT, 9x lets you do anything you want... no comment on that]
<1> mwk: i'm rather sure you can
<5> so it's whatever the kernel exposes to you
<4> because on those OSes, user code is executing in non-priviledged part of protected mode.
<4> so it cannot do direct hardware IO
<6> heheh i hope one day im as cool as you guys
<1> mwk: yes you can ;)
<5> flexo: how, are you making system calls that are linux-specific?
<4> HOWEVER, linux has ioperm() and iopl() syscalls that make your non-priviledged mode a bit less non-priviledged, giving you access to some io ports. but that's the unusual case.
<4> cipher: yes.
<5> exactly
<3> mwk: I mean things like printing characters or changing pixel colors by writing things to the proper area of memory
<3> or, um
<0> with windows, all that is possible too.
<1> that's exactly what dosemu does for example
<4> Dacicus: it's plain impossible for user program on linux/windows.
<1> no it's not -.-
<5> mwk: not exactly :P
<3> without API calls or interrupts, I mean
<4> Dacicus: unless you are system administrator/root
<5> mwk: just inject code into a priviledged program
<3> or whatever the Linux equivalent to those is
<4> cipher: for USER program, impossible. for ADMIN program, possible.
<5> right
<1> ofcourse there is no such a thing
<4> Dacicus: basically, you first need to ask kernel to give you access to them.
<1> there is userspace and kernelspace
<1> and superuser processes still run in userspace
<4> flexo: read the manual.
<0> no injection or whatever hacks you plan to use. win NT has APIs to access almost all kernel objects.
<1> mwk: which one?
<3> What if you don't want to use APIs, but do things directly in ***embly?
<4> flexo: superuser runs in userspace. but it can ASK the kernel to do anything.
<5> mwk: that doesn't quite make sense then, because a user program might put something into an admin program
<4> Dacicus: general protection fault.
<0> Dacicus, no way.
<0> but hacking maybe
<3> But DOS does let you, right?
<4> cipher: no, it cannot. unless there's security hole.
<0> dos has no protection
<5> mwk: right
<3> Okay, that's what I wanted to know.
<4> Dacicus: dos lets you do totally everything.
<3> Thanks.
<0> np
<3> In short, DOS rules ;)
<4> ALSO, one clarification: dosbox/dosemu doesn't do ANY raw i/o.
<0> he. depends on the perspective ;)
<3> Yes, I know.
<5> Dacicus: but even more importantly, it's because DOS has no perception of a priviledged user
<1> mwk: now, that's wrong.
<4> Dacicus: i fail to see how allowing every program to screw up whole system counts as 'ruling'... but yes.
<1> mwk: you can make dosemu access the graphics adapter directly
<4> cipher: everyone is priviledged, obviously.
<5> mwk: right :P
<1> which needs the appropriate dos software and is highly unsafe, yadda yadda
<1> still it's possible
<5> mwk: if ieveryone is priviledged then the meaning of priviledged is meaningless :P
<4> flexo: that's, again, the unusual case
<3> True.
<1> so what?
<4> and 'appropriate' dos software is portable enough to not need such tricks...
<1> and about the manual: i took a look at it
<1> if i get it right the tss can allow port i/o in any ring.
<4> ... as much as 'portable' can be used about dos...
<5> by the way, is there anything in C that allows you to do something like cat << __EOF__ blah blah
<4> flexo: right. but only if you ask the kernel to enable it firsthand.
<5> and continue to consider something quoted udntil the __EOF__ is reached
<1> mwk: sure, but then you *can* directly read the hdc registers and stuff
<4> flexo: only as superuser
<1> pmode provides protection but doesn't make direct hardware access (from userspace even) impossible
<4> but yeah, you can.
<4> indeed.
<1> mwk: well, that depends on the os ofcourse
<3> So, DOS makes direct hardware access relatively trivial, while Linux and Windows makes it much harder. Is that a better way to put it?
<1> Dacicus: linux and windows abstract the hardware. dos doesn't.
<1> the point is not to make hardware access "hard" but to make it easy to write portable software
<1> dos hardly counts as an operating system anyway imho
<7> I keep a running dos box for a cad system
<3> flexo: As I have no idea what your definition of an OS is, and as I'm not very informed about the matter, I won't argue about that now.
<3> Thanks for all the info, guys.
<4> dos is a filesystem driver... and a bootloader
<1> wikipedia says:
<1> The main advantages of an operating system include:
<1> 1. Allows multiple programs to run concurrently. 2. Simplifies the programming of application software because the program does not have to manage the hardware. The operating systems manages all hardware and the interaction of software. It also gives the program a high level interface to the hardware and ways of interacting with other programs.
<1> dos does neigher :)
<7> fix the entry then
<4> it does provide filesystem.
<1> mwk: so does the bios. with 16bit "chs" filenames. ;)
<4> truish.
<4> and... uhm... dos does good as a bootloader
<4> .exe is a manageable format for a kernel, after all...
<1> think .com :)
<4> .com has 64kb limitation...
<5> oh, and I asked a question about the PE header earlier, and forgot to check back for the answer. unfortunately I can't scroll up far enough to see if anyone responded, so...
<1> kinda
<5> is it possible to change the length of the text segment by modifying the PE header?
<1> you have to do the relocation for yourself, but i believe it's completly loaded into memory, no matter how large it is
<1> (might be wrong about that one though)
<4> 15:48 < wobster> cipher, no. but if that results in conflicts with other segments, you're screwed. also, why would you want that?
<5> thanks
<5> 15:48? lol you must be 3 hours ahead of me
<5> 15:45 < mwk> 15:48 < wobster> cipher, no. but if that results in conflicts with
<5> other segments, you're screwed. also, why would you want that?
<4> flexo: there remains the small yet important issue that stack begins 64kb after start of COM.
<4> cipher: it's 21:47 here now.
<5> 6 hours!
<4> flexo: and com starts with interrupts enabled
<4> flexo: put together, it's a major screwup
<5> mwk: where are you located then, with such a time difference
<4> cipher: poland
<5> ah cool
<5> wobster: the reason I asked really was because I could imagine some circumstances where the end of a text segment leaves no space to add extra code to jmp to conveniently. and to extend the text segment in that case would seem like an easy fix.
<5> wobster: in the case of patching a file to add extra functionality
Return to
#asm
or
Go to some related
logs:
foreach $_POST
#linuxhelp
#debian
pclinux menu disappeared
Invalid field count in CSV input on line 1
tightvnc connection refused 111
#debian
#web
gnome-terminal script keep the window open
unable to copy the user's Xauthorization file
|
|