Copy Link
Add to Bookmark
Report
Talk_64_v1.5_NT_version
CALLGATE.TXT
Run any Ring 0 code from a WIN32 application on Windows NT
-----------------------------------------------------------
Copyright (C) 1997 Prasad Dabak & Sandeep Phadke & Milind Borate
Background
----------
Callgate is a mechanism of controlled ring transfers (privilege
level transfers) on INTEL processors. There are ways to implement
callgate mechanism under Windows 3.1 and Windows 95. Refer to
MSDN articles 'Run Privileged Code from Your Windows-based Programs
Using Call Gates' by Matt Pietrek (MSJ May 1993) for Win3.1 implementation.
Refer to PHYS program in Matt Pietrek's excellent "Windows 95 System
Programming Secrets". We are providing here an equivalent mechanism
under Windows NT 3.51 and 4.0. We provide the reader with an API,
driver and a DLL to directly try out this mechanism.
This is the best known mechanism to execute privileged instructions
WITHOUT having to write a NT kernel mode device driver. You can directly
link with our general purpose DLL and execute Ring 0 code.
Implementation
--------------
There are a lot of undocumented functions in the core NT component
NTOSKRNL.EXE. Using some of these functions we have provided a
mechanism for creating callgates under Windows NT. The implementation
consists of a kernel mode device driver CALLGATE.SYS and a wrapper
DLL CALLGATE.DLL. Using the functions from CALLGATE.DLL, one can
create a callgate and execute any Ring 0 code from a WIN32 application.
The prototypes for the functions exported by CALLGATE.DLL are
given in GATE.H header file. We have provided a sample application
which uses this DLL to create callgate and get the contents of the
CPU control registers like CR0, CR2, CR3 from a WIN32 application.
It also demonstrates how direct port I/O can be done using this trick.
The sample program provided, beeps by outputting data on the sound port.
The function which is called through a callgate is written in
assembly language, since the standard 32-bit compiler does not generate
the stack frame required for such a function. The function called
through a callgate is called by a far call. Therefore the parameters
to the functions starts from ESP+8. The standard 32-bit compiler
generates the code which expects the parameters to start from
ESP+4. Also in this case, you have to make a far return, whereas
standard 32-bit compiler generates a near return instruction.
You can find the details about this in Matt Pietrek's
excellent book, "Windows 95 System Programming Secrets", Chapter 5,
page numbers 301, 302 (Cool stuff in the PHYS program).
Note that CALLGATE.SYS and CALLGATE.DLL have to be present in the
same directory as that of the application using CALLGATE.DLL, since
CALLGATE.DLL forms the complete path of the driver by getting the
current directory of the application.
The source code for CALLGATE.DLL and CALLGATE.SYS will be presented
in our forthcoming book "Undocumented Windows NT" by O'Reilly
Associates.
*****NOTE: You have to extremely cautious when writing the function
which is to be called through a callgate. A small mistake can
easily crash your NT machine. We are NOT responsible for any
data loss caused due to the use of this trick.*********
How to Contact us
-----------------
Prasad : pdabak@cyberspace.org
Sandeep : sandeep@giaspn01.vsnl.net.in
Milind : milind@cyberspace.org
README.TXT
Talk64 V1.5 - NT Version
Talk64NT is just a hack of Talk64 1.5 (Stan) and CallGate
from Prasad Dabak, Sandeep Phadke and Milind Borate.
Features
* PC to V64 comm program
* send/ backup ROM images
* interactive V64 DRAM editing
* special developer features
* automatic byte-flipping when needed
* allow sending any size file
* no NT driver installation needed (using Ring 0 code)
Installation
* Copy Talk64NT.exe, CallGate.Dll and CallGate.Sys into the same directory
Needed
* Administrator Rights
Todo
* Support ECP port
Greetings
* #N64dev, specially Nagra and Fennec
Contact
* Original by Stan [BlackBag] (stan@sbox.tu-graz.ac.at)
* CallGate Prasad (pdabak@cyberspace.org)
* - Milind (milind@cyberspace.org)
* - Sandeep (sandeep@giaspn01.vsnl.net.in)
* NT version by Hackerjack! (hkjack@hotmail.com)
TALK64.TXT
talk64 V1.5 - 1/August/1997
Talk64 is a program to send or backup Nintendo64 ROM image to/ from the
Doctor V64. It is a full replacement for the original TPC and V64IO programs
from Bung and additionally has a number of great features for developers.
Available as binary for DOS and Linux, also includes full C source.
SPECIAL FEATURES
================
Talk64 contains a few features no other PC to V64 communications program
offers. These are:
* Fully automatic padding-while-sending that allows you to transmit files
of any size, not just of those which are a multiple of 2 MBits long (see
the -l option).
* Supports sending, receiving (backup) of ROM images and the interactive
'remote-control' V64 memory editing modes all in one program.
* Argument passing to N64 programs to activate e.g. debug mode or other
options (requires ROM images specifically designed to make use of this
feature).
* Complete ANSI C source code is available and may be reused under the terms
of the GNU public license.
Other improvements over the programs from Bung:
* All error conditions are fully handled and reported using precise and
constructive error messages, transfer problems never cause the program to
hang.
* Supports both original and V64 byte-swapped images and auto-detects the
byte order for almost (?) all images.
* Available in functionally fully identical versions for DOS and Linux.
SHORT USAGE (for the reading disabled)
======================================
Sending a game: just start
talk64 gamename.x64
from your command shell. This will send the game via the first parallel port
in your PC, if you want to use the second port use 'talk64 -p2 gamename.x64',
figure yourself how to use the third one. This will work for both the DOS
and the Linux version of talk64.
Updating the V64 bios: just start
talk64 v64_verX.XXX
from your command shell. In other words, it is just like sending a game, so
all of the stuff above goes here as well.
FULL USAGE (for graduate students only)
=======================================
Talk64 has three modes of operation: (1) send (upload) mode to transmit a
ROM image from the PC to the Doctor, (2) receive (download) mode to backup a
ROM image from the Doctor to the PC, (3) and interactive mode that allows you
to inspect and modify the contents of the V64 DRAM (i.e. the memory that
appears to the N64 as cartridge ROM). One of these modes must be selected at
program start with the send mode being the default. These modes are now
described separately.
Send Mode
---------
Send mode is used to send (upload) ROM images from the PC to the Doctor V64
or to update the V64 BIOS.
Usage: talk64 [-o|-s] [-pPort] [-lLength] [-send] <File.v64> [-a Arguments]
- The only mandatory argument is the filename of the ROM image to be
transmitted. In many cases it alone will do and you will not need any of the
options.
- As you might know there are two formats for N64 ROM images in use: the
original format and the byte-swapped format the Doctor V64 uses. Talk64 can
handle both formats and also detect them automatically. In the rare case that
the detection fails, use the -o switch to specify original format or the -s
switch for the V64 byte-swapped (some call it little-endian or mid-endian)
format.
- The -pPort option can be used to specify the parallel port to be used for
sending. You only need this option when you want to override the default,
which is to use the first parallel port in your system. Either specify the
'logical' port number to use, -p1, -p2, or -p3 for your first, second, or
third parallel port, respectively. Or specify the ports hardware address,
using -p3bc, -p378, or -p278.
- Current BIOSes of the Doctor only accept files that are a multiple of
2 MBits long, it will refuse to load other files. Talk64 includes an automatic
padding-while-sending feature that makes pre-padding the ROM images on disk
unnecessary. It is activated simply by adding -l, e.g. 'talk64 -l rom.v64'.
Then talk64 will first transmit the file rom.v64, and add a number of zero
bytes to make the total length a multiple of 2 MBits. Please note that for
files shorter than about 8 MB you might have problems with the ROM checksum,
in that case use chksum64-v1.2 to recalculate the checksum. It is
recommended to use BIOS 1.33 or later with this feature, also see the BIOS
version notes below.
- Different V64 BIOS versions have different capabilities, use the -bios
option to activate the compatibilty modes for older BIOSes in talk64. Talk64
defaults to the currently most recent BIOS version, that is 1.33. To activate
the modes for older BIOSes, e.g. for 1.22 use -bios122 (always use 3 digits
for the version). The BIOS version currently only affects the length auto-pad
feature, versions up to 1.22 only accept files that are a multiple of 64 MBit
long, 1.30 - 1.32 any multiple of 2 MBit but they only run images of 10 MBit
or larger correctly, and 1.33 allows any multiple of 2 MBit.
- The -send option activates send mode, which is redundant as it is active
by default.
- You can also pass arguments to ROM images. Note that I have invented this
method myself because until now there was no convention how to pass arguments
to ROM images on the Doctor. This means that as of yet no images will support
this form of argument passing, but I hope that this method will establish
itself as standard among N64 coders using the Doc. It works by placing the
specified arguments into the 20 Byte name field in the header of the ROM
image in V64 DRAM, your image will need to get them from there.
Conventions are as follows: (1) -a is used to signify argument passing on
the talk64 command line. (2) All arguments specified after -a will be passed,
that means that -a always has to be the last option. (3) If you specify
multiple arguments, they will be separated by a single space for the N64.
(4) talk64 always sets all 20 Bytes in the name file, unused bytes will be
filled with zeros. (5) the 20th Byte will always be zero to ensure zero
termination of the string. Note that talk64 requires BIOS 1.30 or later for
argument passing, and that they will be sent after the actual image, therefore
they will NOT be displayed as the image name on the V64 onscreen TV display.
Examples:
'talk64 -l rom.v64 -a -d -t mode1' will first transmit the image rom.v64
with length auto-padding and set '-d -t mode1' as the arguments.
'talk64 -a -d -t mode1' will set the same arguments without transmitting
any file, one should already be loaded into the V64.
Receive Mode
------------
Receive mode is used to receive (backup, download) a ROM image from the
Doctor V64 to the PC. The image needs to be in V64 DRAM already when
starting talk64, press the '<<' and '>>' buttons on the Doc simultaneously
for 64 MBit backup or '<<', '>>' and the 'MENU' button for a 128 MBit backup.
Usage: talk64 [-pPort] [-o|-s] -rec <File.v64>
- You need to specify -rec to activate receive mode.
- File.v64 is the name to ROM image is to be save to.
- Usage of -p is the same as for sending.
- Use -o or -s to specify the byte order in which the image shall be saved,
the default is -s (V64 byte-swapped).
Interactive Mode
----------------
Interactive mode is the memory inspection/ modification mode introduced in
BIOS 1.30, Bung also calls it 'remote-control' function. In this mode talk64
is a replacement for the crappy and hardly usable V64IO program from Bung.
Usage: talk64 [-pPort] -int
- Specify -int to activate interactive mode.
- Usage of -p is the same as for sending.
You will then provided with a command prompt '>', there you can enter your
commands. Commands include dumping V64 DRAM memory, editing DRAM memory,
uploading/ downloading data to it from/ to files, invoking programs and the
V64, and printing information on the V64 screen. Enter 'help' at the prompt
for a short command summary, that is all you will get, I am not in the mood
to fully describe each command here.
General notes:
- The format for a command is 'commandname parameter1 parameter2 ...'.
Parameters can optionally be separated by commas ','.
- Parameters that are not specified take their default values, which is
dependent on the command executed.
- All numbers are assumed to be hex-numbers.
- As with V64IO, V64 DRAM space starts at address 0x0, V64 address space
starts at 0x80000000. For more information consult the V64IO manual.
- If you enter ' <RETURN>' as the command, the previous command will be
reused. This feature is especially useful with hdump and adump (see below).
- If the start offset for hdump and adump is not specified, they assume
the address the last dump ended at. The default length is the same as the
one used with the last dump.
- Memory edit mode: Use tab to switch been hexedit and ascii edit,
backspace to step back one nibble/ byte, return to skip to the next line,
esc to end editing. In ascii edit mode, any other key will change the
current byte; in hexedit mode 0-9 and a-f will change the current nibble,
space advances to the next byte.
The most noteworthy improvements over V64IO:
- Buffers are handled automatically, the user does not need to worry
about them.
- Automatic byte-swapping in dump modes for the V64 DRAM, so that data
appears the way it really is and strings are readable.
INSTALLING
==========
Either copy the binaries (TALK64.EXE for DOS or bin-unix/talk64.linux-binary
for Linux) to wherever-you-want-them-to-be or compile it fresh from the source
in the src directory. For DOS I used Borland C 3.1, for Linux GCC 2.7.2. For
more info check out the src directory. Linuxers also need to make sure that
the program is suid root, see the first note right below.
NOTES
=====
The Linux version:
Upload64 directly accesses the parallel port hardware. This access requires
root privileges under Linux. Therefore, it is recommended to run upload64
set-user-id root. This means that for the execution of the program, the user
will gain root privileges (in fact upload64 will drop root privileges right
after it has allocated the parallel port for use, so it does not cause any
security problems). To make upload64 suid root, do the following: (1) become
root, (2) type 'chown root talk64', (3) type 'chmod 4755 talk64'. As
another Linux note, the parallel port auto-detection cannot use BIOS
information as under DOS, but has to perform direct hardware detection. It
is extremely unlikely that this will cause problems, but in case it does
specify the physical port address at the commandline, e.g. using -p378.
Error messages of upload64:
If you get the error message 'Could not establish communication with the
Doctor V64!', that an error happened in the initialization phase of the
Doctor. You should check if (1) the Doctor is ready to receive (also try
turning it off and on again) (2) talk64 tried the correct parallel port,
use the commandline option -p if not (3) the cable is correctly connected
at both ends (4) you cable is ok, and (5) you have neither EPP nor ECP enabled
for that parallel port.
If you get the error message 'Error sending transfer header to the Doctor
V64!' or 'Timeout while transmitting data to the Doctor V64!', the
initialization phase was passed ok and the error happened later. This will
usually mean that your cable is bad (broken, too long, or whatever). Another
reason for the timeout error message could be, that you sent a file with a
length the Doctor does not accept - current BIOSes accept only files that are
a multiple of 2 MBits long. In that case, just activate the automatic padding-
while-sending option using -l as described in the usage section.
How about a GUI?
As you might have found out by now talk64 is a commandline program without
any graphical user interface. For my purposes a GUI would be pretty much
useless, that's why i haven't programmed any. However, M. Gallo wrote a
frontend for the Linux version of upload64 in Tcl/Tk that does pretty much
everything you window lovers could wish for. To my knowledge his program is
still unreleased, however, I would expect that a version adapted for talk64
will be out very soon.
STUPID TALK
===========
Talk64 V1.5 is an updated version of my Upload64 V1.0 program. Because of
the major enhancements - the size of the sourcecode has more than doubled - I
thought that a version number of just 1.1 would be inappropriate. Next,
because of the many new features that make talk64 more than a simple upload
program I also believed that the name upload64 did no longer fit and
therefore I renamed it to Talk64. So that's why the first version of Talk64
ever released has version number 1.5, which may sound like boasting, but I
believe my reasons are valid.
Greetings time: tomorrow, so no personal greets today. Still global
Hellos! to everyone on #n64dev, please don't be upset, I will personally greet
you next time you join the channel anyway.
Final words: I'm pissed, writing docs sux.
AUTHORS CONTACT ADDRESS
=======================
Send comments or whatever to stan@sbox.tu-graz.ac.at . Flames will be
joyfully ignored.
