Let's not jump to conclusions. What is more likely? That this is generating test data for a forensics tool, or that this is planting child porn on a dissident's computer (with fixed file names and directories)?
I think it is rather cheeky (and dangerous) to accuse companies of doing such horrible stuff, when all we have is a few leaks (without context) to go on.
See for instance: https://github.com/hackedteam/rcs-common/blob/master/lib/rcs... which generates test keystrokes, test users and test programs for chat. The file names of the "planted" evidence is far too obvious, and they generate a hash for it. In short there is nothing in this code that implies this is used to plant evidence.
I think it is a bit ironic that some seem to have no qualms accusing a company of creating fake child porn accusations. It follows the exact same reasoning for planting evidence: How would child porn be beyond the pale for a dissident?
Even if they have a terrible track record, this code implies nothing that they are currently accused of. It is not like the code is heavily obfuscated or missing other parts. Let's not forget these leaks were "planted" too and we have no idea about its integrity.
Yeah, I think it's the responsibility of the user to bring his own child porn to plant on his victim's computer.
Any tool you can use to upload files on a remote system can be used for that. Hacking Team's tools certainly allow that but I very much doubt they have a tool specialized for planting child porn/evidence on a computer.
But then... we're so used of seeing child porn used as a straw man to increase surveillance that's it's pretty fun to see it used against one of the companies making tools to help with said surveillance. Even if it's wrong.
Most anyone interested in this story immediately jumped on the code thinking it was inserting files. Then a few software engineers took a look at the code and realize the file names were pretty much jokes. Now, everyone thinks it a joke that the tool inserts such material, when in reality it allows any user to insert any file they have, so the government (who has a collection of illegal files) can still use this to frame someone but any outrage over it has been dissipated.
I'm not saying it was intended to happen like this but it is sad it did.
Looking at the code, it's clear the strings are merely tests, and not used when a proper string is defined. However, the fact that their tests and examples use these strings, makes it clear what they thought a good application of their product was.
Assuming this was created with malicious intent (however unlikely), the motive would not be to plant false evidence but rather to create an excuse for probable cause (search and seizure). It would give law enforcement a legitimate reason to hold you and search your devices.
This is a pretty common ruby pattern to provide a default value if none was passed. I would consider this more of a "lorem ipsum" or crappy test fixture than a smoking gun.
I never did any Ruby but what I understands from it is that it take the process argument (if null, it take one at random from that array, seems like default values to test, bad idea but nothing that seems to be their only purpose as that argument is way more useful), it then take path argument (again same stuff with possible default values), the size argument (again but 123456789 as default) and write all that into a string including the current timestamp, which I guess is then added to a file.
As far as I know, there's no standard way to serialize browser history and I doubt it would contains the process and the size of the file.
There's another method that do that in reverse, I guess to then parse that same string.
If I had a guess, I would say that this the part that serialize/deserialize log information from evidence gathering (the actual gathering would happen elsewhere, which I can't find right now, and would call that module to serialize it).
You can find the actual evidence gathering on the clients like in this file, where it's also enriched with metadata and encoded the same way the ruby script does (at least to me, not a c++ programmer, it seems to be the case).
https://github.com/hackedteam/soldier-win/blob/master/Soldie...
Also, while there are plenty of functions for getting data from the target device like `URL_GetBrowserHistory` there are as far i can tell, no obvious equivalents for putting them.
Not directly related to the topic, but after skimming through the readmes of the various exploits HT used, it seems to me, that they rely heavily on social engineering and rather amateurish mistakes done by the targets (opening fake news sites, download and open documents and apps, etc.) as well as certain assumptions about the system like flash beeing active, unchanged default passwords on jailbreaked iphones …
While no doubt, this works very well for industrial espionage and probably against journalists, I have a hard time believing, that it works well against actual criminals who must expect beeing targeted all the time. Or am I overestimating the tech savviness of modern criminals?
All assuming the agencies are not messing heavily with the whole network at the same time, which i think is pretty dependent on the country it is used in.
The RCS software from Hacking Team is basically a Remote Access Trojan, right? As it says in the description:
"It is a tool for taking control of the endpoints, that is, the PCs" [0]
So they already have control over the system and are probably able to down- and upload whatever they want.
Isn't that a feature in all the "Lawful Intercept" tools? The only assurance that they don't upload incriminating stuff is their word. Or is the CP code snippet such a strong trigger?
Hacking Team has a horrid history of not keeping their word, the Sudan connection for example they explicitly denied, among others. I don't get the shitstorm for the CP strings, even after a cursory look at the files uploaded there is quite a lot of stuff I'm more concerned about :d
It's hard to write titles under the char limit, but the just of it is that the code appears to edit a user's browser history to include child porn and bomb blueprints, or something to that effect. It then edits the date and time to place it back in time.
If this code is ever verified, it seems like it could turn the verdict on some CP cases.
Note that you can press "y" after clicking a line to expand the link. This just includes the commit hash so that if this file is modified in the future the link will still point to the same place.
Pressing 'y' on github will cause "master" to be expanded to the current hash so that the link becomes a perma-link to that line of that commit, rather than that line of whatever-is-the-latest commit.
It's trivial to convince the judge and jury that the history is real. Who are they more likely to believe, the investigators or the guy in the orange jumpsuit that swears it was planted? After all, the "it was planted!" excuse is the oldest one in the book.
In US criminal cases, defendants are presumed innocent, and prosecutors must prove guilt "beyond a reasonable doubt". So defendants don't need to prove anything. They just need to invalidate prosecutors' evidence. But defendants are often toast if they lose the expert witness credibility contest.
On the other hand, the prosecution might overlook history because it's in Firefox instead of IE[1]. It's kind of tangential to this subthread, but to tie it back somewhat, that article notes that some browser history entries came up in court, and this bungling doesn't reflect well on the competence and credibility of computer expert witnesses.
I think it is rather cheeky (and dangerous) to accuse companies of doing such horrible stuff, when all we have is a few leaks (without context) to go on.
See for instance: https://github.com/hackedteam/rcs-common/blob/master/lib/rcs... which generates test keystrokes, test users and test programs for chat. The file names of the "planted" evidence is far too obvious, and they generate a hash for it. In short there is nothing in this code that implies this is used to plant evidence.