IDA Pro seems to be just what I need, but I'm not forking out �200 for
an app I'm only going to use once. So... can anyone point me to a
disassembler/debugger that can handle DOS .EXE (MZ-header) files?
Bonus points if it recognises DOS extenders.

My aim is to figure out how DOS/4GW and co. load programs. I'm
guessing that the MZ code image is the loader and DPMI hooks, and the
main program is somewhere beyond that image in a massive data segment.
So, it should be possible to remove the extender and replace it with a
Windows/Linux Protected Mode interface instead. Then I can hook IN and
OUT instructions (with INT3 or the control registers) and translate
audio/joystick I/O so they operate via the OS services.


Alex Davidson

----------------------------------------------------------------------

'You are in the presence of a System Administrator. KNEEL.' --Unknown

On Wed, 6 Apr 2005 18:48:50 +0000 (UTC), Alex  <spamtrap@crayne.org>
wrote:

>IDA Pro seems to be just what I need, but I'm not forking out �200 for
>an app I'm only going to use once. So... can anyone point me to a
>disassembler/debugger that can handle DOS .EXE (MZ-header) files?
>Bonus points if it recognises DOS extenders.
>
>My aim is to figure out how DOS/4GW and co. load programs. I'm
>guessing that the MZ code image is the loader and DPMI hooks, and the
>main program is somewhere beyond that image in a massive data segment.
>So, it should be possible to remove the extender and replace it with a
>Windows/Linux Protected Mode interface instead. Then I can hook IN and
>OUT instructions (with INT3 or the control registers) and translate
>audio/joystick I/O so they operate via the OS services.

I doubt that DOS/4GW impliment the windows API.  So, removing it
simply wouldn't work.  You would have to re-write the entire app.

BTW, there is an a free disassembler whose exe is called: W32dsm87.exe
-- 
Arargh504 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

On Wed, 6 Apr 2005 20:35:03 +0000 (UTC), spamtrap@crayne.org wrote:

>On Wed, 6 Apr 2005 18:48:50 +0000 (UTC), Alex  <spamtrap@crayne.org>
>wrote:
>
>>IDA Pro seems to be just what I need, but I'm not forking out �200 for
>>an app I'm only going to use once. So... can anyone point me to a
>>disassembler/debugger that can handle DOS .EXE (MZ-header) files?
>>Bonus points if it recognises DOS extenders.
>>
>>My aim is to figure out how DOS/4GW and co. load programs. I'm
>>guessing that the MZ code image is the loader and DPMI hooks, and the
>>main program is somewhere beyond that image in a massive data segment.
>>So, it should be possible to remove the extender and replace it with a
>>Windows/Linux Protected Mode interface instead. Then I can hook IN and
>>OUT instructions (with INT3 or the control registers) and translate
>>audio/joystick I/O so they operate via the OS services.
>
>I doubt that DOS/4GW impliment the windows API.  So, removing it
>simply wouldn't work.  You would have to re-write the entire app.

Actually, I wouldn't. The API used by the extended application is
provided by Real Mode DOS and the extender itself. If I'm replacing
the extender, I can quite easily write my own functions to implement
the required API.
>
>BTW, there is an a free disassembler whose exe is called: W32dsm87.exe

Thanks, I'll check that out.


Alex Davidson

----------------------------------------------------------------------

'You are in the presence of a System Administrator. KNEEL.' --Unknown

>>I doubt that DOS/4GW impliment the windows API.  So, removing it
>>simply wouldn't work.  You would have to re-write the entire app.
>
>Actually, I wouldn't. The API used by the extended application is
>provided by Real Mode DOS and the extender itself. If I'm replacing
>the extender, 

OpenWatcom has at least one open source DOS extender, compatible with
DOS/4GW (which is the Watcom-specific version of DOS/4G, which is
why it has a postpended "W"), which you can study.  THere are tools
to remove the DOS/4GW stub and replace it with the stub loader for 
the other extender.  There are at least three 32 bit DOS extenders
usuable with OpenWatcom and thus at least basically similar to DOS/4GW
of which at least two are now open source, but one is the preferred
replacement due to implementing everything DOS/4GW implements and
a bit more.

