Find the answer to your Linux question:
Page 1 of 3 1 2 3 LastLast
Results 1 to 10 of 30
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Keeping out Hackers, and Killing All Viruses!


    I know, it sounds impossible, but it's not. All hackers, and all viruses take advantage of the common file structures and file names that your computer uses. If you operating system seemed alien, or always different than the next, and didn't have any common file names, or folders, they could never navigate. A program's ability to navigate automously is literally dependant on another inidividual's knowledge of the system, common folders, and common files.

    All of this can easily be fixed. First, you adopt long file names, and long folder names. Then you create a file system based upon randomly renaming all of your files. On install, everything is named correctly. So, you whole file system needs to be renamed, and a read from decryption table to present it to the user using common file and folder names. But, written to the disk is all of the encrypted file names and folders. Even the hashtable once it's created will have it's own unique name. The whole system needs a minor revision in order to use this. Any machine communications will result in a loss of direction on the part of the hacker or the author of any virus. They depend upon actually getting a program into your machine. But, if they cannot do that, they have no means.

    So, in your most basic DOS like mode, you have the file table. That file table, and the operating system needs to look at the hashtable. On install, the hashtable reads the same on both sides of the comma. Then at your X-Windows level, you will need a file interpretor to translate meaningless file names back into their originals. What will govern the file names? Well, once upon a time, I wrote a program to shuffle cards, and it removed any frequencies of repetition and produced a naturalized random. I started by drawing a random number between 1 and 100, then a second number between 1 and 10. I cut the deck at 31 cards and loaded that into my right hand array, 21 into my left hand array, and moved the cards from the right hand array into the left hand array based upon the random number between 1 and 10. The random number between 1 and 100 is used to determin how many times to shuffle the deck, and put into a loop. Instead of drawing a number between 1 and 26, or 1 in 52, I drew two numbers between 1 and 3, one for the left hand, and one for the right hand array. If you've ever physically shuffled a deck of cards, then you know that you almost never see every other card go to either the absolute left or right hand, and there are always some left over because the deck wasn't cut exactly. So, the program is written to insure the deck is never cut exactly, and the cards are shuffled imperfectly. Then I load the deck array, which would contain all of the cards before the cut, and the shuffling randomly 1, 2 or 3 cards at a time alternately from each of the two hand arrays. Once the deck has been shuffled, cards can then be drawn from the top of the deck and a natural random order is obviouse. Even randomize timer doesn't effectively eliminate the random procession of numbers from the random number generator. You can always get the same numbers at the same time of day.

    Since it would be a system of renaming files, and using a hash table that is reliably different for each machine, even if they ever get to a point where the operating system is communicating with their machine, they will have to find your hash table in memory. Therefore, you want to scan the upper memory for freespace, and randomly position it. Once, all of that is done, the program that draws characters to produce your filenames, and eliminate extensions, well, every time you generate a new file name, you still need to scan the existing named files for a match, you may need to reshuffle and draw again. But, the likelihood of actually drawing 40 characters that all match, is near zero, and like winning at solitare without cheating.

    It will take work, and some time debugging. But, testing it on a simple boot disk that isn't very large should do the job. I know it's a daunting task, and security is of the essense. So, take my advice, and I'll use Linux.

  2. #2
    Whoah, ain't that a bit of an overkill? Securing a system is way easier imho. Turn off all unnecessary services, use software and hardware firewalls, use dhcp instead of static IPs, restrict user privileges to what is really needed, manually assign ports for e.g. ssh, so that they do not use the default port but e.g. 1002 onwards, run clamav with a cronjob, install rootkit. Then follow system-hardening procedures as e.g. explained for Slackware here,, configure SELinux, keep different folders on different partitions and use good passwords like "Pe5t*3§lLkuu&" and it will be hard for anyone to break into your box.
    Windows free since 2002 | computing since 1984

  3. #3
    Look, firewalls get jacked too. At present, my current firewall is dependant on a file that is growing longer every day. My anti-virus files are watching my firewall for messages from viruses, and code that literally is a virus on my connection.

    Those viruses only work if they get onto my machine, but the firewall watches for messages from them. I wouldn't need the firewall, if the common files weren't there where the virus could look them up and as a result, install itself. If they can view your hard drive, they can uninstall your drivers for any of your hardware. As of yet, I am not aware of any viruses that contain malicious code that includes the binaries required to activate any flash ROMs, but even your BIOS is in jeopordy these days because, they can be updated. At two points, if anything is familiar to another machine it's common names, common files, and common memory alocations for critical information. Now, if I have a file viewer, and everything looks right too me, and I can read all of the common file names, but there is no discriptor/hashtable for the virus, even if it gets into memory, which is about the only place one could start, a conventional file name will stick out. Then, when you look at it, you can instruct your machine to lock out common filenames. But, that would only pertain to what is actually written to the disk as a file name. The small inclusion of the new hashtable would be exclusive to file viewing and as a rule, the machine shouldn't look any different from behind the keyboard or mouse, and all of the file names would continue to follow the present conventions. If you wrote a program, that looked through a file viewer of your own construction, then you would find those long encrypted file names.

    Idealistically, your memory would also have a map, and the order that the programs filled the memory would swap between from the lowest point in memory, to the highest, or from the highest to the lowest. That really calls for a equivalent of emm386.exe in windows that is reversable as a memory manager. You can move BIOS after the program starts, and re-allocate it. Then update all of your driver positions as you randomly place them in memory. It's like placing a stacked deck of cards that has been shuffled at either the lowest memory position working up, or the highest memory location and working down. We are used to utilizing permenant memory allocations start addresses etc. But, as for what goes into memory, per say, a 100 files, as long as they know where they are, the memory won't slow it down, or speed it up, just make it hard to crack.

    That's why I believe Linux should be Un-cracked. The anti-virus and the firewalls are soon going to slow these machines down with these large files that must be searched before information can be passed or utilized by the processor.

    The computer never needs to know or see any extension to operate or run a program. It just needs to know by some form of communications from the file system that it is a program, binary file, etc. As a programmer, you would always do the same work in conventions and standards you always did in your concerns with file formats.

    Linux Uncracked, that's what I want.

  4. $spacer_open
  5. #4
    Okay, let's assume you change all paths and names: How do you want to troubleshoot anything then? How can you expect that e.g. a Support company will give you support then? IMHO, you seem to be a bit paranoid (Aren't we all? ) and your scenario will never be implemented on a large scale for simply logical/every day work reasons. RHCE? Useless with what you propose. But the real life asks for certifications like the RHCE.
    Windows free since 2002 | computing since 1984

  6. #5
    It's not useless. Frankly, you would have to approve that read of your file name encryption through your TCP connection, so that those encrypted filenames would be passed. Once, they were done fixing your machine remotely, then you'd want the option to re-encrypt it to produce a new hash table.

    The viewer that contains a simple database using commas between the original filename, and the new random 40 character file name and a CR{carriage return} is kept there between your hard drive and screen whenever you look at your files from behind the keyboard, or mouse, at any point and time in using the operating system, or desktop. Any automated scan will never find common file names, but if you went to look during the system boot the operating system will use it to replace the encrypted file names with the decrypted ones on your screen. Frankly, you'll never see the encryption tables. They would be introduced as an option for your system boot, and then run. Then the file system would switch to the encrypted look-up table, and place the decrypted file name there for you to see during boot and any time you view the files on the screen.

    Remotely, the tcp connection handling system would then be allowed to send that table, and the remote viewer could then only transmit and recieve encrypted file names and folder names/directory names/ but there at the recieving end decrypt it, and see only the actual file names. Not useless, doesn't prevent remote repair, but to remain secure, after a remote procedure, you would want to change the whole series of tables that concern file and directory names. You as a user would always be looking through a viewer, and never seeing the actual hard drive. If you were a programmer, then you'd never want to encrypt your file system, and you shouldn't be online for the sake of privacy if your selling software..

    It would never be impossible to work with the files because the encryption system would be encorporated into the OS overall. Just impossible to access by simply accessing the drive. That would never be accessed for any other reason except the screen functions. If the drive is read by anything normal, all you should see is the encryption. The decrypted data is something that you keep away from your TCP/IP and internet drivers and data.

    The only other entry point is in the upper memory, if they can get a rountine/program to run from the internet or from email.

    BIOS is typically mirrored in your upper memory, the shuffling routine I mentioned doesn't change the hight of the deck, just how the cards are stacked. This means redesigning Linux to adjust to this procedure, or designing memory manager that takes the message meant to be passed at the assembly language level, and move them.
    BIOS Commands

    There it would keep a table of where the commands were relocated to, and the new memory addresses to use as a result of the relocation in the uppermemory. When you look at your critical drivers at the bios level, they get moved, this changes the addressing and effective addresses that you need at the system level. You use the mirror from that point on, and deny access to bios from that point on. Video Drivers, Sound Drivers, any communications devices such as the printer, ethernet, modem, whatever, are then shuffled, and placed into memory. The start address of the begining of the program is entry point at which you would add the hexdecimal value of the existing command to. The command will have changed it's address, not it's function, it's entry point, but not the distance from the start of the bios to the end. So, it's entry points will not change drastically, but you will have effectively changed them. To keep away from common locations, those drivers are included as cards in a deck, and shuffled. The new locations and entry points are then scrambled, but the ink on the face of the card and memory from first to last location for the length of that program or driver has not changed. Each time this is done, the addresses are updated as any program makes it way, only from the disk to the upper memory. Then the program will be run by the cpu from the upper memory. When you save a program to disk, it will replace the commands with the correct set based upon the convention of BIOS.

    When your desktop loads, it should do about the same thing with programs, and load alternately at the toss of a coin ascending or descending order with it's associated files. At that point, no hacker can mount your system remotely because, your system is the only system that knows how to read the information in memory. There's from the far address to the near address of 0000000000 pending on how far memory goes in Hex. A program can enter memory from the lowest address and work towards the highest as well. A program can actually be written backwards into memory from memory, and the processor have no problem reading it forwards into the cpu. All it needs is a cue, similar to one used for multitasking. Then the hacker cannot use your drivers, TSRs, or any form of any running software. Where the multitasking environment stepped, is right where you can very easily read string data backwards, or forwards into memory. When your memory fills from both ends the highest and the lowest address, so long as the cards are stacked, they never occupy more space. So, the only real concern is dead space between programs, and making sure that when a file in memory ends, the next file will be on top of it, and if you are working from the lowest address to the highest, starting at the very next address underneath the last file.

    One last point, now finding a virus is easy. On your hard drive, it looks like a double incrypted file that's 40 characters long. Because, the only hope that they have of getting on your machine would be another disk, and the only way to hide it is as an encrypted file name. Appending it, with a new program, requires user input and dialog to verify a series of new files. Under normal circumstances, your text files and docuements would retain normal file names, unless encryption was run for the new files in new directories. In memory, it doesn't mind it's own business, and tries to move information where information already exists, such as a program, or critical memory zones, and/or the middle of blank space where there isn't any reserved strings or variables associated to that program. Any attempt to open up used space outside of it's own list of variables assigned memory space is a violation of memory usage, and the multitasking environment is key to this, deletes the culpret from memory.

  7. #6
    Linux User netstrider's Avatar
    Join Date
    Jul 2005
    South Africa
    WTF? That's call I an say

  8. #7
    Linux Guru fingal's Avatar
    Join Date
    Jul 2003
    Birmingham - UK
    Sometimes I feel the need to climb to the top of a mountain and shout HEELLPPPPPPP! Or maybe I just had one too many late nights? I just find most of the above impossible to understand ...

    In any case a Linux box - when security measures are in place - isn't insecure from that point on. It would be different for an enterprise server perhaps, but even as a desktop user I find that many of the same principles of security apply at work.
    I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso

  9. #8
    Linux Enthusiast carlosponti's Avatar
    Join Date
    Dec 2004
    i have ADD so i am sure what you said made sense but i couldnt read it long enough to say that it does.
    Registered Linux user 396557

  10. #9
    The file names and directories are encrypted.
    The common file names and directory names are kept in a file with the new names.

    A file viewer sits between the user, and translates the encrypted file names and directory names to the names that were installed, or that you gave the files. The operating system keeps all of that information, and doesn't allow any other utilities to use decryption window. The old school disk access commands are still there as a part of the operating system, but you must be behind the keyboard and mouse to see the right file names and the right directory names.

    Any remote computer will only see the encrypted file names. There is no encryption alogorithm used, random characters are used, and checked against the table of existing file names and directory names to insure that no to files or directories have the same name. Those random characters are then used to rename the files or directories in a database that only your keyboard/mouse commands can access. When the database is accessed, it simply replaces the encrypted file name or directory name with the original file name or directory name.

    The first message covers how to naturalize randoms and insure that no random table is responsible for the selection of file names or directory names to create the database consistant of the original file or directory name, and new encrypted file or directory name.

    You computer will never present you with a different file system by eye. But, if a computer remotely gains access, there are no common files, no common folders to allow it, to navigate or place a virus that utilizes any of the existing software on your machine.

    One of the biggest problems with viruses is that they use the resources and existing common programs to exist as short programs, that expand in the number of functions that they can commit to by including common files, common functions, and shared resources.

  11. #10
    Linux User ImNeat's Avatar
    Join Date
    Feb 2006
    N. America
    Quote Originally Posted by carlosponti
    i have ADD so i am sure what you said made sense but i couldnt read it long enough to say that it does.
    Haha yea. Way too bloated for my attention span :P
    10" Sony Vaio SRX99P 850MHz P3-M 256MB RAM 20GB HD : ArchLinux
    14" Dell Inspiron 1420N 2GHz Core2Duo 2GB RAM 160GB HD : Xubuntu

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts