Hello.
I had a peculiar experience with a password (forgot it). It is the
password for an AES-encrypted partition on my HDD. I am using the loop
device and the international kernel patch. I wrote a brute-forcer
(didn't find docs and stole a lot of code from mount and losetup).
The problem is that when I leave the brute-forcer working for a longer
time (about 5 seconds on my 750 MHz Duron) when I press Ctrl-C (the
brute-forcer catches the signal and tries to save the session) the
kernel seems to deadlock. It is most probably the loop device driver.
There are about 3304 proceses with sequential PIDs and names of
"[loop7 <defunct>]", and are all zombies. If I try to start an app. as
root I get something like "fork: resource temporarily unavailable", or
"INIT: cannot fork; retrying...". Also, I can't `losetup /dev/loop7`,
since it pauses, issuing nothing. As a normal user I seem to be able to
work as usual. After a short period of time `init` seems to start
functioning and switch the run-level. The brute-forcer works as follows:
1. Generate billions of passwords.
For each of them:
1. Setup a loop device.
2. Read the block after the 1024-th byte and check it
for Ext2/Ext3's magic ID.
If the ID matches:
1. Print the password.
3. Deconfigure the loop device.
The brute-forcer works fine for short periods of time.
I've tried this on kernels 2.4.15 and 2.4.17, it's all the same
(although the 2.4.17 Changelog says about a number of bug-fixes in the
loop-back driver).
I was wondering if you could tell me about any known or unknown problems
with the kernel crypto, or help me realise my stupidity.
Comment: Sorry if this is too off-topic, I could post it to the Linux
kernel mailing list if you prefer.
--
Pav
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