I suspect that using one or more of these will get you most of what
you want.

On Thu, 7 Apr 2005 06:52:59 +0000 (UTC), Alex  <spamtrap@crayne.org>
wrote:

>On Wed, 6 Apr 2005 20:35:03 +0000 (UTC), spamtrap@crayne.org wrote:
>>On Wed, 6 Apr 2005 18:48:50 +0000 (UTC), Alex  <spamtrap@crayne.org>
>>wrote:
>>
<snip>
>>
>>I doubt that DOS/4GW impliment the windows API.  So, removing it
>>simply wouldn't work.  You would have to re-write the entire app.
>
>Actually, I wouldn't. The API used by the extended application is
>provided by Real Mode DOS and the extender itself. If I'm replacing
>the extender, I can quite easily write my own functions to implement
>the required API.
Yes, that is possible, I suppose.  But, if you don't have at least the
object files (to relink), I would expect it to a major undertaking.

I did something somewhat similar.  The BCET runtime was mostly a
rewrite of a runtime for PDS which used a DOS extender.  I had to
convert from the 16-bit OS/2 Family API to the 32-bit Win32 API.  But,
since I had all the source, it was just mostly coding.

>>
>>BTW, there is an a free disassembler whose exe is called: W32dsm87.exe
>
>Thanks, I'll check that out.
I actually prefer Sourcer, however that also costs money.  But, I am
not going to bother to upgrade again until Frank (the author) rewrites
it as a 32-bit app.  Or lets me do it.  I am getting tired of always
running out of memory.

-- 
Arargh504 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

On Thu, 7 Apr 2005 13:07:04 +0000 (UTC), "Kevin G. Rhoads"
<spamtrap@crayne.org> wrote:

>>>I doubt that DOS/4GW impliment the windows API.  So, removing it
>>>simply wouldn't work.  You would have to re-write the entire app.
>>
>>Actually, I wouldn't. The API used by the extended application is
>>provided by Real Mode DOS and the extender itself. If I'm replacing
>>the extender, 
>
>OpenWatcom has at least one open source DOS extender, compatible with
>DOS/4GW (which is the Watcom-specific version of DOS/4G, which is
>why it has a postpended "W"), which you can study.  THere are tools
>to remove the DOS/4GW stub and replace it with the stub loader for 
>the other extender.  There are at least three 32 bit DOS extenders
>usuable with OpenWatcom and thus at least basically similar to DOS/4GW
>of which at least two are now open source, but one is the preferred
>replacement due to implementing everything DOS/4GW implements and
>a bit more.
>
>I suspect that using one or more of these will get you most of what
>you want.

Yeah, I finally found out that these extenders aren't necessarily part
of the program they extend. So now I have an LE/LX-style EXE filespec
and the DOS32A free extender. With source code. Nice...

I'm kinda interested in the LC-style. It's supposedly impossible to
convert an LC EXE back to LE/LX, but if that were true how are they
decompressed/decrypted for execution?



Alex Davidson

----------------------------------------------------------------------

'You are in the presence of a System Administrator. KNEEL.' --Unknown

>Actually, I wouldn't. The API used by the extended application is
>provided by Real Mode DOS and the extender itself. If I'm replacing
>the extender, I can quite easily write my own functions to implement
>the required API.

Already checked out Minde ? It does similar stuff under Linux...

On Thu, 7 Apr 2005 18:25:26 +0000 (UTC), spamtrap@crayne.org wrote:

>On Thu, 7 Apr 2005 06:52:59 +0000 (UTC), Alex  <spamtrap@crayne.org>
>wrote:
>
>>On Wed, 6 Apr 2005 20:35:03 +0000 (UTC), spamtrap@crayne.org wrote:
>>>On Wed, 6 Apr 2005 18:48:50 +0000 (UTC), Alex  <spamtrap@crayne.org>
>>>wrote:
>>>
><snip>
>>>
>>>I doubt that DOS/4GW impliment the windows API.  So, removing it
>>>simply wouldn't work.  You would have to re-write the entire app.
>>
>>Actually, I wouldn't. The API used by the extended application is
>>provided by Real Mode DOS and the extender itself. If I'm replacing
>>the extender, I can quite easily write my own functions to implement
>>the required API.
>Yes, that is possible, I suppose.  But, if you don't have at least the
>object files (to relink), I would expect it to a major undertaking.

