Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
mamot.fr is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mamot.fr est un serveur Mastodon francophone, géré par La Quadrature du Net.

Administered by:

Server stats:

3.2K
active users

mamot.fr: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.4

#syscall

0 posts0 participants0 posts today
cryptax<p>Decai decompiling a malicious shellcode. <br>The instructions are not so readable, if you're not used to syscalls int 0x80. AI does it for you.</p><p><a href="https://asciinema.org/a/4PY8wn2TPg2oBdDQ0Q5bgMYjk" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">asciinema.org/a/4PY8wn2TPg2oBd</span><span class="invisible">DQ0Q5bgMYjk</span></a></p><p><a href="https://mastodon.social/tags/r2ai" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>r2ai</span></a> <a href="https://mastodon.social/tags/decai" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>decai</span></a> <a href="https://mastodon.social/tags/r2" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>r2</span></a> <a href="https://mastodon.social/tags/malware" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>malware</span></a> <a href="https://mastodon.social/tags/shellcode" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>shellcode</span></a> <a href="https://mastodon.social/tags/syscall" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>syscall</span></a> <a href="https://mastodon.social/tags/linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>linux</span></a></p>
Felix Palmen :freebsd: :c64:<p><span class="h-card" translate="no"><a href="https://freeradical.zone/@ax6761" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>ax6761</span></a></span> Well, you could call it an implementation glitch. <a href="https://mastodon.bsd.cafe/tags/uname" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>uname</span></a> is *meant* to give you information about "the OS", but has always been implemented as a <a href="https://mastodon.bsd.cafe/tags/syscall" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>syscall</span></a>, therefore actually telling you something about the <a href="https://mastodon.bsd.cafe/tags/kernel" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>kernel</span></a>.</p><p>In <a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>FreeBSD</span></a>, the kernel doesn't *have* to be the exact same version as the userland, and for security updates, a new kernel is only built when some patch actually affects the kernel.</p><p>Note that on a <a href="https://mastodon.bsd.cafe/tags/Linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Linux</span></a> system, it's arguably even "worse", as Linux is nothing but the kernel. TO know version information about the rest of your installed OS, you'll have to use distribution specific information (or more recently look at the now standardized /etc/osrelease).</p>
cryptax<p>I'm surprised at how badly <a href="https://mastodon.social/tags/Ghidra" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Ghidra</span></a> decompiles this very simple function.</p><p>It's a syscall 0x57 which is unlink (remove a file).</p><p>I'm surprised it decompiles saying it *returns 0x57* ...</p><p><a href="https://mastodon.social/tags/decompiler" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>decompiler</span></a> <a href="https://mastodon.social/tags/syscall" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>syscall</span></a> <a href="https://mastodon.social/tags/linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>linux</span></a></p>
hubertf<p>On thread vs. process permissions</p><p>In common Unix and POSIX systems, all threads in a process are supposed to have the same permission. So why does the vortex8 program work as exploited, where one thread sets different permissions than another one using setresuid/setresgid?</p><p>Reference: <a href="https://man7.org/linux/man-pages/man2/setresuid.2.html" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">man7.org/linux/man-pages/man2/</span><span class="invisible">setresuid.2.html</span></a></p><p>Answer in thread.</p><p><a href="https://mastodon.social/tags/ctf" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>ctf</span></a> <a href="https://mastodon.social/tags/cybersecurity" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>cybersecurity</span></a> <a href="https://mastodon.social/tags/posix" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>posix</span></a> <a href="https://mastodon.social/tags/linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>linux</span></a> <a href="https://mastodon.social/tags/glibc" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>glibc</span></a> <a href="https://mastodon.social/tags/syscall" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>syscall</span></a> <a href="https://mastodon.social/tags/overthewire" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>overthewire</span></a> <a href="https://mastodon.social/tags/vortex" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>vortex</span></a></p>
Some Bits: Nelson's Linkblog<p>Stratoshark: Computer debugging tool: like wireshark, but for system calls instead of network packets<br><a href="https://stratoshark.org/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">stratoshark.org/</span><span class="invisible"></span></a><br> <a href="https://tech.lgbt/tags/via" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>via</span></a>:hackernews <a href="https://tech.lgbt/tags/wireshark" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>wireshark</span></a> <a href="https://tech.lgbt/tags/debugging" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>debugging</span></a> <a href="https://tech.lgbt/tags/syscall" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>syscall</span></a> <a href="https://tech.lgbt/tags/strace" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>strace</span></a> <a href="https://tech.lgbt/tags/devops" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>devops</span></a> <a href="https://tech.lgbt/tags/linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>linux</span></a> #+</p>
HoldMyType<p>when you say you cannot use kernel services or any system call for that matter because <a href="https://mathstodon.xyz/tags/Syscall" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Syscall</span></a> instruction is prohibited inside the enclave. The OS is not a part of the trusted computing base(TCB) in <a href="https://mathstodon.xyz/tags/SGX" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>SGX</span></a>. lets assume that syscall was enabled inside the enclave and you write instructions in assembly to execute the syscall instruction(lets say with parameters for the open system call sys_open). When you do a syscall you jump to the predefined location setup by the kernel during boot to start executing kernel code. What this means is you are jumping from code written by you(which is trusted) to code which is not written by you(OS, which is untrusted and is not a part of your TCB). If you were able to do this, it would defeat the security guarantees provided by SGX. Since the kernel/OS/any other software not written by you is untrusted, you could have a malicious kernel whose open system call reads data inside your enclave and steal your secrets.<br><a href="https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">en.wikipedia.org/wiki/Spectre_</span><span class="invisible">(security_vulnerability)</span></a><br><a href="https://stackoverflow.com/questions/28114746/what-does-it-implies-to-disable-syscall-in-intel-sgx" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">stackoverflow.com/questions/28</span><span class="invisible">114746/what-does-it-implies-to-disable-syscall-in-intel-sgx</span></a></p>
ExploreLive feeds
About