What's new

Tools OpenHTTP Puncher Server

Have been neglected or scammed indirectly, how can I make payment for something and till no nothing is yet to be done about this issue and sir lfasmpao is replying other issue and leaving mine unattended.

Screenshot_2020-05-11-03-43-04-991_com.paypal.android.p2pmobile.jpg
 

Attachments

Have been neglected or scammed indirectly, how can I make payment for something and till no nothing is yet to be done about this issue and sir lfasmpao is replying other issue and leaving mine unattended.

View attachment 842201
That service is only working on Globe/TM (with specific wan IP). It won't work on another network and your account is automatically registered on the server. If you're having trouble with your account. private message me your account details that you registered on the server so I can check it
 
Last edited:
This will be my starting point to follow Leo's career. I will start my journey by making it work, but there's something I don't understand below;

./ohpserver.exe -port (server port) -proxy (HTTP proxy ip:port) -tunnel (redirection tunnel ip:port)

1) server port
- I presume I can just put anything I like (e.g. typing any 16-bit unsigned numbers while blindfolded).

2) HTTP proxy ip:port
- I don't understand where can I get this one. Can I just type whatever my finger hit? (I have a feeling that it's the squid proxy).

3)
redirection tunnel ip:port
- Is it related to something? (e.g. my server ip). If not, where is this from?

4) Squid Necessary? (squid is my favorite among others)
- is the squid proxy necessary to be installed? If so, i presume that the Question number 2 is the answer.

5) Lastly, what about the CLIENT included in the release
- Where can we find the command?


With all (perhaps some) of these questions answered, I can promise to do my best to make it better. Thanks so much.

P.S. if you could please answer it by number as well thanks.
 
joseph_fugata
1-3 is server arguments.

4) Squid Necessary? (squid is my favorite among others)
nope, you can use other proxy software like tinyproxy, privoxy, polipo etc.

5) Lastly, what about the CLIENT included in the release
specify -h on command argument ^_^
 
I think I finally understand how it works, Thanks to you lfasmpao.

correct me if I'm wrong but below is what I think the closest explanation I can find.

Your method of penetrating NATs is probably two-fold which will be describe below.

In order for the full tunnel to be established, the client side needs to
know the public IP address of the server, and the server needs to learn
the public IP address of the client.

However, in a true client-server model, the server doesn't know the client IP
until the client connects, and NATs will normally drop unknown incoming packets.
In openhttp-puncher, the server also does not need to know the client IP address.

I presume here is how the openhttp-puncher server learns the IP address of the client:
You get around this by having the client "pretend" to be a random hop on
the Internet. You essentially using the same technology a traceroute uses
to detect hops on the Internet, but you're doing the reverse in order to
penetrate the NAT.

Specifically, when the server starts up, it begins sending fixed ICMP echo
request packets to the fixed address something like 3.3.3.3. We expect that these packets
won't be returned.

Now, 3.3.3.3 is not a host we have any access to, nor will we end up spoofing
it. Instead, when a client wants to connect, the client (which knows the server
IP address) sends an ICMP Time Exceeded packet to the server. The ICMP packet
includes the "original" fixed packet that the server was sending to 3.3.3.3.

Why? Well, we're pretending to be a hop on the Internet, politely telling the
server that its original "ICMP echo request" packet couldn't be delivered.
Your NAT, being the gapingly open device it is, is nice enough to notice that
the packet inside the ICMP time exceeded packet matches the packet the server
sent out. It then forwards the ICMP time exceeded back to the server behind
the NAT, including the full IP header from the client, thus allowing the
server to know what the client IP address is!

Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3
...
Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3
...
Server (1.2.3.4): ICMP Echo Request -> 3.3.3.3
...
Client (6.7.8.9): ICMP Time Exceeded (includes ICMP Echo Request to 3.3.3.3) -> 1.2.3.4
Server's NAT: Sees server's Echo Request in client's Time Exceeded packet,
sends entire packet to server because it matches server's outgoing packet

Don't believe me? Just traceroute any host behind your NAT. You'll notice
incoming packets coming in from random IP addresses your router knows
nothing about. Your router knows to send those back to you, rather than another
client on your network, based off of the data inside the ICMP time exceeded packet.

Now, the server has only learned the client IP address. We still have no
method to send any additional data. For the full communication, we use the
same method used in my previous software, chownat, to penetrate both NATs.

Example of a client behind a NAT talking to a machine NOT behind a NAT:
Machine A -> NAT A -> net -> quake server