The nice thing about DOS programming is that damn near everything is
done with interrupts...

No linking required. Once the extender's removed, the resultant LE/LX
file contains all the info I need to load and relocate it. All I need
do is provide Protected Mode handlers for Ints 10h, 12h, probably 13h,
21h, 2Fh, 31h and 33h(?). Sound can be handled by installing a driver
in Ring-0 memory space (as a WinXP 'service') which waits for
connections from modified DOS apps, saving process-specific
information at the bottom of the process's Ring-0 stack segment. The
process's TSS is set up to cause an exception every time it's switched
to, which is hooked by the service so it can set up the DR registers
to break at certain port I/O without causing breakpoints in every
piece of code on the system.

A pity the DR registers aren't considered process-specific...

>I did something somewhat similar.  The BCET runtime was mostly a
>rewrite of a runtime for PDS which used a DOS extender.  I had to
>convert from the 16-bit OS/2 Family API to the 32-bit Win32 API.  But,
>since I had all the source, it was just mostly coding.

I got some extender utility binaries (and source, and docs) from the
DOS/32 Advanced project. I've already unbound System Shock's CD-ROM
executable from its extender. I'm not sure about the legalities of
this project, but I won't be distributing any modified EXEs and the
modifier app will be fully Open Source, with all the required
copyright notices.

One of the utilities I got hold of can convert LE/LX to LC format.
This routine seems to sum up the encryption method used, and I think
it's safe to say that it's not uncrackable ;-)

void putbyte(char c)
{
	*destaddr++=(c^xc);
	xc=c;
}

The thing that makes it impossible to put into a debugger is that the
relocation information is bound into the code before encryption, so it
has to be loaded at the bottom of linear memory.


Alex Davidson

----------------------------------------------------------------------

'You are in the presence of a System Administrator. KNEEL.' --Unknown

There is a free version of IDAPro floating around (legal, not warez).
While it's an older version and doesn't have all the bells and whistles
of the latest version, it's still better than anything else out there
(except the latest commercial version, of course). I've used it with
great success in the past.

Just one piece of advice, if anyone offers you an "automatic
disassembler", run like mad! Automatic disassemblers are worthless for
serious work. You need an interactive disassembler to do the job
properly.

IDAPro/Free does handle DOS .EXE files, IIRC.
Cheers,
Randy Hyde

randyhyde@earthlink.net <spamtrap@crayne.org> wrote:
>There is a free version of IDAPro floating around (legal, not warez).
>While it's an older version and doesn't have all the bells and whistles
>of the latest version, it's still better than anything else out there
>(except the latest commercial version, of course). I've used it with
>great success in the past.

>Just one piece of advice, if anyone offers you an "automatic
>disassembler", run like mad! Automatic disassemblers are worthless for
>serious work. You need an interactive disassembler to do the job
>properly.

Yes, and that is why I wrote one for the VAX 11/780 -- the team I had as
part of my senior class project did such a good job that the program was
in production use at the university a month later.  I designed the thing,
but the other coders made it happen as much as I did.  A guy named Freddie and
I wrote the tough parts.

>IDAPro/Free does handle DOS .EXE files, IIRC.
>Cheers,
>Randy Hyde

x86 asssembler is hard to write a disassembler for.  It is not even close
to being an elegant architecture.  All but direct (.com) addressing modes
are screwed up.  Having segment registers, in this day and and age, is just
fucking strange.  This is rapidly becoming a 64-bit world...let's get real!

Regards,
Mark "heading for the 256-bit passing lane" Gibson


-- 
 "The universe is quite robust in design and appears to be doing
  just fine on its own, incompetent support staff notwithstanding."
            -- the Dennis formerly known as (evil), MCFL

On Tue, 12 Apr 2005 02:06:42 +0000 (UTC), "randyhyde@earthlink.net"
<spamtrap@crayne.org> wrote:

