▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

🦑Hide Drives and Partitions- old and new windows
pinterest.com/Undercode_Testing

Do you have data on a partition or hard drive that you don't want tampered with or easily accessible to other users? Well, you can hide any drive/partition in Windows XP, NT, and 2000. That means that they won't show up in Explorer or My Computer.

If you want access to that drive from your user account you should create a desktop shortcut before proceeding. Once hidden, you can still access by typing the drive letter and a colon in Start/Run—for example, "D:" will bring up a folder of the contents on your D drive.

The easiest way with Win XP is to use the TweakUI power toy from Mcft. Go to Start/Run and type in "tweakui" (without the quotes).

Go to My Computer/Drives and uncheck the drive/partition(s) you want hidden. Click "Apply" or "OK" when finished.

If you have XP but not Tweak UI you can download it here...
http://www.Mcft.com/windowsxp/downloads/powertoys/xppowertoys.mspx

For Win NT, 2000, and XP you can use the following Registry edit:

*Be sure to back up the Registry before proceeding
http://www.worldstart.com/tips/tips.php/401

Open the Registry Editor by going to Start/Run and typing in "regedit" (without the quotes). Find your way to...

HKEY_CURRENT_USER\Software\Mcft\Windows\CurrentVersion\Policies

Click on "Explorer".

Double-click the "NoDrives" key in the right column. If you don't find a "NoDrives" registry key, just right-click in the right pane and choose "New/DWORD Value" then name the key "NoDrives".

You'll see a value like "0000 00 00 00 00". This is where the fun starts. The four sets of double zeros (after the "0000") are where you'll enter the values for the drive/partitions. Now, stay with me on this—it's not as complicated as it sounds:

The first column is for drives A-H, the second for I-P, the third for Q-X, and the fourth for Y-Z.

The values for each drive are as follows:

1 - A I Q Y
2 - B J R Z
4 - C K S
8 - D L T
16 - E M U
32 - F N V
64 - G O W
80 - H P X

So, let's say you want to hide drive D. In the first column you would put "08". For drive K you would put "04" in the second column.

But what if you want to hide more than one drive in a column? Simply add the values together: D+E = 8+16 = 24. So in the first column you would put "24".

Still baffled? If you haveold windows - then go get TweakUI and save yourself the math.

Whichever method you use, you can rest easy knowing that the files on that drive or partition are less accessible to other users.

@UndercodeTesting
▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

🦑HOW BT PHONE CARDS WORK ? :
t.me/UndercodeTesting

> Contrary to popular belief, BT phonecards do not work using a magnetic
strip system. The reason for this being that a magnetic strip would be
read only.

🦑So how do they work then?

1) Well, examine a phonecard - preferably a used one if you are going to
scratch it or dissect it. If you look on the printed surface (the green
side - which is the front) you will find two lines which form a thick band.
Underneath this area is a "track" which holds the information about the
number of units used up and how many are left. A used phonecard will have
some tiny bars marked on the track near one end.

2) On the reverse side of the phonecard (the black side) you can see a shiny
black strip in contrast to the matt black which has text on it (on older
phone cards the whole of this side is shiny black). Anyway, this shiny strip
is "opposite" the band on the front and acts as a "window" to the information
on the track - for the simple reason that it is no ordinary shiny black
plastic. This special black plastic is not like all the others (which do
not let normal light or infra-red light pass through) but is transparent to
infra-red light. When a phonecard is in the machine, an infra-red beam is
shone through the back of the card and the reflected beam is checked to
detect the time units remaining.

3) Now to explain the track itself which is protected by a layer of paint that
also serves as the base for printing text and figures visible to the user.
On a 20-unit card, the track has 20 tiny rectangular areas (called
diffraction gratings - you might have come across them if you took physics)
which affect the light reflected by the cards. As the time units are used up,
the ares are destroyed by an eraser head. The design of the assembly enables
the progress of the erasing operation to be checked. in fact, the 20
rectangular areas touch each other and form a continuous strip on the card.

4)The area which is read is wider than the track. This makes it possible to
detect a reduction in track width.

5) Each unit is separated from its neighbour by a distance of 0.6mm. the erase
area is greater than the width of the track so that the unit is always
completely erased. The dimensions of both the card and the time units
suggest 140 as the theoretical maximum number of units possible.

6) The read-and-erase mechanism consists of a moving carriage on which are
fixed the eraser head and the optical components for reading. the carriage
is driven by a stepping device which moves along the track to determine
whether each unit is god or erased. when a unit has been consumed by the
cardphone, the area is erased in its turn and the carriage moves on one step.

