News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Polled I/O on 32/64 bit MASM program using WIN7/8 <<-- QUESTION

Started by ROBOSPOOK, June 07, 2014, 06:43:37 AM

Previous topic - Next topic

ROBOSPOOK

Ok,
  Another question... can you do Polled I/O on a WIN7 machine?  Is this a legal operation?  For example can I read/write to  port 1F7 and extract data from a Winchester drive register  to get a drives serial number .. can this be done easily  ... does anyone have an example it if it can?   Not that I will understand all of it yet.. but I am getting there slowly..

WOW 32 bit MASM is much much different than the ol' 16 bit stuff..

Peace Long Life

Robo

dedndave

as far as i know, a kernel mode driver is required to perform direct I/O
since Vista, kernel mode drivers should be signed drivers
this requires WHQL certification

http://msdn.microsoft.com/en-us/library/windows/hardware/ff553979%28v=vs.85%29.aspx

now, for the work-arounds

there might be other ways to get to ring 0 (without a kernel mode driver)
this is something that other forum members may answer better than me
but, generally, this topic is not allowed in the forum because it may have malicious uses

another possibility is to have the user ok the installation of an un-signed driver

finally, what you might be able to do, is to find a third-party driver that is WHQL certified

dedndave

before you go to all that trouble, verify you need to perform direct I/O
drive hardware has changed signifigantly since Vista was released
i.e., most drives are SATA nowdays - reading that port may be a thing of the past

ROBOSPOOK

Well the SATA argument is very valid what I had in mind was the old IDE and EIDE drives of olden days.... Many moons ago I wrote an app that allows one to retrieve much information about the drive capabilities like, serial, number or cylinders & sectors etc. Of course one could also make the case that one could also do some dastardly things like low level format a drive but then that presupposes you know the vendor unique command to get to that level but that is not a commonly known command and is not documented anywhere that I know of. 

I also know that while the SATA drives are somewhat different there is documentation that describes how to read the data in these drives in the Seagate libraries or even through the standards organization ...what is that x13 or whatever it is .

My end goal is to learn whatever I can so that I will be able to write some forensics applications that allows one to find these idiots that are writing the viruses and doing things they should not be doing

ROBO

dedndave

there is a big difference between performing I/O on your own machine,
and distributing an end-user product that does the same

for learning purposes, you can use whatever kernel mode driver you can get your hands on
i shouldn't have to tell you how much damage you can do - lol
it's actually much worse than the old days
there are certain control register values that can be set that are really hard to undo
so - be very careful

but - you mentioned seagate
well - there you go - they must have a kernel mode driver that allows them to access I/O ports
that is, if they are designed to be run under windows
if they are self-booting apps, they may not need a driver

a program that comes to mind is CPU-Z
i know they have kernel mode drivers that allow them to access the control registers
but - i don't know whether or not they perform I/O

MichaelW

Some 20 years ago I developed multiple versions of a DOS application that could send an Identify Device command to an ATA/ATAPI device and display the returned data. Some time around 2005 I experimented with a Win32 version that used WinIo to provide I/O port access. I don't have any clear memory of the results or my conclusions, but if I had been successful, I would have remembered that result. It was a "long shot" anyway, because the only version of Windows that would allow the DOS version to work correctly was Windows 98 First Edition. All other versions that I tested, from 95 to XP, silently blocked access to the command/control block registers. So I agree with Dave, you will probably need a kernel-mode driver, and I suspect that it will need to deal with much more than I/O port access.
Well Microsoft, here's another nice mess you've gotten us into.

dedndave

it sounds like the end application might well be self-booting
you can do a lot that way, because you start out in real mode - no OS to deny access
of course, it takes a lot of time to modify-assemble-boot to try changes

a CD in "El Torito" mode might be interesting to you

dedndave

haven't done it for a while, but last time i made one, i used CDBurnerXP
don't let the name mislead you - it works under win7/8, 32/64

https://cdburnerxp.se/en/home

ROBOSPOOK

well you both may be right.. a kernel mode driver is probably gonna be necessary to access ports.  With reference a self booting disk that is always an option but I had hopes of building it into an all encompassing tool.. might not happen tho.

thanks guys

ROBO

Tedd

All of this information is available without going into device drivers, or weird hacks.

DeviceIOControl can get drive geometry, drive serial number, lock/unlock, eject, etc -- you'll have to look up the correct value for dwIoControlCode for what you need (scroll down to "For lists of supported control codes, see the following topics").

And reading from the disk itself has already been covered (open the device with CreateFile, then ReadFile to read sectors).
Potato2