>There is a free version of IDAPro floating around (legal, not warez).
>While it's an older version and doesn't have all the bells and whistles
>of the latest version, it's still better than anything else out there
>(except the latest commercial version, of course). I've used it with
>great success in the past.
>
>Just one piece of advice, if anyone offers you an "automatic
>disassembler", run like mad! Automatic disassemblers are worthless for
>serious work. You need an interactive disassembler to do the job
>properly.
>
>IDAPro/Free does handle DOS .EXE files, IIRC.
>Cheers,
>Randy Hyde

Yup, I found that IDA Demo. A very nice piece of software. Only thing
is, parts of DOS/4GW construct code on the stack and call it. More
than once I saw a POP bx, JMP [bx] sequence instead of a RETN, which
confuses IDA no end. I've got very little experience of text-mode GUIs
and interactive disassemblers, and ultimately it proved easier to load
the file into Turbo Debugger and copy sections of code over to a text
editor manually.
Then I found DOS32a, an Open Source replacement for DOS/4GW. It comes
with a handy unwrapper that leaves a plain LE/LX-format EXE...
This project is looking easier all the time.

BTW, I am so very glad I started using USENET. It's so much quicker to
get help with something by posting on USENET than hanging around on
Internet forums!


Alex Davidson

----------------------------------------------------------------------

'You are in the presence of a System Administrator. KNEEL.' --Unknown

Mark Gibson wrote:

>
> x86 asssembler is hard to write a disassembler for.  It is not even
close
> to being an elegant architecture.  All but direct (.com) addressing
modes
> are screwed up.

What is direct (.com) addressing mode?

> Having segment registers, in this day and and age, is just
> fucking strange.  This is rapidly becoming a 64-bit world...let's get
real!

Look, I read this newsgroup daily, as do thousands of others worldwide.
Occasionally I post here. But I don't find the need to pollute this
newsgroup by swearing. If you want to fill your posts with juvenile
obscenities, head out to one of the alt groups and do what you like
there.

Having segment registers is not strange; segmentation has several
advantages from an operating system perspective. It has nothing to do
with the number of address bits either. 

-- 
Regards
Alex McDonald

Alex McDonald <spamtrap@crayne.org> wrote:
>Mark Gibson wrote:

>>
>> x86 asssembler is hard to write a disassembler for.  It is not even
>close
>> to being an elegant architecture.  All but direct (.com) addressing
>modes
>> are screwed up.

>What is direct (.com) addressing mode?

>> Having segment registers, in this day and and age, is just
>> fucking strange.  This is rapidly becoming a 64-bit world...let's get
>real!

>Look, I read this newsgroup daily, as do thousands of others worldwide.
>Occasionally I post here. But I don't find the need to pollute this
>newsgroup by swearing. If you want to fill your posts with juvenile
>obscenities, head out to one of the alt groups and do what you like
>there.

>Having segment registers is not strange; segmentation has several
>advantages from an operating system perspective. It has nothing to do
>with the number of address bits either. 

I will fucking swear as I please.  It is cathartic.  As far as segment
registers go, there is no point (literally) these days, since a 32-bit
register can address 4Gb of memory directly.  I have 2Gb on my newest
PC, and that is way more than most PCs have.  I'd shove a pair of 2Gb sticks
into it to make 4Gb , but they are still very pricey.

Segment registers are sort of nice from an OS perspective, but things can
get complicated very quickly.  A linear address space is far better from a
low level programmer's perspective, and the end user will see a performance
increase over a segmented architecture in most cases.  I like being able
to address byte 2,123,000,005 .  Given that some of the code I write uses
data tables that measure into the gigabyte range, it only figures.

Segment registers require an extra clock cycle or two to access memory.
That is *BAD*(tm).  It is better to use a spiffy uProc and a phat (sp? :-)
bus to hit the memory location directly.  As usual, I tend to throw
hardware at the problem when I can.  A few zillion instructions down the
road, the right hardware pays off.


Regards,
Mark "how fast can I overclock this thing?" Gibson