6) OK, for those that weant to know, here is an ascii graphical representation
of the read and erase geometry :

Time units
---------------------------------------------------------
Track | | | | | | | | | 1.2mm
---------------------------------------------------------
<0.6mm>

Area read Area erased
*** *********
---------------***------------------*********------------
| | | *** | | | *|*****|* | | 1.6mm
---------------***------------------*********------------
*** *********
0.4mm 0.7mm

Well I hope you all understood that! Most of the information in this text
file was obtained from British Telecom <spit> sources so is quite likely to
be correct (after all, they should know their own cardphones!).

Archaos.

------EOF--------------

Finger for PGP Key.

@UndercodeTesting
▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

🦑Basic BIOS password crack ":
for 99% of situations

This is a password hack but it clears the BIOS such that the next time you start the PC, the CMOS does not ask for any password. Now if you are able to bring the DOS prompt up, then you will be able to change the BIOS setting to the default. To clear the CMOS do the following:
Get DOS prompt and type:
DEBUG hit enter
-o 70 2e hit enter
-o 71 ff hit enter
-q hit enter
exit hit enter
Restart the computer. It works on most versions of the AWARD BIOS.



🦑Accessing information on the hard disk
When you turn on the host machine, enter the CMOS setup menu (usually you have to press F2, or DEL, or CTRL+ALT+S during the boot sequence) and go to STANDARD CMOS SETUP, and set the channel to which you have put the hard disk as TYPE=Auto, MODE=AUTO, then SAVE & EXIT SETUP. Now you have access to the hard disk.

Standard BIOS backdoor passwords
The first, less invasive, attempt to bypass a BIOS password is to try on of these standard manufacturer's backdoor passwords:
AWARD BIOS
AWARD SW, AWARD_SW, Award SW, AWARD PW, _award, awkward, J64, j256, j262, j332, j322, 01322222, 589589, 589721, 595595, 598598, HLT, SER, SKY_FOX, aLLy, aLLY, Condo, CONCAT, TTPTHA, aPAf, HLT, KDD, ZBAAACA, ZAAADA, ZJAAADC, djonet, %øåñòü ïpîáåëîâ%, %äåâÿòü ïpîáåëîâ%
🦑AMI BIOS
AMI, A.M.I., AMI SW, AMI_SW, BIOS, PASSWORD, HEWITT RAND, Oder
Other passwords you may try (for AMI/AWARD or other BIOSes)
LKWPETER, lkwpeter, BIOSTAR, biostar, BIOSSTAR, biosstar, ALFAROME, Syxz, Wodj
Note that the key associated to "_" in the US keyboard corresponds to "?" in some European keyboards (such as Italian and German ones), so -- for example -- you should type AWARD?SW when using those keyboards. Also remember that passwords are Case Sensitive. The last two passwords in the AWARD BIOS list are in Russian.

