Can you test my new program ?, short description below:

wrc is a small windows telnet server which provides capability of remote access to windows command-line. wrc is able to work either as a windows service or as a usual windows console application and can handle multiple connections simultaneously.
wrc works on Windows 2k/xp

usage: wrc [-p port] [-i] [-s] [-u] [-?]
-i install wrc as a windows service
-u uninstall wrc windows service
-p port specify port number, default port is 5125
-s run wrc as a console application
-? help

example:

The following command installs wrc as a windows service on port 8888:
wrc -i -p 8888

now we have to start up our wrc windows service:
net start wrc

then we can make a connection, for example:
telnet 127.0.0.1 8888

you can download it from here: <snipped>

Thanks in advance !

Dani AI

Generated

is correct to be cautious and ’s request for source is the minimum reasonable ask. A small telnet-style server that hands out a command shell is exactly the sort of binary that needs reproducible provenance and safe testing procedures before any community member runs it.

Practical checklist for to build trust

  • Publish the full source in a public VCS with a clear license, build instructions, and a reproducible build log (compiler, flags, libs, target OS).

  • Provide a cryptographic release fingerprint and a detached signature (SHA-256 + PGP or similar). Example verification commands:

    sha256sum wrc.exe
    certutil -hashfile wrc.exe SHA256
    gpg --verify wrc.exe.sig wrc.exe
  • State exactly what the server does: ports bound, default listen address, required privileges (service user), whether it spawns an interactive cmd/shell, files/registry it touches, and any persistence.

  • Offer an option to bind to localhost by default, require explicit opt-in for a network-facing service, and implement authentication (not plaintext). Code-sign releases if possible.

Safe testing checklist for reviewers

  • Test only in an isolated VM snapshot with no network or with host-only networking; restore snapshot after tests.

  • Verify hashes/signature before executing and (optionally) submit the binary for an online static scan.

  • Monitor behavior with netstat/ProcessExplorer/ProcMon and capture traffic with Wireshark to confirm no unexpected outbound connections. Example:

    netstat -ano | findstr :<port>
  • Run the server under a low-privilege account; do not install as a service on production machines. Check for created services, autoruns, or unexpected file writes.

Security notes for the author

  • Telnet is plaintext. Prefer authenticated, encrypted transport (TLS/SSH) and avoid invoking an interactive shell over an unauthenticated channel. Sanitize all input, limit concurrency, fail closed on errors, and log actions with timestamps and PID info.

Meeting the checklist above gives community reviewers the concrete evidence needed to test safely and reduces the “unknown binary” risk that highlighted.

Recommended Answers

All 3 Replies

Lets see
- new poster (we've no idea who the hell you are, or what your intent is)
- posting an executable
- without the source code
- which opens up ports on your machine
- to allow remote access to your machine.

JUST HOW DUMB DO YOU THINK WE ARE?

I don't have any bad intensions, what can I do to prove it ?

Post the source code, obviously.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.