-- 
 "The universe is quite robust in design and appears to be doing
  just fine on its own, incompetent support staff notwithstanding."
            -- the Dennis formerly known as (evil), MCFL

randyhyde@earthlink.net wrote:
> There is a free version of IDAPro floating around (legal, not warez).
> While it's an older version and doesn't have all the bells and
whistles
> of the latest version, it's still better than anything else out there
> (except the latest commercial version, of course). I've used it with
> great success in the past.

If anyone has a link to this, I'd appreciate it.  I am trying to
unravel some 20-year-old code (MS-DOS .exe) in my spare time and can't
afford the pro version.

> Just one piece of advice, if anyone offers you an "automatic
> disassembler", run like mad! Automatic disassemblers are worthless
for
> serious work. You need an interactive disassembler to do the job
> properly.

I assuming you're talking about Sourcer, which I have had mixed results
with.  For .COM and .SYS files it is the bomb -- very nice and accurate
results.  But for anything with multiple segments or embedded data, it
gets confused and spits out entire sections of "code" that are really
tables or something.  obj2asm also confuses data for code, but the
output is much more usuable because it uses the symbol information to
give procedure calls and variables their actual names.

> IDAPro/Free does handle DOS .EXE files, IIRC.

I got the impression it didn't :-(  From the web page, it states that
IDA Pro Trial only supports Windows PE executables.  Where is
IDAPro/Free?

Mark Gibson wrote:
> Alex McDonald <spamtrap@crayne.org> wrote:
> >Mark Gibson wrote:
>
> >>
> >> x86 asssembler is hard to write a disassembler for.  It is not
even
> >close
> >> to being an elegant architecture.  All but direct (.com)
addressing
> >modes
> >> are screwed up.
>
> >What is direct (.com) addressing mode?
>
> >> Having segment registers, in this day and and age, is just
> >> fucking strange.  This is rapidly becoming a 64-bit world...let's
get
> >real!
>
> >Look, I read this newsgroup daily, as do thousands of others
worldwide.
> >Occasionally I post here. But I don't find the need to pollute this
> >newsgroup by swearing. If you want to fill your posts with juvenile
> >obscenities, head out to one of the alt groups and do what you like
> >there.
>
> >Having segment registers is not strange; segmentation has several
> >advantages from an operating system perspective. It has nothing to
do
> >with the number of address bits either.
>
> I will fucking swear as I please.  It is cathartic.

It's pathetic.

> As far as segment
> registers go, there is no point (literally) these days, since a
32-bit
> register can address 4Gb of memory directly.  I have 2Gb on my newest
> PC, and that is way more than most PCs have.  I'd shove a pair of 2Gb
sticks
> into it to make 4Gb , but they are still very pricey.
>
> Segment registers are sort of nice from an OS perspective, but things
can
> get complicated very quickly.  A linear address space is far better
from a
> low level programmer's perspective, and the end user will see a
performance
> increase over a segmented architecture in most cases.  I like being
able
> to address byte 2,123,000,005 .  Given that some of the code I write
uses
> data tables that measure into the gigabyte range, it only figures.
>
> Segment registers require an extra clock cycle or two to access
memory.
> That is *BAD*(tm).  It is better to use a spiffy uProc and a phat
(sp? :-)
> bus to hit the memory location directly.  As usual, I tend to throw
> hardware at the problem when I can.  A few zillion instructions down
the
> road, the right hardware pays off.
>

In 32 bit mode, segments can be up to 4Gb; and there can be many of
them. True, there aren't many modern OSes that provide segmentation
facilties to the programmer, but they are essential in a modern OS.
Windows and Linux would not be able to function without them.

There's no 1 or 2 clock cycle overhead for segment registers, unless a
segment override is used on the instruction. Segment registers are used
all the time in Windows and Linux; every instruction refers to CS, for
instance. It's just that the segment register points at the whole 4Gb
of memory, and the DS ES and SS are equal to CS; so the entire memory
space looks flat & linear and address x is the same regardless of the
segment register used. Many of the problems of viruses running code on
the stack are a direct consequence of this scheme, hence the kludgy NX
bit that Intel and AMD have added.