🦑Flashing BIOS via software
If you have access to the computer when it's turned on, you could try one of those programs that remove the password from the BIOS, by invalidating its memory.
However, it might happen you don't have one of those programs when you have access to the computer, so you'd better learn how to do manually what they do. You can reset the BIOS to its default values using the MS-DOS tool DEBUG (type DEBUG at the command prompt. You'd better do it in pure MS-DOS mode, not from a MS-DOS shell window in Windows). Once you are in the debug environment enter the following commands:
AMI/AWARD BIOS
O 70 17
O 71 17
Q
PHOENIX BIOS
O 70 FF
O 71 17
Q
GENERIC
Invalidates CMOS RAM.
Should work on all AT motherboards
(XT motherboards don't have CMOS)
O 70 2E
O 71 FF
Q
Note that the first letter is a "O" not the number "0". The numbers which follow are two bytes in hex format.

🦑Flashing BIOS via hardware
If you can't access the computer when it's on, and the standard backdoor passwords didn't work, you'll have to flash the BIOS via hardware. Please read the important notes at the end of this section before to try any of these methods.

🦑Using the jumpers
The canonical way to flash the BIOS via hardware is to plug, unplug, or switch a jumper on the motherboard (for "switching a jumper" I mean that you find a jumper that joins the central pin and a side pin of a group of three pins, you should then unplug the jumper and then plug it to the central pin and to the pin on the opposite side, so if the jumper is normally on position 1-2, you have to put it on position 2-3, or vice versa). This jumper is not always located near to the BIOS, but could be anywhere on the motherboard.
To find the correct jumper you should read the motherboard's manual.
Once you've located the correct jumper, switch it (or plug or unplug it, depending from what the manual says) while the computer is turned OFF. Wait a couple of seconds then put the jumper back to its original position. In some motherboards it may happen that the computer will automatically turn itself on, after flashing the BIOS. In this case, turn it off, and put the jumper back to its original position, then turn it on again. Other motherboards require you turn the computer on for a few seconds to flash the BIOS.
If you don't have the motherboard's manual, you'll have to "brute force" it... trying out all the jumpers. In this case, try first the isolated ones (not in a group), the ones near to the BIOS, and the ones you can switch (as I explained before). If all them fail, try all the others. However, you must modify the status of only one jumper per attempt, otherwise you could damage the motherboard (since you don't know what the jumper you modified is actually meant for). If the password request screen still appear, try another one.
If after flashing the BIOS, the computer won't boot when you turn it on, turn it off, and wait some seconds before to retry.

🦑Removing the battery
If you can't find the jumper to flash the BIOS or if such jumper doesn't exist, you can remove the battery that keeps the BIOS memory alive. It's a button-size battery somewhere on the motherboard (on elder computers the battery could be a small, typically blue, cylinder soldered to the motherboard, but usually has a jumper on its side to disconnect it, otherwise you'll have to unsolder it and then solder it back). Take it away for 15-30 minutes or more, then put it back and the data contained into the BIOS memory should be volatilized. I'd suggest you to remove it for about one hour to be sure, because if you put it back when the data aren't erased yet you'll have to wait more time, as you've never removed it. If at first it doesn't work, try to remove the battery overnight.
Important note: in laptop and notebooks you don't have to remove the computer's power batteries (which would be useless), but you should open your computer and remove the CMOS battery from the motherboard.

🦑Short-circuiting the chip
Another way to clear the CMOS RAM is to reset it by short circuiting two pins of the BIOS chip for a few seconds. You can do that with a small piece of electric wire or with a bent paper clip. Always make sure that the computer is turned OFF before to try this operation.
Here is a list of EPROM chips that are commonly used in the BIOS industry. You may find similar chips with different names if they are compatible chips made by another brand. If you find the BIOS chip you are working on matches with one of the following you can try to short-circuit the appropriate pins. Be careful, because this operation may damage the chip.
CHIPS P82C206 (square)
Short together pins 12 and 32 (the first and the last pins on the bottom edge of the chip) or pins 74 and 75 (the two pins on the upper left corner).
gnd
74
|__________________
5v 75--| |
| |
| |
| CHIPS |
1 * | |
| P82C206 |
| |
| |
|___________________|
| |
| gnd | 5v
12 32
OPTi F82C206 (rectangular)
Short together pins 3 and 26 (third pin from left side and fifth pin from right side on the bottom edge).
80 51
|______________|
81 -| |- 50
| |
| |
| OPTi |
| |
| F82C206 |
| |
100-|________________|-31
|| | |
1 || | | 30
3 26