Machine A sends a UDP packet to quake server, opening a "session".
NAT A sees this and says:
"If any UDP packets come back soon with the same host and port info,
you're routing it to machine A."
Quake server sends UDP packets back, hits NAT A, and NAT A seeing the right
hosts and ports, sends it to machine A. Machine A and quake server are now
able to communicate without any problem.

Now here is how openhttp-puncher works now that client and server know each others IP.
Goal is: Machine A (ssh client) -> NAT A -> net -> NAT B -> Machine B (ssh server)

When you start up the openhttp-puncher server on machine B, it slowly fires off
UDP packets to machine A. Of course, NAT A is not expecting these so it
drops every one of them. Machine B does not stop.

Once you begin the openhttp-puncher client on machine A, it begins sending UDP
packets to machine B. Note: openhttp-puncher defaults source and destination
ports to 8888. Any unprivileged user can set UDP source and dest ports.
Normally the UDP packets that machine A is sending to NAT B would get dropped.
However, since machine B is sending similar packets OUT, NAT B assumes
these are responses and lets them back in. Once machine B sees these packets,
it sends handshake packets back to machine A. These packets will not get
dropped by NAT A because of the same reason: NAT A sees packets going out, and
the packets coming back to the NAT look like responses to the ones going out.

Finally, both sides are fully communicating over UDP, allowing protocols that
run over TCP to tunnel through.
Note: I only assume but i'm sure that there is a keep-alive process on the openhttp-puncher server and client that
always keeps the UDP "session" active. The packets it sends usually have a 0 byte
payload and are only sent when the client is not sending data out. Otherwise,
the fastest it will possibly send the keep-alive packets is one packet every 5
seconds. If any other type of data is traveling through the tunnel, no
keep-alive packets will be transmitted.
 
joseph_fugata
1-3 is server arguments.

4) Squid Necessary? (squid is my favorite among others)
nope, you can use other proxy software like tinyproxy, privoxy, polipo etc.

5) Lastly, what about the CLIENT included in the release
specify -h on command argument ^_^


So here's what I did in Ubuntu 18.04 LTS:

1) Install squid using VPS Manager 3.0 derive from phreaker56 (an You do not have permission to view the full content of this post. Log in or register now.so I no longer need to go trough squid configuration file manually)
- The auto script install everything for me including Dropbear SHH Account manager, and Squid Proxy.

Final prep done:

  • Squid Proxy configured as example = 123.456.789.0 at port 80,8080, and 3128.
  • Dropbear SHH example = 123.456.789.0 at port 22, and port 443
  • Add necessary Payload Domain host allowed
  • Add User With Password
  • Tested everything with You do not have permission to view the full content of this post. Log in or register now. - works fine

2) Run the installation you provided

wget https://github.com/lfasmpao/open-http-puncher/releases/download/0.1/ohpserver-linux32.zip unzip ohpserver-linux32.zip chmod +x ohpserver

3) Run command you provided:
The code works only for me after I omit the .EXE here:

screen -dm bash -c "./ohpserver.exe -port 55555 -proxy 123.456.789.0:8080 -tunnel 123.456.789.0:443"

Nothing happens but I presume it is because it is screen, so I just believed to my self that it's all I need to do and it should work

4) Test it with the Client Provided in the download with all argument needed top run it. NO ERROR BUT NO LUCK.
There must be wrong with my arguments: (SEE ATTACH IMAGE)
http-windows-x86 -port 55555 -proxy 123.456.789.0:8080 -auth josephgwapo:pass123 -payload clients3.google.com

5) Test it with You do not have permission to view the full content of this post. Log in or register now. (SEE ATTACH IMAGE). NO LUCK EITHER.

DID I FOLLOW YOU RIGHT? What have I done wrong?














Untitled.png
Untitled2.png
 

Attachments

it can be a trick din to act as fake information sa firewall 👌🏻 and you can use screen nalang for background process as di ko sure kung stable na yan for a very large crowds
Very useful din ito...pwede sya gawing apn proxy.. na ginagamitan ng username / password
 
gumawa ako sa ubuntu server located at u.s pero ang bagal ohp server + openvpn + injector, di ko pa na try sa singapore di ko lam anong mali yung singapore mo nmn na nasa tunnelcat mabjlis
 
gumawa ako sa ubuntu server located at u.s pero ang bagal ohp server + openvpn + injector, di ko pa na try sa singapore di ko lam anong mali yung singapore mo nmn na nasa tunnelcat mabjlis
 

Users search this thread by keywords

  1. SSH TUNNEL WINDOWS
Back
Top