!!DO NOT USE SHARTY!!
https://desuarchive.org/_/search/text/integrity.wasm/
tl;dr sharty runs aggressive malware that attempts to gain remote access to your network and tries to get your discord info if you have it open while visiting the site
i figure most of you guys arent active posters on sharty but if you even visited there once i would recommend you change your passwords and such
inwent on it dour days agonamd my pc is slowed down now
So for those of us who aren't in i/tttt/, if it basically installs a keylogger, how do you get that out of your system?
>>349095
>went on sharty and my internet went down
F
>>350311
im not super tech literate but i think the script is executed serverside. as in, its not actually on your computer but while you're on the site it will do what it wants
>>351752
if it was able to gain access though they would theoretically be able to install a RAT on your computer and scrape locally
i could be talking out of my ass tho i never took a class or anything for this stuff
>>34909 ➡
if i opened it in mobile browsing i'm probably fine right, all that scrapes is browser cookies?
uh, users are anonymized the same way here as on 4chan right?
don't want sharty somehow getting every user of this site that would be not great
>>349095
At least use the Tor Browser. AFAIK Sharty just portscans your IP for services
>>349095
this is not possible. this would be a major hole in the web browser's security and a huge deal. they can fingerprint you sure , but like ... so can every other site ?
>>351770
how could it install anything unless you downloaded something
the sharty code, which was posted on june 2024 (integrity.wasm) does three major things:
<tries to detect discord running on the client machine and tries to detect tuxler running on the client machine
<sends that information back to the server via websocket traffic
<opens up staging for arbitrary javascript code execution
the script itself isn't /necessarily/ malicious on it's own but could very well be used to target specific users and run arbitrary code
this decompilation was from 2024 so who knows what they've done with it at this point. they could do all of this with javascript and the only thing i can think of that would inspire them to do this with wasm instead is a naive 'vibe' of obfuscation.
>>351752
you are incorrect, it is wasm (webassembly) and is run by your browser
>>351770
if they were able to escape the browser sandbox and run arbitrary code then they'd have bigger fish to fry, probably
that kind of exploit would be worth a LOT OF MONEY and would be absolutely wasted on sharty posters
there's always the chance that it's a honeypot but people who run that sort of thing are usually more competent i feel
all that being said, the code that is posted in OP is not malicious by itself but is a really obvious attack vector that was suspiciously obscured
tl;dr you're likely fine but i sure wouldn't visit the place
>>360163
I thought of something but then realized the hacker was probably not sharty staff so nvm. I thought maybe it was an attempt to get the discord of one of the 4chan moderators since I remember they use discord for comms.
>>360158
yeah just a user i think. sharty had this scanning over a year ago
>>360163
oh cool our posts made a quote loop
#trve
watch THIS >>360181
>>360181
hell yeah
you can quote your own post to hug yourself >>360184 #hug
>>360184
aw
>>352170
>no guys we're just running this XSS attack on your host because uhh the trannies
>>352170 the code is like a "Trojan horse" — it's technically limited by the browser's sandbox, but it's designed in a way that could allow for attacks from malicious actors.
>>360653
what kind of attacks, or how? is it either escaping or exploiting something about the sandbox, or not?
>>360386
>>360653
i really should be anonposting this and not trying to do an argument-from-self-authority but: no, that's not true. i despised soyjak.party et al. long before they started raiding my site all the time and despise them more now, but this is mostly hysteria
it absolutely is all for user tracking but claims of malware or opening the door for malware are untrue. worst case is maybe they're opening the door to someone else exploiting their own site/exploiting users when (and only when) they are browsing their own site (e.g., stealing your soyjak.party cookies; doing weird stuff when you visit the site) but there are no security implications or risks here for users' browsers/computers
the only real implications beyond the standard kind of tracking stuff you see from many sites is that they can know some applications you have running on your computer (discord and a VPN application). certainly a privacy breach but not a security breach
>>360870
and there are other privacy implications beyond what many or most sites do with their tracking but it's not accurate to consider it malware. you could consider it web spyware maybe, and somewhat device spyware (due to the local port scanning to see some things you might be running on your computer), but that's it
the ability to send arbitrary javascript for clients to run at any time does not indicate anything malicious in a device/browser security sense. any site could add<script>repeat every minute { fetch /stuff, append <script> tag to <head> with contents of /stuff }</script>
to their HTML and basically achieve the same effect as what's here. this could let a site owner do various things a user might not want, and do it in a targeted way to a specific user or groups of users, but the end effect is not anything worse than anything that could happen to you if you ever load any site with javascript enabled
>>360386
>no guys we're just running this XSS attack on your host because uhh the trannies
that's not what XSS is/means. nearly all discourse i have seen about this is from people pretending to know security things (and in some cases people intentionally trolling and baiting because they know it's dramatic and funny to make it seem like visiting a soyjak website will give you stuxnet)
tl;dr
- they are doing more invasive tracking than almost any other site you will ever encounter
- it isn't actually malware or a security threat whatsoever
- worst privacy implication is they can know if you have discord open or a certain VPN application open (and in theory they might try to detect more applications in the future)
- there are other privacy implications but they're fairly common tracking techniques that will probably run if you visit your bank's website
>>360843
>>360870
The integrity wasm code is like a modular "Trojan horse".
It's not malicious as such, but its design makes it really easy to use for targeted attacks.
>WASM as a Dual Tool
It's more about being sneaky than being effective, but it's not 100% reliable.
>>361105
>>361156
Shasty code isn't "malicious" in and of itself, but there's potential for it to be used as a weapon. Its capabilities could be activated remotely to transform the browser into an attack tool. Using WASM seems like an attempt to avoid simple analysis, but it's not any more technically risky than what JS can do. The key is how it's used. If the server sends malicious payloads, the risk materializes.
You can use extensions like uBlock Origin to block untrusted WebSocket connections.
Try using browsers with strict isolation (like Firefox with privacy.resistFingerprinting).
Just so you're aware, you'll need to disable WebAssembly in security-critical configurations (even though it limits web functionality).
>>361105
how is it like a trojan horse? I'm not understanding this
>>361105
correct, the other sketchy angle here is WASM was used to attempt to obfuscate the logic (since you'd need to decompile/reverse engineer it to fully see what it can do), which is pretty rare to do for tracking code, i think. (unless i am unaware of recent developments.) of course it backfired and just 1) drew more attention to it, 2) made it seem more powerful/capable than it actually is (spooky system programming language in a compiled binary vs. JS), and 3) made it seem more like they really had something to hide
>>361135
any JS can turn your browser into an attack tool. if this sort of thing concerns you you really just need to use noscript or similar. the real story here is the invasive tracking, not that they can send JS to targeted clients to execute whenever they want. decent chance they're doing that as just another obfuscation measure (someone would need to record it live to grab the full tracking code), but there could be other reasons like maybe wanting to be able to troll certain users. it could be something sketchier but it can't do anything regular JS can't do on any site
that being said, real malware does basically follow all of these same patterns (among others), so i understand the initial paranoia. if it weren't extremely difficult to run actual on-device malware by visiting a website i wouldn't be surprised if they'd try that too
>>361135
they could just update their regular main.js (or whatever) on their site to start ddosing another site or redirect everyone to meatspin or whatever, or could make different users load different main.js files to make it only affect certain people. the dynamic loading here gives them more flexibility and does raise questions by making it clear they may want to do or are doing this sort of targeting, but without examples of code payloads it's tough to determine the overall intention
>>361371
Sharty's developers used WASM, which made their code more visible, drawing the attention of reversers and security experts.
Since WASM is binary, it can seem more dangerous than it actually is. For example, you could see a WASM module that only calculates hashes like a keylogger.
If they'd used JavaScript, the community would've checked the code pretty much right away. With WASM, they're always going to assume something's up, even when that might not be the case.
Modern browsers keep WASM/JS separate from the operating system. If someone wanted to do traditional malware (like ransomware), they'd need a critical (zero-day) vulnerability in the browser or plugins (like Flash, which is now obsolete).
>>361335
>>362685
that is so true, bestie
>>361371
hey admin, how do you think you can solve this issue? idk myself sorry but it seems like a big usability thing because it seems so common on this board that it's too easy to inadvertently start a post and claim an id + spot in the thread, potentially by using keys and mouse actions in areas or ways that you'd otherwise expect to be non-inputs and just for navigating
>>362737
I just figured out one obvious thing I should have realized sooner: on page load the input form loads later than other things and can start eating your keypresses as inputs for a post sort of out of time with the rest of the page loading and kind of catch you offguard if you're a keyboard-heavy user
could you make it somehow not grab your input to the post box when it shows up by default?
>>363003
hi
>>362737
it's intentional. blankposts automatically get hidden a few seconds after submitting and deleted within a minute or so. however someone who starts a post with no text and then leaves won't have their post submitted until the open post edit window (30 minutes) expires. and we don't delete blankposts if someone has quoted the post
possible options:
- do something so posts that are open and have had no text for N minutes get closed sooner than the 30 minute window
- delete blankposts even if they've been quoted
i kind of thought if someone is quoting it maybe it like makes more sense to keep it up since maybe it and its position in the thread could be relevant but i guess it's probably not worth it
>>362749
>could you make it somehow not grab your input to the post box when it shows up by default?
no, that's a core feature. i knew it would lead to many inadvertent starts of posts but i think it's worth it. someone should be able to open a thread and immediately start typing to reply, without any cursor movements/clicks or non-content keypresses
>>362737
>but it seems like a big usability thing because it seems so common on this board that it's too easy to inadvertently start a post and claim an id + spot in the thread, potentially by using keys and mouse actions in areas or ways that you'd otherwise expect to be non-inputs and just for navigating
it will definitely trip some people up the first time they visit the site, but after a bit of use i figure it shouldn't really be a problem
most people don't use like vim mode in their browser. if they're navigating it'd typically be with arrow keys or page up/down i think
please add lynx support
>>363058
I think for me it's a combination of my habit of using space and shift+space to navigate as an easy off-hand/one-hand action and the fact that the page opens at the bottom of the thread instead of the top like other imageboard - all my learned actions from two decades of using 4chan are kind of just not handled intuitively, and I know that's user specific but considering what you're emulating here at least stylistically... it's a nasty thing to have to switch between if users are concurrent with other sites/imageboards with their own quirks and conventions
>>363049
I can't argue with it on that basis if that's literally the desired effect but I find it obnoxious lol
>>363042
if you're committed to keeping it this way I think the handling of blankposts you have set up is fine, it's just their inadvertent creation
>>363155
i suppose we could add a user option to disable focusing of the reply form on page load. i kind of dislike cluttering the options menu though and i'm not sure how many people would use it
>>363176
that's fair, I think for better and/or worse that sort of has the knock on effect of reinforcing the chatroom vs traditional imageboard feel
>>363177
for non-live boards (users can create non-live boards on our site) you have to click reply to see the reply form at least. and maybe we could not scroll to the bottom for threads in non-live boards when the page loads
>>363178
if that doesn't go against what you're envisioning or break shit I think it'd be more welcoming to any chan users
>>363180
this makes sense
>>363179
well it's fine, we want to give users the option to create a board and configure it as non-live. i want to maintain the current behavior for live boards but i want to make non-live boards as similar as possible to 4chan
>>363179
you can test a non-live thread in >>>/classic/
well i guess one issue is we do still default to the last 200 posts for non-live threads so starting at the top is debatable
we have a paginated mode as well but it's read-only at the moment
>tries to detect discord running on the client machine and
>tries to detect discord running on the client machine and
cant start newline on mobile... anyway this is impossible to do because browsers are sandboxed and you cant even detect whats open in another tab because of the same origin policy, this whole thread is retarded
>>363465
there is a setting that toggles if you want to newline or not with Enter
where
>>363465
Did you not look at the decompilation?
>>363479
what does that change, did they actually find this major of a flaw in the browser that they can acces your computer? that would be huge
should be multiple papers written at this point
>>363482
The wasm code simply attempts to create a websocket connection to the local discord
int main() {
Discord Detection
EmscriptenWebSocketCreateAttributes attr;
emscripten_websocket_init_create_attributes(&attr);
Discord's RPC can run on ports 6463-6472, but this check is only for the default.
https://github.com/discord/discord-api-docs/blob/main/docs/topics/RPC.md
attr.url = "ws://127.0.0.1:6463/?v=1";
discord_check_start_time = (uint64_t) emscripten_get_now();
EMSCRIPTEN_WEBSOCKET_T discordSocket = emscripten_websocket_new(&attr);
emscripten_websocket_set_onopen_callback(discordSocket, NULL, discord_ws_open);
emscripten_websocket_set_onerror_callback(discordSocket, NULL, discord_ws_error);
discord rpc service
it doesn't access anything but presumably just checks if the connection is made / attempted or rejected
>>363491
It uses the errors produced and the timing of the errors to make a guess on if discord is running or not
>>363485
https://incolumitas.com/2021/01/10/browser-based-port-scanning/
here's a relevant paper
>>363522
this is smart but still it doesnt do much, the port could be open and used by some other program, you cant even reliably tell if its discord and even if you can they need to find another major flaw to do anything with it because it just wont let you do anything else other than measure error response times
>>363540
this is just a guess but I don't think it needs to be 100% precise
it's sharty nonsense
it's probably not mission critical for them to know if someone is using discord
i would guess it does a decent job considering the endpoint is somewhat specific (?v=1 param)
idk, it's probably not important either way but it is doing what it says on the box
>>363540
especially for their audience, i think most of the time port 6463 listening means discord is running. 6463 is uncommon enough i'd guess it means it 99.9% of the time
even if the accuracy rate were way lower it'd still be worth it for them (since they're just looking for indicators as justification to exclude/limit/block people and probably don't care that much about false positives)
i don't know too much about the current state of localhost port scanning from browsers or if browsers have patched things to make it more difficult/impossible. there were definitely ways to do it ~5 years ago. the soyjak WASM code (https://pastebin.com/NTChvPPB) suggests tuxler will accept the connection if it's running, and if discord is running it will take at least 100 ms to respond with an error. don't know if those are reliable
I think the sharty was pretty open about running anti-discord shit