This is a thread dedicated to research of North Korea's operating system, Red Star OS, and general research about North Korea's technology and network infrastructure.
>Red Star download
archiveos.org
>Watermarking
Red Star apparently uses watermarking, and scanning as well, supposedly in the following binaries:
- opprc
- scnprc
- rtscan.ko
>/usr/bin/opprc
One of these files can be downloaded at:
github.com
/bket/ - Best Korea exploration thread
Owen Brooks
Other urls found in this thread:
sizeof.cat
github.com
cia.gov
sizeof.cat
github.com
twitter.com
Daniel Foster
>antivirus on a linux
yea this distro is a joke. no one wonder why it's fedora based. because they work for communists and red hat is pozzed
Luke Miller
I found an interesting function in opprc binary, by the way. It seems like when Red Star detects an unapproved CD it will eject it and reboot the system
Joshua Jones
sizeof.cat
I hope you are ok, user.
"The system is absolutely network-silent except when you actively do something that requires network access, like using the browser. It does not call the mothership, not for updates, not for telemetry, not to let Kim Jong Un know the status of your internal organs. Spoiler, he doesn’t give a fuck about your hentai porn. You’re not trusting me? Well, you should, because if you listened and installed the OS inside a VM, you can now mitm/firewall the external connections and notice the absolute silence."
James Brooks
how can we help koreans with censorship? i read somewhere they smuggle media players from china that lets you play everything without watermarking from thumb drives. most koreans were still on windows xp, and because of this red star fiasco pozware, most koreans will think of linux as evil oppressive os, when in reality running linux should put you on equal footing with the censors since they use linux too for firewalling (ie gfwc)
David Flores
Apparently it checks all of the files on a CD for a specific pattern. But for some reason decompiling C++ classes does not work for me, so I cannot seem to delve deeper
Carter Moore
Can you upload the binary somewhere?
Sebastian Kelly
>github.com
It's the opprc, link is in the original post.
I have also got my hands on the other binaries and if you can suggest me a service which doesn't require registration, I will upload that too
Samuel Rivera
I used ghidra, but since it is literally made by glowies, you might not want to use it yourself.
Boomerang or IDA pro should work too
Mason Wright
It appears that file watermarking information is stored as some sort of global variable. Might be worth looking into this.
If we crack their watermarking system, the files on CD drives and others could be pre watermarked by someone else and Red Star shouldn't notice. However, there appears to be a newer version of it, Red Star 4 (the one we have is 3). 4 may have different watermarking system. But at the very least, south koreans and chinese will put much less people in jeopardy when they smuggle information into NK
Carson Martinez
how likely is it that some Nork blessed by holy schizo revelations has neutered the OS controls with his own code, and/or users some other OS on a flashdrive?
Isaac Parker
Does somebody know what in_GS_OFFSET is?
Nolan Diaz
An insight into the DPRK internet/intranet.
sizeof.cat
Eli Rodriguez
%fs and %gs are segmentation registers in x86, which x86_64 doesnt use, so thread-local and kernel information is stored in them instead.
Robert Lewis
I am now trying to understand the SetWatermarkingData function
bool SetWatermarkingData(void)
{
int iVar1;
undefined4 *puVar2;
int in_GS_OFFSET;
undefined4 local_114 [4];
undefined4 local_104;
undefined4 local_100;
int local_10;
local_10 = *(int *)(in_GS_OFFSET + 0x14);
puVar2 = local_114;
for (iVar1 = 0x41; iVar1 != 0; iVar1 = iVar1 + -1) {
*puVar2 = 0;
puVar2 = puVar2 + 1;
}
local_114[0] = 0x7273752f;
local_114[1] = 0x62696c2f;
local_114[2] = 0x6475412f;
local_114[3] = 0x69536f69;
local_104 = 0x6c616e67;
local_100 = 0x7461642e;
iVar1 = access((char *)local_114,0);
if (local_10 == *(int *)(in_GS_OFFSET + 0x14)) {
return iVar1 == 0;
}
/* WARNING: Subroutine does not return */
__stack_chk_fail();
}
Is the decompilation output. I assumed that local_104 and local_100 follow local_114 and I got the following
bool SetWatermarkingData()
{
const char* fname = "/usr/lib/AudioSignal.dat";
return access(fname, 0) == 0;
}
However what I don't get is why the original for loop overwrites so much data with zeroes. The loop occurs 65 times, and the pointer is probably an int*, so it overwrites 65*4 bytes of data with zeroes, much more than needed for "/usr/lib/AudioSignal.dat". Perhaps I am missing something?
Juan Parker
There is some interesting stuff in the binary ...
Eli Perez
Here is a script for interacting with the /dev/res device
github.com
Wyatt Thompson
I doubt many in the west use red star
Jack Thompson
>Perhaps I am missing something?
IDA/hex-rays changes that for loop to just
>memset(name, 0, sizeof(name));
so probably nothing too important about that
IMO hex-rays is usually a lot easier to understand than ghidra output, you might want to get hold of that, the leaked IDA 7.7sp1 contains it
Jordan Torres