List of lists code example
gerotica
all
program in memory in dos? I´ve been trying to use it unsucesfully for
quite a time....
Benjamin David Lunt
RBIL is a great resource on these kind of things.
Have a look here:
http://www.ctyme.com/intr/rb-2983.htm
Ben
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.frontiernet.net/~fys/index.htm
To reply by email, please remove the zzzzzz's
Batteries not included, some assembly required.
"gerotica" <pger...@gmail.com> wrote in message
news:d5fd9c85-6c66-4391...@c58g2000hsc.googlegroups.com...
Does anybody have a working example code using dos int 52h to know
all
program in memory in dos? I扉e been trying to use it unsucesfully for
quite a time....
Rod Pemberton
news:d5fd9c85-6c66-4391...@c58g2000hsc.googlegroups.com...
> for quite a time....
Did you mean int 21h, ax=52h?
Most of the examples I've found using int 21h, ax=52h were based on info
each respective author obtained from Andrew Schulman's "Undocumented DOS"
book. They typically use system vars or list of lists to get the current
directory structure (CDS). I haven't seen any which obtain memory
information this way. Maybe you want the memory control block (MCB)?
These were available on the 'net use int 21h, ax=52h to get the CDS:
A "ramdrive" by Davin McCall to comp.os.msdos.programmer
http://groups.google.com/group/comp.os.msdos.programmer/msg/36b34f208807076b
CDROM.C by Jim Harper
IHPFS (An HPFS Driver for DOS) by Marcus Better
RIFS (Remote Installable File System) by Kyle A. York
CPHANTOM by Thomas F. Divine
(These are filesystems or network redirectors. I can try to track them down
again if you want them... IIRC, I couldn't relocate one a while ago.)
Another good source of info besides RBIL (Ralf Brown's Interrupt List) are
old Dr. Dobbs articles on MS-DOS. You can use Yahoo to search the site for
specific DOS internal structures such as:
BPB (BIOS Parameter Block)
CDS (Current Directory Structure)
DPB (Drive Parameter Block)
LoL (List of Lists)
DTA (Dos Transient Area)
FN1 (Filename buffer)
MCB (Memory Control Block)
SFT (System File Table)
SDA (Swappable Data Area)
e.g., in Yahoo's search box:
+MCB +site:www.ddj.com
Rod Pemberton
gerotica
that I end up with "you need to use int21h/52h to get list-of-lists
and walk through the MCB chain"... Well, I tried this:
#include "dos.h"
#include "mem.h"
struct mcb
{
char flag;
unsigned owner;
unsigned length;
char junk[3];
char name[8];
};
void main(void)
{
union REGS inregs, outregs;
struct SREGS sregs;
struct mcb mcb;
unsigned char far *p, *addr;
inregs.h.al = 0x00;
inregs.h.ah = 0x52;
intdosx(&inregs, &outregs, &sregs);
p = MK_FP(_DS, _BX-2);
memcpy(&mcb, p, sizeof(mcb));
}
Sorry if this looks absurd someway, but I´ve tried A LOT of things
before that...
Watching mcb var never returns the 'M' signature I would see if the
first MCB was pointed correctly... I tried using *p, $p, p in every
situations (sorry about it, but i am desesperated already)...
What am I doing wrong?
Rugxulo
On May 4, 5:57 pm, gerotica <pgerot...@gmail.com> wrote:
>
> Everytime I try to search for "how mem.exe works" or something like
> that I end up with "you need to use int21h/52h to get list-of-lists
> and walk through the MCB chain"... Well, I tried this:
Well, the obvious answer (IMO) is to get FreeDOS' version's source and
take a look:
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/mem/
You can also browse online in SVN (although it hasn't changed
recently):
http://freedos.svn.sourceforge.net/viewvc/freedos/mem/trunk/source/mem/
Benjamin David Lunt
The second listing on the page
http://www.frontiernet.net/~fys/mcb.htm
may be what you are looking for. It is in assembly
though.
Also, the word value (16-bit value) at es:bx-2 is
the segment of the MCB, not that actual first MCB.
You need to get this value, then create a far pointer
by doing:
addr = MK_FP(_ES, _BX);
const bit16u mcb = *((bit16u *) (addr-2));
p = MK_FP(mcb, 0x0000);
Hope this helps,
Ben
"gerotica" <pger...@gmail.com> wrote in message
news:ce531c19-a396-4c1d...@25g2000hsx.googlegroups.com...
Everytime I try to search for "how mem.exe works" or something like
that I end up with "you need to use int21h/52h to get list-of-lists
and walk through the MCB chain"... Well, I tried this:
#include "dos.h"
#include "mem.h"
struct mcb
{
char flag;
unsigned owner;
unsigned length;
char junk[3];
char name[8];
};
void main(void)
{
union REGS inregs, outregs;
struct SREGS sregs;
struct mcb mcb;
unsigned char far *p, *addr;
inregs.h.al = 0x00;
inregs.h.ah = 0x52;
intdosx(&inregs, &outregs, &sregs);
p = MK_FP(_DS, _BX-2);
memcpy(&mcb, p, sizeof(mcb));
}
Sorry if this looks absurd someway, but I扉e tried A LOT of things
Rod Pemberton
Everytime I try to search for "how mem.exe works" or something like
that I end up with "you need to use int21h/52h to get list-of-lists
and walk through the MCB chain"... Well, I tried this:
<code snip>
Sorry, not feeling unmotivated to look at your code...
The following link to a Dr. Dobb's journal article comes up from Yahoo, _if_
you had entered my suggestion in the prior post... :-(
"Mapping DOS Memory Allocation" by Robert Moore
http://www.ddj.com/184408026
He has code (in C) which "walks" the MCB chain and what appears to be an
in-depth article on how MCB's work. Maybe his code or article will help
you find something.
Rod Pemberton
gerotica
>the segment of the MCB, not that actual first MCB.
I tried this, never sure if it was right... Now I know, thanks Ben.
And thanks to Rod, very useful links, I think now I can beat this... I
´ll let you all know..
gerotica
Now, if I get the address of a specific program, could I dump it to an
exe file?
Knowing the segment it starts and its size, I only need to dump it all
to a file and call it exe right?
Benjamin David Lunt
Nope.
First off, DOS doesn't place the EXE header in memory.
Second, the relocation entries are already patched.
Third, who says that the data and/or code hasn't been
modified by the app itself between the time it was
loaded, and the time you want to "dump" it to a file?
You can dump it to a file and using various tools,
namely a disassembler, to see what is going on. However,
you will not be able to dump it to a file, then load
that file into memory and expect it to run without errors.
gerotica
Actually now I need to dump a keyboard ISR installed by the
application, wich is encrypted in the exe. Shit, this is getting
harder than I thought...
Another idea I had was to run the dos app in a windows cmd.exe and
dump it with a windows disassembler.. Problem is I cant find any info
on how windows maps the dos exe
Rod Pemberton
> Hmmm....
> Now, if I get the address of a specific program, could I dump it to an
> exe file?
Uhm, how'd the program get into memory in the first place? I.e., shouldn't
you have the entire app on disk already...?
As Ben pointed out, the code in memory won't always be the same as the .exe.
But, if your OS allows access to the memory where the program is, the code
should be in the form that the application will execute. So, a raw dump of
memory will grab the executable "parts". I'd suspect that for most
circumstances (no overlays...) the compiled code routines, if unexecuted,
won't be modified at all.
Rod Pemberton
Rod Pemberton
> Actually now I need to dump a keyboard ISR installed by the
> application, wich is encrypted in the exe. Shit, this is getting
> harder than I thought...
Encrypted keyboard ISR...
Are you still working on the same app issue that you were working on in
March, and Dec. 2006? (modifying another app's memory, int 0x60, etc. - no
I looked that up, got deju vu below.)
> Another idea I had was to run the dos app in a windows cmd.exe and
> dump it with a windows disassembler.. Problem is I cant find any info
> on how windows maps the dos exe
For DOS, my first attempt would be to write a ISR which traps int 21h,
ah=4b. You could then try:
1) replacing al=00h (load) with 01h (load no execute)
if it returns to DOS then do a raw memory dump to a file
disassemble dump
2) in int 21h, ah=4b, dump memory to disk
pass al to original int21h, ah=4b routine
dump memory to disk
compare two dumps for differences, disassemble
Since dumping memory requires DOS calls to write to disk, it's possible you
might have a reentrancy problem for 2). I'm not too sure. In which case,
you might save the dumps to XMS memory and write to disk later. (deja
vu...)
Rod Pemberton
gerotica
than "can´t do it"...
I think I can´t load the program without executing it because the
decypt occurs when the program has started...
My idea is to make a tsr that respond to a hot key, then check the new
int09 (or int16h) vector and dump the memory from that point... then
I would know the entry point of the isr and disassemble it...
gerotica
/*00000000:*/ 0xBA, 0x00, 0x29, 0x09, 0xF4, 0x06, 0x70, 0x00, 0x16,
0x00, 0x96, 0x03, 0xF4, 0x06, 0x70, 0x00,
/*00000010:*/ 0xF4, 0x06, 0x70, 0x00, 0x54, 0xFF, 0x00, 0xF0, 0x08,
0x80, 0x00, 0xF0, 0x16, 0xE8, 0x00, 0xF0,
/*00000020:*/ 0xCD, 0x03, 0xF6, 0x04, 0xA4, 0x03, 0x2E, 0x31, 0x6F,
0xEF, 0x00, 0xF0, 0x6F, 0xEF, 0x00, 0xF0,
/*00000030:*/ 0x6F, 0xEF, 0x00, 0xF0, 0x6F, 0xEF, 0x00, 0xF0, 0xB7,
0x00, 0x96, 0x03, 0xF4, 0x06, 0x70, 0x00,
/*00000040:*/ 0x5E, 0x01, 0x00, 0xC0, 0x4D, 0xF8, 0x00, 0xF0, 0x41,
0xF8, 0x00, 0xF0, 0x25, 0x03, 0xF6, 0x04,
That would be the interrupt vector table, right?
Assuming it is, vector for int09 is 0x3A4:0x312E, am I right?
Assuming I am, here it is:
/*03A43120:*/ 0x02, 0x20, 0x02, 0x20, 0x04, 0xA0, 0x02, 0xA0, 0x04,
0x90, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
/*03A43130:*/ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
/*03A43140:*/ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x40, 0xFF,
0xFF, 0x00, 0x00, 0x00, 0x00, 0x54, 0x4D,
/*03A43150:*/ 0x50, 0x00, 0x2E, 0x24, 0x24, 0x24, 0x00, 0x00, 0x0D,
0x00, 0xD2, 0x01, 0xD2, 0x01, 0xD9, 0x01,
/*03A43160:*/ 0xB8, 0xDA, 0x10, 0x16, 0x01, 0x00, 0x00, 0x00, 0x00,
0x80, 0x00, 0xE6, 0x04, 0x45, 0x00, 0x96,
/*03A43170:*/ 0x03, 0x2E, 0x60, 0x2E, 0x5C, 0x53, 0x02, 0x38, 0x60,
0x0C, 0x28, 0x2E, 0x5C, 0x81, 0x06, 0x19,
/*03A43180:*/ 0x09, 0x01, 0x00, 0x74, 0x07, 0x70, 0x00, 0x1F, 0x00,
0xE5, 0x13, 0x00, 0x00, 0x00, 0x00, 0xFF,
/*03A43190:*/ 0xFF, 0xEE, 0x06, 0x70, 0x00, 0x8B, 0x03, 0xA2, 0x32,
0x21, 0x03, 0x3C, 0x00, 0x96, 0x03, 0x00,
/*03A431A0:*/ 0x00, 0x16, 0x01, 0x2C, 0x04, 0x11, 0x09, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
/*03A431B0:*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
/*03A431C0:*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
/*03A431D0:*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
/*03A431E0:*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8E,
0x04, 0x00, 0x00, 0x2E, 0x04, 0x00, 0x00,
/*03A431F0:*/ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x49, 0x00,
Doesnt look like an ISR right? Maybe 3a4h is segment value, different
from memory address....
I think i will change my profession...
msg
> No, that would be another problem not solved yet for other reasons
> than "can´t do it"...
<snip>
I have no idea to which post you are replying; when posting to
a Usenet newsgroup in reply to a previous post, please include
context at the beginning of your reply (most newsreader programs
will insert the text of the message to which you are replying,
ready for you to trim it). This is _not_ Google Groups,
where you may be seeing a thread arranged in some fashion by the
Google interface.
Michael
gerotica
Ops... Sorry about that, didnt know....
Ok, til here we have:
Dos 6.22
I need to dump a ISR from memory, cause it´s encrypted in the exe...
I use a TSR to respond to a hot key while the program I want to dump
is running... here is the result of the dump:
Benjamin David Lunt
>Ok, my TSR dumped the whole memory, and here is the start of it:
>
>/*00000000:*/ 0xBA, 0x00, 0x29, 0x09, 0xF4, 0x06, 0x70, 0x00, 0x16,
>0x00, 0x96, 0x03, 0xF4, 0x06, 0x70, 0x00,
>/*00000010:*/ 0xF4, 0x06, 0x70, 0x00, 0x54, 0xFF, 0x00, 0xF0, 0x08,
>0x80, 0x00, 0xF0, 0x16, 0xE8, 0x00, 0xF0,
>/*00000020:*/ 0xCD, 0x03, 0xF6, 0x04, 0xA4, 0x03, 0x2E, 0x31, 0x6F,
>0xEF, 0x00, 0xF0, 0x6F, 0xEF, 0x00, 0xF0,
>/*00000030:*/ 0x6F, 0xEF, 0x00, 0xF0, 0x6F, 0xEF, 0x00, 0xF0, 0xB7,
>0x00, 0x96, 0x03, 0xF4, 0x06, 0x70, 0x00,
>/*00000040:*/ 0x5E, 0x01, 0x00, 0xC0, 0x4D, 0xF8, 0x00, 0xF0, 0x41,
>0xF8, 0x00, 0xF0, 0x25, 0x03, 0xF6, 0x04,
>
>That would be the interrupt vector table, right?
Not neccassarily. The BA 00 29 told me
MOV DX,2900h
However, the remaining code after that looks bogus, so it may be
data. Also, just because the dump utility started with 00000000
doesn't mean that is the memory location. It just means the
offset from the start of the dump/file.
>Assuming it is, vector for int09 is 0x3A4:0x312E, am I right?
No, that doesn't look right. BIOS should be resident much higher
(or lower) than that.
Use debug:
-d 0000:0024
to get the value for the int 9h service. Remember it is a
word for the offset, another for the segment.
Then use the u command
-u segment:offset
Much easier than what you are doing above, yes?
gerotica
> >Ok, my TSR dumped the whole memory, and here is the start of it:
>
> >/*00000000:*/ 0xBA, 0x00, 0x29, 0x09, 0xF4, 0x06, 0x70, 0x00, 0x16,
> >0x00, 0x96, 0x03, 0xF4, 0x06, 0x70, 0x00,
> >/*00000010:*/ 0xF4, 0x06, 0x70, 0x00, 0x54, 0xFF, 0x00, 0xF0, 0x08,
> >0x80, 0x00, 0xF0, 0x16, 0xE8, 0x00, 0xF0,
> >/*00000020:*/ 0xCD, 0x03, 0xF6, 0x04, 0xA4, 0x03, 0x2E, 0x31, 0x6F,
> >0xEF, 0x00, 0xF0, 0x6F, 0xEF, 0x00, 0xF0,
> >/*00000030:*/ 0x6F, 0xEF, 0x00, 0xF0, 0x6F, 0xEF, 0x00, 0xF0, 0xB7,
> >0x00, 0x96, 0x03, 0xF4, 0x06, 0x70, 0x00,
> >/*00000040:*/ 0x5E, 0x01, 0x00, 0xC0, 0x4D, 0xF8, 0x00, 0xF0, 0x41,
> >0xF8, 0x00, 0xF0, 0x25, 0x03, 0xF6, 0x04,
>
> >That would be the interrupt vector table, right?
>
> Not neccassarily. The BA 00 29 told me
> MOV DX,2900h
> However, the remaining code after that looks bogus, so it may be
> data. Also, just because the dump utility started with 00000000
> doesn't mean that is the memory location. It just means the
> offset from the start of the dump/file.
I dumped the file starting from address 0000:0000, so I know I am at
interrupt vector table.
>
> >Assuming it is, vector for int09 is 0x3A4:0x312E, am I right?
>
> No, that doesn't look right. BIOS should be resident much higher
> (or lower) than that.
Bios should be, but the program I am dumping may have changed it.
>
> Use debug:
>
> -d 0000:0024
>
> to get the value for the int 9h service. Remember it is a
> word for the offset, another for the segment.
Humm... Offset comes first then segment?
>
> Then use the u command
>
> -u segment:offset
>
> Much easier than what you are doing above, yes?
>
> Ben
Yes, but I have to dump it while main program is running, that's why
Im using a tsr...
Sorry if a lot of info is missing here...
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Forever Young Softwarehttp://www.frontiernet.net/~fys/index.htm
Ted Davis
You *need* Undocumented DOS, 2nd. Edition (Schulman), *with* the floppy.
You could spend a few dollars now and save yourself untold fruitless
effort later.
That book and disk are worth their weight in gold to Real DOS system level
programmers. As of this morning, $8 would get you the book *and* support
Goodwill Industries. <http://tinyurl.com/654bz4>
--
T.E.D. (tda...@mst.edu)
Jim Leonard
> I need to dump a ISR from memory, cause it´s encrypted in the exe...
My favorite trick for dumping code is to run it under Desqview on a
386 or later with QEMM installed. While the program is running, you
can open a second Desqview window and type "ems dir" and get a list of
all the EMS pages in use. You'll see that each Desqview window is
using 640KB of EMS (number look familiar?) A simple "ems save xxx"
from the other window will dump all of the running window's memory
into a flat 640KB file that you can examine offline.
What exactly are you trying to achieve again? What does the encrypted
ISR do? And how do you know it's encrypted (could it merely be
compressed, in which case running UNP will uncompress the .exe)?
gerotica
It´s a keyboard ISR.. The thing is, when I disassemble it under IDA
Pro I can´t find any typical key processing routine, and I can see a
few setvectors for int09. So I guess the program is decrypting some
data to get the ISR, because the pointer to the ISR that setvect uses
doesnt look like a consistent routine. I am using Codeview to try to
find where the ISR is, but there´s some kind of protection that looks
for a debugger and freezes the program before the "decryption". I am
not familiar with the debugger detection technics used in MS-DOS so Im
stuck. I can see that the program runs in real-mode, so IDA wouldnt be
confused in the disassembly. Here is what IDA shows me:
.....
3805:02AB mov word ptr cs:loc_383F0, ax
3805:02AF mov ax, es:26h
3805:02B3 mov word ptr cs:loc_383F0+2, ax
3805:02B7 push ds
3805:02B8 mov dx, 3A4h
3805:02BB push cs
3805:02BC pop ds
3805:02BD assume ds:seg070
3805:02BD mov ax, 2509h
3805:02C0 int 21h ; DOS - SET
INTERRUPT VECTOR
3805:02C0 ; AL = interrupt
number
3805:02C0 ; DS:DX = new vector
to be used for specified interrupt
3805:02C2 pop ds
3805:02C3 assume ds:dseg
3805:02C3 retn
3805:02C3 sub_382B4 endp
Addres 070:3a4h:
seg070:03A4 push ds
seg070:03A5 push ax
seg070:03A6 mov ax, seg dseg
seg070:03A9 mov ds, ax
seg070:03AB inc word ptr ds:3D08h
seg070:03AF pop ax
seg070:03B0 pop ds
seg070:03B1 jmp dword ptr cs:loc_383F0
seg070:03B1 ;
---------------------------------------------------------------------------
seg070:03B6 db 33h, 0C0h, 39h, 6, 4Eh, 38h, 75h, 57h,
39h, 6, 8, 3Dh
seg070:03B6 db 75h, 0Fh, 8Eh, 0C0h, 26h, 0A1h, 6Ch, 4,
3Bh, 6, 68h
seg070:03B6 db 38h, 74h, 45h, 0A3h, 68h, 38h, 0FFh,
1Eh, 0EAh, 37h
seg070:03B6 db 0A9h, 80h, 0, 74h, 39h, 83h, 3Eh, 40h,
38h, 0, 74h
seg070:03B6 db 10h, 8Ah, 26h, 6Ch, 38h, 0CDh, 16h
seg070:03E9 ;
---------------------------------------------------------------------------
seg070:03E9 test ds:3842h, ax
seg070:03ED jz short loc_38443
seg070:03EF call dword ptr ds:383Eh
seg070:03F3
seg070:03F3 loc_38443: ; CODE XREF:
seg070:03ED j
seg070:03F3 cmp word ptr ds:3860h, 0
seg070:03F8 jz short loc_38466
seg070:03FA
seg070:03FA loc_3844A: ; CODE XREF:
seg070:040A j
seg070:03FA call dword ptr ds:3858h
seg070:03FE jb short loc_38466
seg070:0400 push word ptr ds:3856h
seg070:0404 call loc_3839B
seg070:0407 pop bx
seg070:0408 or ax, ax
seg070:040A jz short loc_3844A
seg070:040C sub word ptr ds:385Ch, 2
seg070:0411 mov ds:3856h, bx
seg070:0415 retf
cs:loc_383F0 points to this:
seg070:03A0 loc_383F0: ; DATA XREF:
sub_382B4+47 w
seg070:03A0 ;
sub_38314+1 r ...
seg070:03A0 mov al, ds:0A203h
seg070:03A0 ;
---------------------------------------------------------------------------
seg070:03A3 db 3
seg070:03A4 ;
---------------------------------------------------------------------------
wich is right before 070:3a4, begging of the "ISR"... Or maybe it´s
changed at runtime right? Anyway...
What am I doing wrong here???
gerotica
Yes, it changes to 0B003C4BAh
Now, JMP 0b003c4bah would be a value above the 128MB RAM. Where is it
jumping?
Dirk Wolfgang Glomp
> On 5 maio, 21:43, "Benjamin David Lunt" <zf...@frontiernet.net> wrote:
>> Use debug:
>>
>> -d 0000:0024
>>
>> to get the value for the int 9h service. Remember it is a
>> word for the offset, another for the segment.
>
> Humm... Offset comes first then segment?
Sure, the x86-core use little endian, but debug need "Segment:Offset"
to specify an adress.
To read one adress-entry of a vectortable stored in "Segment:Offset":
-d Segment:Offset l4
lowbyte offset, highbyte offset, lowbyte segment, highbyte segment
...
To diplay the fist ASCII in the first row of the textscreen:
-d b800:0 l1
ASCII, color, ...
...
http://www.armory.com/~rstevew/Public/Tutor/Debug/debug-manual.html
Dirk