Dallas DS1287, DS1287A
Benchmarq bp3287MT, bq3287AMT
The Dallas DS1287 and DS1287A, and the compatible Benchmarq bp3287MT and bq3287AMT chips have a built-in battery. This battery should last up to ten years. Any motherboard using these chips should not have an additional battery (this means you can't flash the BIOS by removing a battery). When the battery fails, the RTC chip would be replaced.
CMOS RAM can be cleared on the 1287A and 3287AMT chips by shorting pins 12 and 21.
The 1287 (and 3287MT) differ from the 1287A in that the CMOS RAM can't be cleared. If there is a problem such as a forgotten password, the chip must be replaced. (In this case it is recommended to replace the 1287 with a 1287A). Also the Dallas 12887 and 12887A are similar but contain twice as much CMOS RAM storage.
__________
1 -| * U |- 24 5v
2 -| |- 23
3 -| |- 22
4 -| |- 21 RCL (RAM Clear)
5 -| |- 20
6 -| |- 19
7 -| |- 18
8 -| |- 17
9 -| |- 16
10 -| |- 15
11 -| |- 14
gnd 12 -|__________|- 13

NOTE: Although these are 24-pin chips,
the Dallas chips may be missing 5 pins,
these are unused pins.
Most chips have unused pins,
though usually they are still present.

Dallas DS12885S
Benchmarq bq3258S
Hitachi HD146818AP
Samsung KS82C6818A
This is a rectangular 24-pin DIP chip, usually in a socket. The number on the chip should end in 6818.
Although this chip is pin-compatible with the Dallas 1287/1287A, there is no built-in battery.
Short together pins 12 and 24.
5v
24 20 13
|___________|____________________|
| |
| DALLAS |
|> |
| DS12885S |
| |
|__________________________________|
| |
1 12
gnd

Motorola MC146818AP
Short pins 12 and 24. These are the pins on diagonally opposite corners - lower left and upper right. You might also try pins 12 and 20.
__________
1 -| * U |- 24 5v
2 -| |- 23
3 -| |- 22
4 -| |- 21
5 -| |- 20
6 -| |- 19
7 -| |- 18
8 -| |- 17
9 -| |- 16
10 -| |- 15
11 -| |- 14
gnd 12 -|__________|- 13

Replacing the chip
If nothing works, you could replace the existing BIOS chip with a new one you can buy from your specialized electronic shop or your computer supplier. It's a quick operation if the chip is inserted on a base and not soldered to the motherboard, otherwise you'll have to unsolder it and then put the new one. In this case would be more convenient to solder a base on which you'll then plug the new chip, in the eventuality that you'll have to change it again. If you can't find the BIOS chip specifically made for your motherboard, you should buy one of the same type (probably one of the ones shown above) and look in your motherboard manufacturer's website to see if there's the BIOS image to download. Then you should copy that image on the chip you bought with an EPROM programmer.

Important
Whether is the method you use, when you flash the BIOS not only the password, but also all the other configuration data will be reset to the factory defaults, so when you are booting for the first time after a BIOS flash, you should enter the CMOS configuration menu (as explained before) and fix up some things.
Also, when you boot Windows, it may happen that it finds some new device, because of the new configuration of the BIOS, in this case you'll probably need the Windows installation CD because Windows may ask you for some external files. If Windows doesn't see the CD-ROM try to eject and re-insert the CD-ROM again. If Windows can't find the CD-ROM drive and you set it properly from the BIOS config, just reboot with the reset key, and in the next run Windows should find it. However most files needed by the system while installing new hardware could also be found in C:WINDOWS, C:WINDOWSSYSTEM, or C:WINDOWSINF .

Key Disk for Toshiba laptops
Some Toshiba notebooks allow to bypass BIOS by inserting a "key-disk" in the floppy disk drive while booting. To create a Toshiba Keydisk, take a 720Kb or 1.44Mb floppy disk, format it (if it's not formatted yet), then use a hex editor such as Hex Workshop (***.bpsoft.com/downloads/index.html) to change the first five bytes of the second sector (the one after the boot sector) and set them to 4B 45 59 00 00 (note that the first three bytes are the ASCII for "KEY" followed by two zeroes). Once you have created the key disk put it into the notebook's drive and turn it on, then push the reset button and when asked for password, press Enter. You will be asked to Set Password again. Press Y and Enter. You'll enter the BIOS configuration where you can set a new password.

Key protected cases
A final note about those old computers (up to 486 and early Pentiums) protected with a key that prevented the use of the mouse and the keyboard or the power button. All you have to do with them is to follow the wires connected to the key hole, locate the jumper to which they are connected and unplug it.

@UndercodeTesting
▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

🦑Basic BIOS password crack

▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

🦑Delete An "undeletable" File :
t.me/UndercodeTesting

🦑𝕃𝔼𝕋'𝕊 𝕊𝕋𝔸ℝ𝕋 :

Open a Command Prompt window and leave it open.
Close all open programs.
Click Start, Run and enter TASKMGR.EXE
Go to the Processes tab and End Process on Explorer.exe.
Leave Task Manager open.
Go back to the Command Prompt window and change to the directory the AVI (or other undeletable file) is located in.
At the command prompt type DEL <filename> where <filename> is the file you wish to delete.
Go back to Task Manager, click File, New Task and enter EXPLORER.EXE to restart the GUI shell.
Close Task Manager.


Or you can try this

Open Notepad.exe

Click File>Save As..>

locate the folder where ur undeletable file is

Choose 'All files' from the file type box

click once on the file u wanna delete so its name appears in the 'filename' box

put a " at the start and end of the filename
(the filename should have the extension of the undeletable file so it will overwrite it)

click save,

It should ask u to overwrite the existing file, choose yes and u can delete it as normal


Here's a manual way of doing it. I'll take this off once you put into your first post zain.

1. Start
2. Run
3. Type: command
4. To move into a directory type: cd c:\*** (The stars stand for your folder)
5. If you cannot access the folder because it has spaces for example Program Files or Kazaa Lite folder you have to do the following. instead of typing in the full folder name only take the first 6 letters then put a ~ and then 1 without spaces. Example: cd c:\progra~1\kazaal~1
6. Once your in the folder the non-deletable file it in type in dir - a list will come up with everything inside.
7. Now to delete the file type in del ***.bmp, txt, jpg, avi, etc... And if the file name has spaces you would use the special 1st 6 letters followed by a ~ and a 1 rule. Example: if your file name was bad file.bmp you would type once in the specific folder thorugh command, del badfil~1.bmp and your file should be gone. Make sure to type in the correct extension.

@UndercodeTesting
▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

🦑This tip requires a change to the Windows Registry. Please see the MSFN Guide "Backup Your Registry" if you are new to the Windows Registry:
instagram.com/UndercodeTesting

🦑𝕃𝔼𝕋'𝕊 𝕊𝕋𝔸ℝ𝕋 :

1) Windows Media Player (WMP) is a built-in application that allows you to play multimedia files. Like many other applications, WMP remembers the most recently played files and displays them in the Recent File List under the File menu. This feature is useful if you regularly play certain files, but you may want to clear the list if you share the computer and a user account or create archives and CDs.

2) There are two ways you can clear the list:

I. The ClearMRU.exe Utility is available for free in the Windows Media Player Bonus Pack from Microsoft, but Microsoft does not support this tool.

II. You can also manually delete the list through the Windows Registry:

1. Start the Windows Registry Editor, regedit.exe, by typing regedit in the Windows Run Command Line.

2. Go to HKEY_CURRENT_USER\Software\Microsoft\MediaPlayer\Player\RecentFileList.

3. Delete the RecentFileList subkey.

4. If you've also streamed content from the Internet, you can delete the RecentURLList subkey.

5. Exit the Registry Editor.

6. Restart the computer.

To keep certain files in the list, don't delete the entire key. Deleting individual entries within the key will get rid of the files that you no longer want in the Recent File List.

@UndercodeTesting
▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

🦑CUSTOMIZE START BUTTON FOR MAJOR WINDOWS VERSIONS :


First you need a tool called "Resource Hacker". This free program allows you to change resources in any .exe file such as "Explorer.exe", which includes the [Start] button's Label. You can visit Download.com and search there for "Resource Hacker".
After you download it, follow the guide here:

🦑Step 1:

A - Run "Resource Hacker" and open the file "%windir%\Explorer.exe".
B - You see a Tree of all Resources in this file, expand the "String Table"
C - Find the "start" and replace it with your own text. then press the [Compile Script] button.
D - Save "Explorer.exe" as "MyStart.exe" DONT save it as Explorer.exe, do "save as.." and give it a new name.
E - Quit "Resource Hacker".

🦑Step 2:

A - Click on the [Start] button and choose the "Run..." item from the start menu. (Or use the shortcut key WinKey+R)
B - Type "RegEdit" in the Run "Dialog Box". And then press the [Ok] buton to run the "Registry Editor" program.
C - Go to: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon" and find the "Shell" property.
D - Replace value of the "Shell" property to "MyStart.exe".
E - Quit "Registry Editor".
F - Restart your system.

Note about Registry Editor:
if you did not find the key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon", you can search the Registry for the "Explorer.exe", to do this use the Edit Menu | Find Next (Ctrl+F).

@UndercodeTesting
▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

🦑How to find a remote IP
twitter.com/UndercodeNews

Method 1

To view someone's IP# when they send you hotmail email do this:
1) Click "Options" on the upper right side of the page.
2) On the left side of the page, Click "Mail"
3) Click "Mail Display Settings"
4) Under "Message Headers" select "Full" or "Advanced"
5) Click ok

Method 2
reg a dydns account and install the ip pointer, so each time you ping the host name you regestored

for example:
you regestor the host name myhost.dydns.com, then you keep a little software running on the target host. The little software will keep update your IP to dydns.com server.

so at your pc just start cmd, and ping myhost.dydns.com, it will give you the most updated ip address.

Method 3
neverender, what doesn't work for you? Simply type in nc -vvv -l -p 80 on your box, which will set it to listen in verbose mode on port 80. Then give them a link to your IP address (for example: 111.111.111.11) and tell them to type it in their browser. The browser should resolve the address as well as append port 80 automatically. Just make sure that your friend is not very computer literate.

Method 4
Just download a very simple server such as this one and install it on your comp. Then run it and give your ip to the person you want and tell them to connect to it through a browser. Your server will log their connection and you will get their IP.




@UndercodeTesting
▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

