21–30 of 68 posts
Correct me if I'm wrong, but one of the additional benefits of using a password manager such as 1Password is that it thwarts keyloggers. They may only get your master password (which shouldn't be your password on any site) but your site specific user name and password are never actually typed.
"This keylogger program can be legitimately purchased and used, ostensibly for monitoring your kids’ or employees’ browsing habits, etc. As you can imagine, PK can also be used for badness." Is this person suggesting that using a keylogger to spy on your employees/children without their knowledge is not 'badness'?!
As for employees, if it's a work computer I pretty much say anything is fair game.
Reverse engineering stuff like this can be fun. I remember trying to reverse engineer some random .exe that got emailed to me once. I disassembled it but all I found was some basic initialization code and then a jmp to an address that didn't seem to exist. However when I ran it (in a VM) with a debugger it seemed to go through all kinds of Win32 Calls. Very odd
Ah good old HIEW. It's the simplest and nicest disassembler - open a file switch to disassembly with one keypress. Move one line or one byte at a time for defeating code that jumps in the middle of instructions, edit the assembly (ok code bytes) in place with live preview what instructions you're writing. All in 130KB of code :) http://www.hiew.ru/ EDIT: I wonder why is the author using a version from 2004 though...…
To you, maybe. I have no use for it, so it's not, especially when it costs $200.
I wonder how he just happened to notice the keylogger connecting to FTP? Did he have a monitor in the background or something? Seems like that would be a good practice for doing things like this, and this guy obviously knows his stuff.
I'd say the older version that was analyzed before wasn't using unicode yet, whereas the later version was.
Very cool how you see the effects of character encodings all over the place - even where you don't expect them.
Also, if done right, the "encryption" should IMHO have been done after the file has been written in its native encoding using an input byte sequence. But seeing that the XOR key had that second 0 byte, I'd say that the encryption was done using a "string" key instead of plain bytes.
And don't get me started on the idea of using XOR as "encryption" - especially with repeated pattern like this, this can't even be reasonably called obfuscation IMHO.
It is fun to figure out how malware works.
> Well, for the dump file BPK.DAT, the XOR key partially worked, but to make it more readable I XORed it using two bytes 0xAA, 0x00 I'd say the older version that was analyzed before wasn't using unicode yet, whereas the later version was. Very cool how you see the effects of character encodings all over the place - even where you don't expect them. Also, if done right, the "encryption" should IMHO have been done aft…