Linux (which it appears you're using) sets up 4 segments; one each of
kernel text, kernel data, user text and user data. They map from 0 to
4Gb -- so why bother? Because the properties of the kernel and user
segments differ. The kernel segments run in privilege level 0
(highest), and the user areas in privilege level 3 (lowest). Only by
using segmentation registers is this possible on an x86.

So there is a point (literally).

-- 
Regards
Alex McDonald

On Tue, 12 Apr 2005 17:07:17 +0000 (UTC), "Jim Leonard"
<spamtrap@crayne.org> wrote:

[snip]
>I got the impression it didn't :-(  From the web page, it states that
>IDA Pro Trial only supports Windows PE executables.  Where is
>IDAPro/Free?

It can be found here:
http://ftp.erm.tu-cottbus.de/freeware/IDA%204.1%20Freeware/idafre41.zip

among other places. The only way to get Google to find this version is
to search for idafre41.zip, it seems.

This version runs as a console app, 80x25 text mode.



Alex Davidson

----------------------------------------------------------------------

'You are in the presence of a System Administrator. KNEEL.' --Unknown

Mark Gibson <spamtrap@crayne.org> wrote:
> I will fucking swear as I please.  It is cathartic.  

Apparently necessary.

> Segment registers require an extra clock cycle or two to

Not necessarily if in pipelined hardware.  The page
translation mechanism is much heavier.

-- Robert

>>>>>>>>
Yup, I found that IDA Demo. A very nice piece of software. Only thing
is, parts of DOS/4GW construct code on the stack and call it. More
than once I saw a POP bx, JMP [bx] sequence instead of a RETN, which
confuses IDA no end.
<<<<<<<<

It confuses a lot of disassemblers.
That's why you want an interactive disassembler. So you can go in an
manually adjust things after the first pass "automatic mode" does its
job. The nice thing about the freeware version of IDAPro is that it
saves up all your changes between runs so the next time you run IDAPro
on that file, you don't have to start all over again.


>>>>
I've got very little experience of text-mode GUIs
and interactive disassemblers, and ultimately it proved easier to load
the file into Turbo Debugger and copy sections of code over to a text
editor manually.
<<<<
Ah, you've not been around since the days of Turbo Pascal, I take it
:-)

Seriously, in other news, I'm currently using the IDAPro v4.3 freeware
version and it does PE and MS-DOS EXE files. You do, however, have to
play around with it to figure out how it all works. If you want great
docs, you'll need to buy the commercial version. Data rescue does have
a fairly good support forum, you can probably learn stuff by lurking
there.
Cheers,
Randy Hyde

On Wed, 13 Apr 2005 04:19:28 +0000 (UTC), "randyhyde@earthlink.net"
<spamtrap@crayne.org> wrote:

>>>>>>>>>
>Yup, I found that IDA Demo. A very nice piece of software. Only thing
>is, parts of DOS/4GW construct code on the stack and call it. More
>than once I saw a POP bx, JMP [bx] sequence instead of a RETN, which
>confuses IDA no end.
><<<<<<<<
>
>It confuses a lot of disassemblers.
>That's why you want an interactive disassembler. So you can go in an
>manually adjust things after the first pass "automatic mode" does its
>job. The nice thing about the freeware version of IDAPro is that it
>saves up all your changes between runs so the next time you run IDAPro
>on that file, you don't have to start all over again.

It's a very nice feature, yes.
I'm extremely impressed with IDA. It successfully disassembled a 1.3MB
3-object LE-format EXE first time, with no adjustments required.
Is there any way to locate fixups? My own LE/LX parser picked out a
fixup point which IDA appears to have left alone. I'm wondering
whether the fixup was unnecessary or whether my parser picked the
wrong address.

>>>>>
>I've got very little experience of text-mode GUIs
>and interactive disassemblers, and ultimately it proved easier to load
>the file into Turbo Debugger and copy sections of code over to a text
>editor manually.
><<<<
>Ah, you've not been around since the days of Turbo Pascal, I take it
>:-)

No. I got my first IBM PC only about ten years ago. It ran Windows/DOS
and OS/2, until I messed around with Doublespace a few weeks later and
wiped the hard disk...