🦑 Security holes manifest themselves in (broadly) four ways
youtube.com/undercode

1) Physical Security Holes.

- Where the potential problem is caused by giving unauthorised persons
physical access to the machine, where this might allow them to perform
things that they shouldn't be able to do.

A good example of this would be a public workstation room where it would
be trivial for a user to reboot a machine into single-user mode and muck
around with the workstation filestore, if precautions are not taken.

Another example of this is the need to restrict access to confidential
backup tapes, which may (otherwise) be read by any user with access to
the tapes and a tape drive, whether they are meant to have permission or
not.

2) Software Security Holes

- Where the problem is caused by badly written items of "privledged"
software (daemons, cronjobs) which can be compromised into doing things
which they shouldn't oughta.

The most famous example of this is the "sendmail debug" hole (see
bibliography) which would enable a cracker to bootstrap a "root" shell.
This could be used to delete your filestore, create a new account, copy
your password file, anything.

(Contrary to popular opinion, crack attacks via sendmail were not just
restricted to the infamous "Internet Worm" - any cracker could do this
by using "telnet" to port 25 on the target machine. The story behind a
similar hole (this time in the EMACS "move-mail" software) is described
in [Stoll].)

New holes like this appear all the time, and your best hopes are to:

a: try to structure your system so that as little software as possible
runs with root/daemon/bin privileges, and that which does is known to
be robust.

b: subscribe to a mailing list which can get details of problems
and/or fixes out to you as quickly as possible, and then ACT when you
receive information.

>From: Wes Morgan <morgan@edu.uky.ms>
>
> c: When installing/upgrading a given system, try to install/enable only
> those software packages for which you have an immediate or foreseeable
> need. Many packages include daemons or utilities which can reveal
> information to outsiders. For instance, AT&T System V Unix' accounting
> package includes acctcom(1), which will (by default) allow any user to
> review the daily accounting data for any other user. Many TCP/IP packa-
> ges automatically install/run programs such as rwhod, fingerd, and
> <occasionally> tftpd, all of which can present security problems.
>
> Careful system administration is the solution. Most of these programs
> are initialized/started at boot time; you may wish to modify your boot
> scripts (usually in the /etc, /etc/rc, /etc/rcX.d directories) to pre-
> vent their execution. You may wish to remove some utilities completely.
> For some utilities, a simple chmod(1) can prevent access from unauthorized
> users.
>
> In summary, DON'T TRUST INSTALLATION SCRIPTS/PROGRAMS! Such facilities
> tend to install/run everything in the package without asking you. Most
> installation documentation includes lists of "the programs included in
> this package"; be sure to review it.

3) Incompatible Usage Security Holes

- Where, through lack of experience, or no fault of his/her own, the
System Manager assembles a combination of hardware and software which
when used as a system is seriously flawed from a security point of view.
It is the incompatibility of trying to do two unconnected but useful
things which creates the security hole.

Problems like this are a pain to find once a system is set up and
running, so it is better to build your system with them in mind. It's
never too late to have a rethink, though.

Some examples are detailed below; let's not go into them here, it would
only spoil the surprise.

4) Choosing a suitable security philosophy and maintaining it.

>From: Gene Spafford <spaf@cs.purdue.edu>
>The fourth kind of security problem is one of perception and
>understanding. Perfect software, protected hardware, and compatible
>components don't work unless you have selected an appropriate security
>policy and turned on the parts of your system that enforce it. Having
>the best password mechanism in the world is worthless if your users
>think that their login name backwards is a good password! Security is
>relative to a policy (or set of policies) and the operation of a system
>in conformance with that policy.

---

From: Hacking
Subject: Hacking Ideas
Date: 11/10/93

( Please contribute by sending E-Mail to <scott@santafe.edu> ... )

[ Many ideas taken from: HaxNet - APG V1.3 : Guide to finding new holes]

NOTE: I think this should be divided into general categories:
1) General principles
2) Looking for holes in src (most items here)
3) Looking in binary distributions
4) Looking in site specific configurations

The following general classifications suggest themselves:
1) SUID/SGID
2) Return codes/error conditions
3) unexpected input
4) race conditions
5) authentication
6) implicit trust
7) parameters
8) permissions
9) interrupts
10) I/O
11) symbolic links
12) Daemons, particularly those taking user input.
13) Kernel race conditions
14) what else? - please add categories

