UNDERCODE COMMUNITY
2.69K subscribers
1.23K photos
31 videos
2.65K files
80.7K links
πŸ¦‘ Undercode Cyber World!
@UndercodeCommunity


1️⃣ World first platform which Collect & Analyzes every New hacking method.
+ AI Pratice
@Undercode_Testing

2️⃣ Cyber & Tech NEWS:
@Undercode_News

3️⃣ CVE @Daily_CVE

✨ Web & Services:
β†’ Undercode.help
Download Telegram
▁ β–‚ β–„ ο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁

πŸ¦‘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
▁ β–‚ β–„ ο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁
This media is not supported in your browser
VIEW IN TELEGRAM
▁ β–‚ β–„ ο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁

πŸ¦‘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
▁ β–‚ β–„ ο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁

πŸ¦‘Build best dictionnary in 2020 for bruteforce and crack accounts :


1) git clone --depth=1 --branch=master https://www.github.com/landgrey/pydictor.git

2) cd pydictor/

3) chmod +x pydictor.py

4) python pydictor.py

πŸ¦‘All of pydictor can generating wordlist
type wordlist identifier description supported function
core base C1 basic wordlist F1 F2 F3 F4
core char C2 custom character wordlist F1 F2 F3 F4
core chunk C3 permutation and combination wordlist ALL
core conf C4 based on configuration file wordlist ALL
core extend C5 extend wordlist based on rules ALL
core sedb C6 social engineering wordlist ALL
tool combiner T1 combine the specify directory files tool
tool comparer T2 compare two file content difference tool ALL
tool counter T3 word frequency count tool ALL
tool handler T4 handle the input file tool ALL
tool uniqbiner T5 combine and unique the directory files tool ALL
tool uniqifer T6 unique the input file tool ALL
tool hybrider T7 hybrid couples word list tool F1 F2 F3 F4
plugin birthday P1 birthday keyword wordlist in specify datetime scope ALL
plugin ftp P2 against keyword generate ftp password wordlist ALL
plugin pid4 P3 id card last 4 char wordlist ALL
plugin pid6 P4 id card last 6 char wordlist ALL
plugin pid8 P5 id card last 8 char wordlist ALL
plugin scratch P6 wordlist based on web pages keywords ALL

MUCH MORE ON README..

βœ…Verified by Undercoder

@UndercodeTesting
▁ β–‚ β–„ ο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁
▁ β–‚ β–„ iο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁

πŸ¦‘The exploit achieves R/W access to the host's physical memory all ios 10 :) βœ…verified by undercode
t.me/iUndercode


πŸ¦‘This exploit has been tested on the iPhone 7, iOS 10.2 (14C92). To run the exploit against different devices or versions, the symbols must be adjusted.


> The attached archive contains the following directories:
-hostapd-2.6 - A modified version of hostapd utilised in the exploit. This version of hostapd is configured to
support 802.11k RRM, and in particular Neighbor Reports. Moreover, this version of hostapd is
instrumented to add various commands, allowing injection and reception of crafted action frames
used throughout the exploit.
-OneRing - The exploit itself.

πŸ¦‘To run the exploit, you must execute the following steps:
-Connect (and enable) a SoftMAC Wi-Fi dongle to your machine (such as the TL-WN722N)
-Compile the provided version of hostapd
-Modify the "interface" setting under "hostapd-2.6/hostapd/hostapd.conf" to match your interface's name
-Configure the following settings under "OneRing/rrm_exploit/conf.py":
-HOSTAPD_DIR - The directory of the hostapd binary compiled above
-TARGET_MAC - The MAC address of the device being exploited
-AP_MAC - The MAC address of your wireless dongle
-INTERFACE - The name of the wireless dongle's interface
-Configure the following settings under "OneRing/conf.py":
-TARGET_MAC - The MAC address of the device being exploited
-TARGET_IP - The IP address of the device being exploited
-Assemble the backdoor shellcode by running "OneRing/rrm_exploit/assemble_backdoor.sh"
-Assemble each of the code chunks under "OneRing/code_chunks" by running "compile.sh"
-Run hostapd with the configuration file provided above, broadcasting a Wi-Fi network ("test80211k")
-Connect the target device to the network
-Run "OneRing/attack.py"

