EnyeLKM blog

December 10th, 2006
Hello.
With the less pager, when a file is readed containing hidden text between the corresponding labels, there is an strange behaviour: when is readed for first time or when scrolling downwards, the text comes out hidden; when scrolling backwards, the text is visible.
This can be reproduced continuously doing an up and down scroll over less same execution.
The stdout of a complete strace execution (without filter options) of less reproducing this behaviour with the same README.txt of LKM and its example of hidding:

# strace less LEEME.txt

Version less: 394
Version kernel (kernel.org): 2.6.18
Greetings.
Comments:
David Reguera García
_____________________
Hello Nethox, welcome to the blog, it is a pleasure to have you around. In my opinion what should be done is to filter through offset, to do a sort of table with ranks, from the offsets were there is hidden text and when trying to read that offset putting the pointer at the frontor behind the hidden text (depending were are we trying to read). So you avoid accesing to the file content, also a redirection should be done or something for when the hidden text file is saved is rewritten again with the new hidden text. Would this be viable? Would it be interesting to investigate it? Any other ideas? you decide :-). Greetings.
Greetings.
]]–>
RaiSe
__________________________
Hi.The hooked syscal of read only checks the size marks inside the buffer that read will read, in example if the program executes read(pepe, buf, 1024) the hacked_read reads those 1024 bytes, cheks if the marks are there, and if they are it deletes them, and the new buffer is what gives back to user space. So if a program is doing reads byte by byte the hidding does not work, and small size reads are being done were in one same read the marks are not read also. Greetings.
RaiSe how are you getting on with the shell through TCP? have you done something else? you can upload your releases or segments of code if you like :-).