(Suggested splitting of above into main and sub-catagories)
I: Suid binaries and scripts
unexpected user interactions
flawed liberary calls
implicit assumptions of external conditions (sym links, loc. paths)
race conditions
II: daemons running with priviliged uid's
race conditions
poor file protectons
implicit file protections
trust
authentication
III: Kernel problems
Kernel race conditions
device driver code

The following four step method was created by System Development
Corporation, who report a 65% success rate on the flaw hypotheses
generated. Doing a comprehensive search for operating system flaws
requires four steps:

Step 1) Knowledge of system control structure.
===============================================
To find security holes, and identifying design weaknesses it is
necessary to understand the system control structure, and layers.
One should be able to list the:
A) security objects: items to be protected. ie: a users file.
B) control objects: items that protect security objects. ie: a i-node
C) mutual objects : objects in both classes. ie: the password file
With such a list, it is possible to graphically represent a control
hierarchy and identify potential points of attack. Making flow charts
to give a visual breakdown of relationships definitely helps.
Reading the various users, operators, and administrators manuals should
provide this information.
(following para's should probably be moved to a "legal" section)
Reading and greping source code should also prove valuable. For those
without a source licence, I would suggest we use LINUX, NET2, and BSD386
distributions in order to stay legal. At some future time we may be able
to form a working contract between someone or a company with legal access
to other distributions and members actively participating in this project.
It appears that extracts of proprietary code may be used for academic
study, so long as they are not reused in a commercial product - more
checking is necessary though.

Step 2) Generate an inventory of suspected flaws. (i.e. flaw hypotheses)
========================================================================
In particular we want:
Code history:
What UNIX src does a particular flavor derive from? This is important
for cross references (very often only one vendor patches certain code,
which may get reused, in it's unpatched reincarnation by others)
A solid cross reference:
Who checked which bug in what OS and what version prevents us from
duplicating work.

A good start would be listing all the suid binaries on the various OS
flavors/versions. Then try to work out why each program is suid. i.e.:
rcp is suid root because it must use a privilaged port to do user
name authentication.
Often code that was never designed to be suid, is made suid, durring
porting to solve file access problems.
We need to develope a data base that will be able to look at pairs and
triplets of data, specificly: program name, suid, sgid, object accessed
(why prog is suid/sgid), OS flavor/version, and flav/vers geniology.
Any sugestions on how to implement such a DB?

Step 3) Confirm hypotheses. (test and exploit flaws)
====================================================

Step 4) Make generalizations of the underlying system weaknesses, for
which the flaw represents a specific instance.
=====================================================================