πŸ¦‘Following the steps above should result in DART's descriptor being mapped into IO-Space, allowing R/W access to the host's physical memory. You can utilise this R/W access by calling the "read_host_dword" and "write_host_dword" functions, respectively.


Proof of Concept:
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/42996.zip

▁ β–‚ β–„ iο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁
▁ β–‚ β–„ ο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁

πŸ¦‘ How to modify *.exe files :

learn how to change *.exe files, in 5 easy steps:

1) Don't try to modify a prog by editing his source in a dissasembler.Why?
Cause that's for programmers and assembly experts only.

try to view it in hex you'll only get tons of crap you don't understand.
First off, you need Resource Hacker(last version). It's a resource editor-
very easy to use, You can download it at h**p://www.users.on.net/johnson/resourcehacker/

2) Unzip the archive, and run ResHacker.exe. You can check out the help file too


3) You will see that the interface is simple and clean. Go to the menu FileOpen or press Ctrl+O to open a file. Browse your way to the file you would like to edit. You can edit *.exe, *.dll, *.ocx, *.scr and *.cpl files, but this tutorial is to teach you how to edit *.exe files, so open one.

4) In the left side of the screen a list of sections will appear.
The most common sections are
-String table;
-RCData;
-Dialog;
-Cursor group;
-Bitmap;
-WAV.
*Icon: You can wiew and change the icon(s) of the program by double-clicking the icon section,chossing the icon, right-clicking on it an pressing "replace resource". After that you can choose the icon you want to replace the original with.
*String table: a bunch of crap, useful sometimes, basic programming knowladge needed.
*RCData: Here the real hacking begins. Modify window titles, buttons, text, and lots more!
*Dialog:Here you can modify the messages or dialogs that appear in a program. Don't forget to press "Compile" when you're done!
*Cursor group: Change the mouse cursors used in the program just like you would change the icon.
*Bitmap: View or change images in the programs easy!
*WAV:Change the sounds in the prog. with your own.


5) In the RCData,Dialog,Menu and String table sections you can do a lot of changes. You can modify or translate the text change links, change buttons, etc.


TIP: To change a window title, search for something like: CAPTION "edit this".
TIP: After all operations press the "Compile Script" button, and when you're done editing save, your work @ FileSave(Save as).
TIP: When you save a file,the original file will be backed up by default and renamed to Name_original and the saved file will have the normal name of the changed prog.
TIP: Sometimes you may get a message like: "This program has a non-standard resource layout... it has probably been compressed with an .EXE compressor." That means that Resource Hacker can't modify it because of it's structure.


@UndercodeTesting
▁ β–‚ β–„ ο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁
▁ β–‚ β–„ ο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁

πŸ¦‘ here is one way to optimize the bandwidth for emule, which not on the manual
> for Old windows :)
t.me/UndercodeTesting


πŸ¦‘CODE
With Windows 2000/XP:Β» speedup

Open "regedit.exe" and do the following:

[HKEY_LOCAL_MACHINESYSTEM]
CurrentControlSet
Services
Tcpip
Parameters
Set as: "GlobalMaxTcpWindowSize"=dword:00007fff

[HKEY_USERS.DEFAULT]
Software
Microsoft
Windows
CurrentVersion
Internet Settings
Set as: "MaxConnectionsPerServer"=dword:00000020
"MaxConnectionsPer1_0Server"=dword:00000020

[HKEY_CURRENT_USER]
Software
Microsoft
Windows
CurrentVersion
Internet Settings
Set as: "MaxConnectionsPerServer"=dword:00000020
"MaxConnectionsPer1_0Server"=dword:00000020

@UndercodeTesting
▁ β–‚ β–„ ο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁
πŸ¦‘ SPEEDUP CONNECTION OLD WINDOWS SUCH XP-AND LOWER
▁ β–‚ β–„ ο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁

πŸ¦‘How to increase FPS on your PC or laptop to improve gaming performance:


Update your graphics drivers.

Give your GPU a slight overclock.

Boost your PC with an optimization tool.

Upgrade your graphics card to a newer model.

Switch out that old HDD and get yourself an SSD.

Turn off Superfetch and Prefetch

