←back to thread

412 points xfeeefeee | 3 comments | | HN request time: 0.644s | source
Show context
godelski ◴[] No.43748662[source]
This seems like quite a lot of work to hide the code. What would the legitimate reasons for this be? Because it looks like it would make the program less optimized and more complexity just leads to more errors.

I understand the desire to make it harder for bots, but 1) it doesn't seem to be effective and bots seem to be going a very different route 2) there's got to be better ways that are more effective. It's not like you're going to stop clones through this because clones can replicate by just seeing how things work and reverse engineer blackbox style.

replies(8): >>43748681 #>>43748712 #>>43748741 #>>43748839 #>>43749167 #>>43749282 #>>43750130 #>>43752385 #
noduerme ◴[] No.43748712[source]
A generous take would be that they have their own internal GUI tools that make it easier for non-programmers to set up visual elements in this. That was historically the reason to invent VMs like Flash. A less generous take would account for the enormous potential for hiding nefarious code inside such a thing, and account for the nature of the government which deployed it, and conclude that it was a national security / defense project disguised as a candy-coated trojan horse.
replies(1): >>43748994 #
supriyo-biswas ◴[] No.43748994[source]
VM-based architectures are really common in the obfuscation space, which is why you have executable packers[1], JS packers[2] and bot management products[3][4] leveraging similar techniques.

As for why the obfuscation is needed: bot management products suffer from a fundamental weakness in that ultimately, all of them simply collect static data from the environment, therefore it would make much more sense to make the steps involved as difficult to reverse engineer as possible. Once that is done, all you need to do is slightly change the schematics of your script every few weeks and publish a new bundle, and you've got yourself a pretty unsubvertible* protection scheme.

Regarding the "trojan horse", I think someone is yet to show proof that it's a Javascript exploit.

(*Unsubvertible is obviously relative, but raising the cost the attack, from say, $0.01/1000 requests to $10/1000 requests would massively cut down on abuse.)

[1] https://vmpsoft.com/

[2] https://jscrambler.com/

[3] https://github.com/neuroradiology/InsideReCaptcha

[4] https://www.zenrows.com/blog/bypass-cloudflare#_qEu5MvVdnILJ...

replies(1): >>43750071 #
noduerme[dead post] ◴[] No.43750071[source]
[flagged]
1. saagarjha ◴[] No.43750164[source]
Amazing. Every word of what you said was wrong.
replies(1): >>43750267 #
2. noduerme ◴[] No.43750267[source]
Well, then correct me.
replies(1): >>43758816 #
3. saagarjha ◴[] No.43758816[source]
Your definition of VM diverges from the standard one. This is a VM:

> it has opcodes that you can write to in another higher-level "language"

VMs aren't just VirtualBox.

TikTok obfuscates their frontend because they fingerprint the device and send it to their server, likely as an anti-fraud thing. Generally these kinds of things will make it so that you can't treat the frontend as a black box and replay requests or do anything simple like that. For example, if they add an incrementing counter to each request and then encrypt it, and then they see you send the same request again, then they will flag you for doing something fishy. You'd only know what they were doing if you reverse engineered the frontend. This isn't security per se but it makes people have to reverse engineer the code to mimic genuine behavior, which is their goal.

As for TikTok being a cyberweapon: you're going to have to back up that claim. Obfuscating an app and then installing it on people's phones is not as clever an idea as you think it is.