Tool Box:
=========
AGREP: I suggest everyone obtain, and install agrep from:
ftp cs.arizona.edu /agrep/agrep.tar.Z
Agrep supports "windowing" so it can look for routines, and subroutines.
It also supports logical operators and is thus ideally suited to automating
the search for many of the following flaws. i.e. <psudocode>
agrep WINDOW {suid() NOT taintperl()} /usr/local/*.pl
or agrep WINDOW {[suid() OR sgid()] AND [system() OR popen() OR execlp()
OR execvp()]} /usr/local/src/*.c

PERMUTATION PROGRAM: Another tool worth producing is a program to generate
all possible permutations of command line flags/arguments in order to uncover
undocumented features, and try to produce errors.

TCOV:

CRASH: Posted to USENET (what FTP archive?) (descrip?)

PAPERS: There are several papers that discuss methods of finding flaws, and
present test suites.
1) An Emphirical Study of the reliability of UNIX Utilities, by Barton P.
Miller, Lars Fredriksen, and Bryan So, Comm ACM, v33 n12, pp32-44,
Dec '90. Describes a test suite for testing random input strings.
Results indicated that 25% of the programs hung, crashed, or misbehaved.
In one case the OS crashed. An understanding of buffer and register
layout on the environment in question, and the expected input is likely
to produce the desired results.
2) The Mothra tools set, in Proceedings of the 22nd Hawaii International
Conference on Systems and Software, pages 275-284, Kona, HI, January '89
3) Extending Mutation Testing to Find Environmental Bugs, by Eugene H.
Spafford, Software Practice and Experience, 20(2):181-189, Feb '90
4) A paper by IBM was mentioned that was submitted to USENIX a few years
ago. (Anyone have a citation?).

Specific Flaws to Check For:
============================
1) Look for routines that don't do boundary checking, or verify input.
ie: the gets() family of routines, where it is possible to overwrite
buffer boundaries. ( sprintf()?, gets(), etc. )
also: strcpy() which is why most src has:
#define SCYPYN((a)(b)) strcpy(a, b, sizeof(a))

2) SUID/SGID routines written in one of the shells, instead of C or
PERL.

3) SUID/SGID routines written in PERL that don't use the "taintperl"
program.)

4) SUID/SGID routines that use the system(), popen(), execlp(), or
execvp() calls to run something else.

5) Any program that uses relative path names inside the program.

6) The use of relative path names to specify dynamically linked libraries.
(look in Makefile).

7) Routines that don't check error return codes from system calls. (ie:
fork(2), suid(2), etc), setuid() rather, as in the famous rcp bug

8) Holes can often be found in code that:
A) is ported to a new environment.
B) receives unexpected input.
C) interacts with other local software.
D) accesses system files like passwd, L.sys, etc.
E) reads input from a publicly writable file/directory.
F) diagnostic programs which are typically not user-proofed.

9) Test code for unexpected input. Coverage, data flow, and mutation
testing tools are available.

10) Look in man pages, and users guides for warnings against doing X, and
try variations of X. Ditto for "bugs" section.

11) Look for seldom used, or unusual functions or commands - read backwards.
In particular looking for undocumented flags/arguments may prove useful.
Check flags that were in prior releases, or in other OS versions. Check
for options that other programs might use. For instance telnet uses -h
option to login ...
right, as most login.c's I've seen have:
if((getuid()) && hflag){
syslog()
exit()
}

12) Look for race conditions.

13) Failure of software to authenticate that it is really communicating
with the desired software or hardware module it wants to be accessing.

14) Lack or error detection to reset protection mechanisms following an
error.

15) Poor implementation resulting in, for example, condition codes being
improperly tested.

16) Implicit trust: Routine B assumes routine A's parameters are correct
because routine A is a system process.

17) System stores it's data or references user parameters in the users
address space.

18) Inter process communication: return conditions (passwd OK, illegal
parameter, segment error, etc) can provide a significant wedge, esp.
when combined with (17).

19) User parameters may not be adequately checked.

20) Addresses that overlap or refer to system areas.

21) Condition code checks may be omitted.

22) Failure to anticipate unusual or extraordinary parameters.

23) Look for system levels where the modules involved were written by
different programmers, or groups of programmers - holes are likely
to be found.

24) Registers that point to the location of a parameters value instead
of passing the value itself.

25) Any program running with system privileges. (too many progs are given
uid 0, to facilitate access to certain tables, etc.)

26) Group or world readable temporary files, buffers, etc.

27) Lack of threshold values, and lack of logging/notification once these
have been triggered.

28) Changing parameters of critical system areas prior to their execution
by a concurrent process. (race conditions)

29) Inadequate boundary checking at compile time, for example, a user
may be able to execute machine code disguised as data in a data area.
(if text and data areas are shared)

30) Improperly handling user generated asynchronous interrupts. Users
interrupting a process, performing an operation, and either returning
to continue the process or begin another will frequently leave the
system in an unprotected state. Partially written files are left open,
improper writing of protection infraction messages, improper setting
of protection bits, etc often occur.

31) Code that uses fopen(3) without setting the umask. ( eg: at(1), etc. )
In general, code that does not reset the real and effective uid before
forking.

32) Trace is your friend (or truss in SVR4) for helping figure out what
system calls a program is using.

33) Scan /usr/local fs's closely. Many admins will install software from
the net. Often you'll find tcpdump, top, nfswatch, ... suid'd root for
their ease of use.

34) Check suid programs to see if they are the ones originally put on the
system. Admins will sometimes put in a passwd replacement which is less
secure than the distributed version.

35) Look for programs that were there to install software or loadable
kernel modules.

36) Dynamically linked programs in general. Remember LD_PRELOAD, I think
that was the variable.

37) I/O channel programming is a prime target. Look for logical errors,
inconsistencies, and omissions.

38) See if it's possible for a I/O channel program to modify itself, loop
back, and then execute the newly modified code. (instruction pre-load
may screw this up)

39) If I/O channels act as independent processors they may have unlimited
access to memory, thus system code may be modified in memory prior to
execution.

40) Look for bugs requiring flaws in multiple pieces of software, i.e. say
program a can be used to change config file /etc/a now program b assumes
the information in a to be correct and this leads to unexpected results
(just look at how many programs trust /etc/utmp)

41) Any program, especially those suid/sgid, that allow shell escapes.

@UndercodeTesting
▁ ▂ ▄ ｕ𝕟𝔻Ⓔ𝐫Ć𝔬𝓓ⓔ ▄ ▂ ▁

🦑 Security holes manifest themselves in (broadly) four ways