Most of my early coding was done in BASIC of various forms (TRS-80,
BBC, Acorn A3000, etc). Assembly was the second language I learned,
and I didn't properly understand it until I picked up C a little
later. Most of my lower-level coding is done in Windows, but for DOS.
Much as I hate Windows I don't know if I could do a large project
without a GUI.

>Seriously, in other news, I'm currently using the IDAPro v4.3 freeware
>version and it does PE and MS-DOS EXE files. You do, however, have to
>play around with it to figure out how it all works. If you want great
>docs, you'll need to buy the commercial version. Data rescue does have
>a fairly good support forum, you can probably learn stuff by lurking
>there.
>Cheers,
>Randy Hyde

The commercial version is *very slightly* outside my budget at the
moment ;-) I've still got to find accommodation for next year, and get
a second monitor, and upgrade my server to an Opteron system...




Alex Davidson

----------------------------------------------------------------------

'You are in the presence of a System Administrator. KNEEL.' --Unknown

Alex wrote:
> >I got the impression it didn't :-(  From the web page, it states
that
> >IDA Pro Trial only supports Windows PE executables.  Where is
> >IDAPro/Free?
>
> It can be found here:
>
http://ftp.erm.tu-cottbus.de/freeware/IDA%204.1%20Freeware/idafre41.zip
>
> among other places. The only way to get Google to find this version
is
> to search for idafre41.zip, it seems.
>
> This version runs as a console app, 80x25 text mode.

Thank you!  I also found the windows 4.3 free version, although it
comes with less automatic-compiler-discover libraries.

These are amazing programs, very capable!  I think it will take me at
least a week to get proficient in using them.  Any pointers IDA
veterans can share with me?

>Sound can be handled by installing a driver
>in Ring-0 memory space (as a WinXP 'service') which waits for
>connections from modified DOS apps, saving process-specific
>information at the bottom of the process's Ring-0 stack segment. The
>process's TSS is set up to cause an exception every time it's switched
>to, which is hooked by the service so it can set up the DR registers
>to break at certain port I/O without causing breakpoints in every
>piece of code on the system.

What about modifying the port-permission bitmap instead?
Btw, if you�re interested i adding GUS sound support as well feel free
to contact me.

On Thu, 14 Apr 2005 21:04:27 +0000 (UTC), spamtrap@crayne.org (TS)
wrote:

>>Sound can be handled by installing a driver
>>in Ring-0 memory space (as a WinXP 'service') which waits for
>>connections from modified DOS apps, saving process-specific
>>information at the bottom of the process's Ring-0 stack segment. The
>>process's TSS is set up to cause an exception every time it's switched
>>to, which is hooked by the service so it can set up the DR registers
>>to break at certain port I/O without causing breakpoints in every
>>piece of code on the system.
>
>What about modifying the port-permission bitmap instead?
>Btw, if you�re interested i adding GUS sound support as well feel free
>to contact me.

Altering the I/O permissions map won't help a lot because quite a lot
of modern sound hardware doesn't have legacy emulation modes, eg. the
Realtek something-or-other built into the mainboard of my own system.
I'd need to add a new driver to the game.

It's a moot point anyway, at the moment. I think I've been redesigning
this project every time I learn something new about WinXP...
Currently, the plan is to hijack an unused GDT entry and build an LDT
for a 'DPMI Environment'. I'd basically be replacing NTVDM with a
system that ran the Protected Mode parts of a DPMI app as Windows
processes. I've been told by many, many people that modifying even
unused GDT entries will crash the kernel, and I don't doubt that, but
I'm going to play with it anyway. I might even discover something
entirely new about XP's kernel[0].

[0] This is most definitely at the far low end of the probability
scale.


Alex Davidson

----------------------------------------------------------------------

'You are in the presence of a System Administrator. KNEEL.' --Unknown

Hi there,
	I saw took your advise to use IDAPro/freeware as DOS disassemble posted 
here and thought it would be useful to me too.
	I'm trying to use it to understand the BIOS of a PCI device. I'm doing 