Upgrade to an SSD

check out your hardwarwes such graphical card and rams and cpu

Tweaking the AMD/ATI Control Center

@UndercodeTesting
▁ β–‚ β–„ ο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁
▁ β–‚ β–„ ο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁

πŸ¦‘Configuring your Bulletproof FTP Server Tutorial

I am not sure where I found this tutorial, It’s been a while…It might even have been here... ..So if it is one of yours, my hat goes off to you once again....

After reading the excellent tutorial on "Creating an FTP" that Norway posted…

(I would suggest reading and following his tutorial first, then following up with this one)

I thought that perhaps this tutorial might be pretty helpful for those interested in knowing how to configure their Bulletproof FTP Server that don't already know how... Here's how to get started…

This is for the BulletProof FTP Server 2.10. However, It should work fine on most following versions as well.

I'm assuming you have it installed and cracked.

Basics
1. Start the program.
2. Click on Setup > Main > General from the pull-down menu.
3. Enter your server name into the 'Server Name' box. Under Connection set the β€œMax number of users" to any number. This is the limit as to how many users can be on your sever at any time.
4. Click on the 'options' tab of that same panel (on the side)
5. Look at the bottom, under IP Options. Put a check in the box β€œRefuse Multiple Connections from the same IP”. This will prevent one person from blocking your FTP to others.
6. Also put a check in the 'Blocked Banned IP (instead of notifying client). VERY IMPORTANT! If somebody decides to 'Hammer' (attempt to login numerous times VERY quickly) your server/computer may CRASH if you don't enable this.
7. Click on the 'advanced' tab
8. At the bottom again look at the 'hammering area'
9. Enable 'anti-hammer' and 'do not reply to people hammering' Set it for the following: Block IP 120 min if 5 connections in 60 sec. You can set this at whatever you want to but that is pretty much a standard Click 'OK'

Adding Users
11. Setup > User accounts form pull-down.
12. Right click in the empty 'User Accounts' area on the right: choose 'Add'
13. Enter account name. (ie: logon name)
14. In the 'Access rights' box right click: choose β€˜Add’.
15. Browse until you find the directory (folder) you want to share. In the right column you will see a bunch of checkboxes. Put a check in the following ones: Read, Write, Append, Make, List, and +Subdirs. Press 'select'.
16. Enter a password for your new FTP account.
17. Click on 'Miscellaneous' in the left column. Make sure 'Enable Account' is selected. Enable 'Max Number of Users' set it at a number other than zero. 1 for a personal account and more that one for a group account. Enable 'Max. no. of connects per IP' set it at 1

18. Under 'Files' enable 'show relative path' this is a security issue. A FTP client will now not be able to see the ENTIRE path of the FTP. It will only see the path from the main directory. Hide hidden flies as well.
Put a tick in both of these.

Advanced:
You don't need to do any of this stuff, but It will help tweak your server and help you maintain order on it. All of the following will be broken down into small little areas that will tell you how to do one thing at a time.

Changing the Port
The default port is always 21, but you can change this. Many ISPs will routinely do a scan of its own users to find a ftp server, also when people scan for pubs they may scan your IP, thus finding your ftp server. If you do decide to change it many suggest that you make the port over 10,000.
1. Setup > Main > General
2. In the 'Connection' Area is a setting labeled 'Listen on Port Number:'
3. Make it any number you want. That will be your port number.
4. Click 'OK'

Making an 'Upload Only' or 'Download Only' ftp server.
This is for the entire SERVER, not just a user.
1. Setup > Main > Advanced
2. In the advanced window you will have the following options: uploads and downloads, downloads only, and uploads only. By default upload and download will be checked. Change it to whatever you want.
3. Click 'OK’


While you are running your server, usually you will end up spending more time at your computer than you normally do. Don't be afraid to ban IP's. Remember, on your FTP you do as you want.
When you are online you must also select the open server button next to the on-line button which is the on-line Button

You also have to use the actual Numbered ip Address ie: 66.250.216.67

Or even Better yet, get a no-ip.com address

@UndercodeTesting
▁ β–‚ β–„ ο½•π•Ÿπ”»β’Ίπ«Δ†π”¬π““β“” β–„ β–‚ ▁