Rocksolid Light

Welcome to novaBBS (yes, it's Usenet)

register  nodelist  faq  

I give you the man who -- the man who -- uh, I forgets the man who? -- Beauregard Bugleboy


rocksolid / Hacking / shellcode challenge

SubjectAuthor
* shellcode challengeAnonymous
+- Re: shellcode challengerslightuser
`- Re: shellcode challengeAnonymous

1
Subject: shellcode challenge
From: Anonymous
Newsgroups: rocksolid.shared.hacking
Organization: i2pn2 (i2pn.org)
Date: Sun, 30 Aug 2020 21:20 UTC
Path: i2pn2.org!.POSTED!not-for-mail
From: pos...@anon.com (Anonymous)
Newsgroups: rocksolid.shared.hacking
Subject: shellcode challenge
Date: Sun, 30 Aug 2020 14:20:30 -0700
Organization: i2pn2 (i2pn.org)
Message-ID: <ha.850.2hb6u0@anon.com>
Content-Type: text/plain; charset=UTF-8
Injection-Info: i2pn2.org; posting-account="def2";
logging-data="29063"; mail-complaints-to="usenet@i2pn2.org"
View all headers
Let's say, you wanted to make an application which provides some web service on the surface, while secretly giving shell access to the box on which it runs.
The application is in a scripted language like php, python or node, and of course you would not want your victims (the ones that install your application) to find out about it.
I guess the big challenge in this scenario would be to hide or obfuscate the part of the code that provides the shell access. Ideas that come to mind are:

-encrypt the code as a string and decrypt it at runtime
-embed the code in some file like an impage or a pdf,  (possibly encrypted) and read it later from there
-use some obscure coding style in order to make the code less readable (possibly using obfuscators)

All of these approaches have their pros and cons, with the second one being the hardest to detect I think.
All of the options like plausible deniability, though.

So maybe the best thing would be to use a broken lib somewhere in the code (maybe statically linked).

How would you go about this ?

What's your

--
Posted on def2


Subject: Re: shellcode challenge
From: rslightuser
Newsgroups: rocksolid.shared.hacking
Organization: Rocksolid Light
Date: Mon, 31 Aug 2020 09:21 UTC
Path: i2pn2.org!rocksolid2!.POSTED.localhost!not-for-mail
From: rslightu...@rslight.i2p (rslightuser)
Newsgroups: rocksolid.shared.hacking
Subject: Re: shellcode challenge
Date: Mon, 31 Aug 2020 09:21:42 +0000
Organization: Rocksolid Light
Message-ID: <c37ba53cf2b9370d1849b7fb70d95c9b$1@dkzerogt6z6ybhcj.onion>
References: <ha.850.2hb6u0@anon.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: novabbs.org; posting-account="retrobbs1"; posting-host="localhost:127.0.0.1";
logging-data="365"; mail-complaints-to="usenet@novabbs.org"
User-Agent: Rocksolid Light (news.novabbs.com/getrslight)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on novabbs.org
X-Spam-Level: **
X-Rslight-Site: $2y$10$CgrnhvRFhHPuIQlE9hjabe4XQ7Bojk4uiZp0S5bNVB8mnCTaXSirW
View all headers
Anonymous wrote:

Let's say, you wanted to make an application which provides some web service on the surface, while secretly giving shell access to the box on which it runs.
The application is in a scripted language like php, python or node, and of course you would not want your victims (the ones that install your application) to find out about it.
I guess the big challenge in this scenario would be to hide or obfuscate the part of the code that provides the shell access. Ideas that come to mind are:

-encrypt the code as a string and decrypt it at runtime
-embed the code in some file like an impage or a pdf,  (possibly encrypted) and read it later from there
-use some obscure coding style in order to make the code less readable (possibly using obfuscators)

All of these approaches have their pros and cons, with the second one being the hardest to detect I think.
All of the options like plausible deniability, though.

Maybe leave some debug code in when releasing code. Something that gives the dev shell access, but should not be enabled in release or should have been removed. You forgot to remove it.
So maybe the best thing would be to use a broken lib somewhere in the code (maybe statically linked).

I guess that's how government agencies get a lot of stuff done. Exploit bugs in libs.



--
Posted on: Rocksolid Light
dkzerogt6z6ybhcj.onion


Subject: Re: shellcode challenge
From: Anonymous
Newsgroups: rocksolid.shared.hacking
Organization: def2
Date: Mon, 31 Aug 2020 14:15 UTC
Path: i2pn2.org!.POSTED!not-for-mail
From: pos...@anon.com (Anonymous)
Newsgroups: rocksolid.shared.hacking
Subject: Re: shellcode challenge
Date: Mon, 31 Aug 2020 07:15:22 -0700
Organization: def2
Message-ID: <ha.852.4ao9xd@anon.com>
References: <ha.850.2hb6u0@anon.com>
Content-Type: text/plain; charset=UTF-8
Injection-Info: i2pn2.org; posting-account="def2";
logging-data="28927"; mail-complaints-to="usenet@i2pn2.org"
View all headers
Maybe leave some debug code in when releasing code.

I think that is a classic as well. Pretty much like a hardcoded default password. Gives you maximum deniability, but easier to detect.

I guess that's how government agencies get a lot of stuff done. Exploit bugs in libs.

That option should be the optimum between deniability and secrecy.

--
Posted on def2


1
rocksolid light 0.6.7
clearnet i2p tor