it by saying IDA to treat it as a binary file, to use 8086 generic 
processor type (or something that sounds like that to me now) and to 
treat code as being 16 bits. If you have time, I'd like to ask you two 
questions:
	1- Am I giving it the wright parameters?
	2- Do you know where can I find a reference on how the BIOS (of the 
machine) uses this code. i.e. whether it's read only (which I doubt 
since I can see some actual code being disassembled), entry points for 
code, etc.
	As far as I know, due to the type of card, it's kind of a mix: code and 
data, but can't figure out how to start understanding it.
	Thanks for any help you or anyone in this group can provide. Kind regards,

Marcos

randyhyde@earthlink.net wrote:
> There is a free version of IDAPro floating around (legal, not warez).
> While it's an older version and doesn't have all the bells and whistles
> of the latest version, it's still better than anything else out there
> (except the latest commercial version, of course). I've used it with
> great success in the past.
> 
> Just one piece of advice, if anyone offers you an "automatic
> disassembler", run like mad! Automatic disassemblers are worthless for
> serious work. You need an interactive disassembler to do the job
> properly.
> 
> IDAPro/Free does handle DOS .EXE files, IIRC.
> Cheers,
> Randy Hyde
> 

On Tue, 19 Apr 2005 17:18:37 +0000 (UTC), Marcos Kurban
<spamtrap@crayne.org> wrote:

>Hi there,
>	I saw took your advise to use IDAPro/freeware as DOS disassemble posted 
>here and thought it would be useful to me too.
>	I'm trying to use it to understand the BIOS of a PCI device. I'm doing 
>it by saying IDA to treat it as a binary file, to use 8086 generic 
>processor type (or something that sounds like that to me now) and to 
>treat code as being 16 bits. If you have time, I'd like to ask you two 
>questions:
>	1- Am I giving it the wright parameters?
No, you are not giving it the right parameters.  I have never heard of
a PCI device on any processor less than a 386.  So, you need to use a
generic 80386 processor type.

>	2- Do you know where can I find a reference on how the BIOS (of the 
>machine) uses this code. i.e. whether it's read only (which I doubt 
>since I can see some actual code being disassembled), entry points for 
>code, etc.
It might help to know WHAT type of PCI device.  

>	As far as I know, due to the type of card, it's kind of a mix: code and 
>data, but can't figure out how to start understanding it.
>	Thanks for any help you or anyone in this group can provide. Kind regards,

<snip>
-- 
Arargh504 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

spamtrap@crayne.org escribi�:
> On Tue, 19 Apr 2005 17:18:37 +0000 (UTC), Marcos Kurban
> <spamtrap@crayne.org> wrote:
> 
> 
>>Hi there,
>>	I saw took your advise to use IDAPro/freeware as DOS disassemble posted 
>>here and thought it would be useful to me too.
>>	I'm trying to use it to understand the BIOS of a PCI device. I'm doing 
>>it by saying IDA to treat it as a binary file, to use 8086 generic 
>>processor type (or something that sounds like that to me now) and to 
>>treat code as being 16 bits. If you have time, I'd like to ask you two 
>>questions:
>>	1- Am I giving it the wright parameters?
> 
> No, you are not giving it the right parameters.  I have never heard of
> a PCI device on any processor less than a 386.  So, you need to use a
> generic 80386 processor type.
> 
> 
>>	2- Do you know where can I find a reference on how the BIOS (of the 
>>machine) uses this code. i.e. whether it's read only (which I doubt 
>>since I can see some actual code being disassembled), entry points for 
>>code, etc.
> 
> It might help to know WHAT type of PCI device.  
> 
A vga compatible video card.
Thanks for you help. Regards,

Marcos

On Tue, 19 Apr 2005 22:11:37 +0000 (UTC), "Marcos E. Kurb�n"
<spamtrap@crayne.org> wrote:

<snip>
>> It might help to know WHAT type of PCI device.  
>> 
>A vga compatible video card.
Ahh.  Been there done that.  Years ago.  I used Sourcer (from v-com)
and the bios processor, but it was still a royal pain.

At least in the old days, the vga bios was read only.


-- 
Arargh504 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.