flat assembler
Message board for the users of flat assembler.

Index > Main > Keylogger without INT

Author
Thread Post new topic Reply to topic
HE-MAN



Joined: 02 Dec 2013
Posts: 5
HE-MAN 02 Dec 2013, 08:58
I'm writing a keylogger that don't work because when press a key the key is logged but the keyboard is locked. Here is part of the code of my keylogger:
Code:
 
Begin:
in al,64h
                cmp al,21h
                jnz Begin
                in al,60h
                ...
    

I think that the error is the value 21h at the input status byte. What is wrong at my code?[/code]
Post 02 Dec 2013, 08:58
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 02 Dec 2013, 09:19
HE-MAN,

Why are you spin-waiting for both input data and transmit timeout exactly (i.e. no other flags set)? test al, 1 / jz Begin seems to be more appropriate here.
Post 02 Dec 2013, 09:19
View user's profile Send private message Reply with quote
HE-MAN



Joined: 02 Dec 2013
Posts: 5
HE-MAN 02 Dec 2013, 10:23
baldr wrote:
HE-MAN,

Why are you spin-waiting for both input data and transmit timeout exactly (i.e. no other flags set)? test al, 1 / jz Begin seems to be more appropriate here.

No! I'm waiting for:
bit 0: 1
1: 0: Command buffer is empty -> time to send a command
2: 1: Selftest successful
3: 0: 60h was last accessed port
4: 1: Keyboard enabled
5: PS/2: Mouse interface = 1

With the code: test al,1; jz Begin the keyboard seems locked when I use that code in my keylogger. Why?
Post 02 Dec 2013, 10:23
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 02 Dec 2013, 11:51
HE-MAN,

Your bit combination is 00110101b == 35h (!= 21h). Moreover, RBIL's PORTS.TXT shows port 64h layout as follows:
Code:
Bitfields for keyboard controller read status (ISA, EISA):
Bit(s)  Description     (Table P0398)
 7      parity error on transmission from keyboard
 6      receive timeout
 5      transmit timeout
 4      keyboard interface inhibited by keyboard lock
        or by password server mode (IBM PS/2-286 [model bytes FCh/09h],
          "Tortuga" [model F8h/19h]) (see #00515 at INT 15/AH=C0h)
 3      =1 data written to input register is command (PORT 0064h)
        =0 data written to input register is data (PORT 0060h)
 2      system flag status: 0=power up or reset  1=selftest OK
 1      input buffer full (input 60/64 has data for 8042)
        no write access allowed until bit clears
 0      output buffer full (output 60 has data for system)
        bit is cleared after read access    
There are some differences regarding MCA & Compaq, but bits 0 and 1 invariably are the same: al & 1 means port 60h has data to be read, and al & 2 means 60h/64h should not be written.
Post 02 Dec 2013, 11:51
View user's profile Send private message Reply with quote
HE-MAN



Joined: 02 Dec 2013
Posts: 5
HE-MAN 02 Dec 2013, 12:23
baldr wrote:
HE-MAN,

Your bit combination is 00110101b == 35h (!= 21h). Moreover, RBIL's PORTS.TXT shows port 64h layout as follows:
Code:
Bitfields for keyboard controller read status (ISA, EISA):
Bit(s)  Description     (Table P0398)
 7      parity error on transmission from keyboard
 6      receive timeout
 5      transmit timeout
 4      keyboard interface inhibited by keyboard lock
        or by password server mode (IBM PS/2-286 [model bytes FCh/09h],
          "Tortuga" [model F8h/19h]) (see #00515 at INT 15/AH=C0h)
 3      =1 data written to input register is command (PORT 0064h)
        =0 data written to input register is data (PORT 0060h)
 2      system flag status: 0=power up or reset  1=selftest OK
 1      input buffer full (input 60/64 has data for 8042)
        no write access allowed until bit clears
 0      output buffer full (output 60 has data for system)
        bit is cleared after read access    
There are some differences regarding MCA & Compaq, but bits 0 and 1 invariably are the same: al & 1 means port 60h has data to be read, and al & 2 means 60h/64h should not be written.

No! My bit combination isn't that. I try with 35h but the keylogger does not log none keys. Aaarrggghhh! I am going to have a hysterical attack!
Post 02 Dec 2013, 12:23
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 02 Dec 2013, 13:04
HE-MAN,

Just made boot floppy image and loaded it in Bochs:
Code:
        mov     ax, 0xB800
        mov     ds, ax
kbwait: in      al, 0x64
        test    al, 1
        jz      kbwait
        in      al, 0x60
        mov     [0], al
        jmp     kbwait

        rb      510-$
        db      0x55, 0xAA

        db      80*2*18*512-$ dup 0    
Works as expected.
Post 02 Dec 2013, 13:04
View user's profile Send private message Reply with quote
HE-MAN



Joined: 02 Dec 2013
Posts: 5
HE-MAN 04 Dec 2013, 05:09
baldr wrote:
HE-MAN,

Just made boot floppy image and loaded it in Bochs:
Code:
        mov     ax, 0xB800
        mov     ds, ax
kbwait: in      al, 0x64
        test    al, 1
        jz      kbwait
        in      al, 0x60
        mov     [0], al
        jmp     kbwait

        rb      510-$
        db      0x55, 0xAA

        db      80*2*18*512-$ dup 0    
Works as expected.

This is NOT intendend to be loaded in bochs. This is to run in victims operating systems like windows or ubuntu(linux). The test al,1 / jz Begin don't work for my PCs. What can I do?
Post 04 Dec 2013, 05:09
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 04 Dec 2013, 08:38
HE-MAN,

I'd tried the following bootsector on a real PC:
Code:
        cli
        mov     ax, 0xB800
        mov     es, ax
        xor     di, di
        mov     ah, 0x07
kbwait: in      al, 0x64
        test    al, 1
        jz      kbwait
        in      al, 0x60
        stosw
        jmp     kbwait

        rb      510-$
        db      0x55, 0xAA    
Again, works as expected. Apart from output difference, only cli is a significant addition (spin-wait rarely outrun interrupt handler, so I had to disable IRQ1 somehow; Bochs starts it with CF==0 already).

Let me guess: you want me to find out why your code isn't working? Sorry, I'd lost my crystal ball somewhere. Without proper context even guesswork is futile. Does this code run in SMM or as a part of hypervisor?

I rarely endorse making of malware, and "to run in victims operating systems" sounds alike.

P.S. Don't quote my post if your comment doesn't refer to its content.
Post 04 Dec 2013, 08:38
View user's profile Send private message Reply with quote
HE-MAN



Joined: 02 Dec 2013
Posts: 5
HE-MAN 11 Dec 2013, 13:14
baldr wrote:
HE-MAN,

I'd tried the following bootsector on a real PC:
Code:
        cli
        mov     ax, 0xB800
        mov     es, ax
        xor     di, di
        mov     ah, 0x07
kbwait: in      al, 0x64
        test    al, 1
        jz      kbwait
        in      al, 0x60
        stosw
        jmp     kbwait

        rb      510-$
        db      0x55, 0xAA    
Again, works as expected. Apart from output difference, only cli is a significant addition (spin-wait rarely outrun interrupt handler, so I had to disable IRQ1 somehow; Bochs starts it with CF==0 already).

Let me guess: you want me to find out why your code isn't working? Sorry, I'd lost my crystal ball somewhere. Without proper context even guesswork is futile. Does this code run in SMM or as a part of hypervisor?

I rarely endorse making of malware, and "to run in victims operating systems" sounds alike.

P.S. Don't quote my post if your comment doesn't refer to its content.

My code run at hypervisor. At windows operating systems don't need to disable IRQ 1. My problem is that my code only log the keys but when release the key the key is locked. Why?
Code:
Begin:
in al,64h
test al,1
jz Begin
test al,20h
jnz Begin    
Post 11 Dec 2013, 13:14
View user's profile Send private message Reply with quote
george21



Joined: 18 Dec 2013
Posts: 1
george21 18 Dec 2013, 02:37
Sounds like a script kiddy who wants to make his 1337 keylogger truly 1337. If you're going to call your target audience victims I think your intentions are pretty clear ;]
Post 18 Dec 2013, 02:37
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.