cyb - cyberpunk

>>18996
I've been examining the function you posted.

That long string looks like base64 encoding, but it's not the standard charset. The first while loop's if / else block reveals the encoding type.

48 to 57 = '0'..'9' = value 0 to 9
97 to 122 = 'a'..'z' = value 10 to 35
65 to 90 = 'A'..'Z' = value 36 to 61
45 = '-' = 62
95 = '_' = 63
The function will ignore any chars other than the charset:
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ-_
Which means you can freely put line breaks in. The decoding algorithm uses no padding chars.

If I had to guess, the set of characters may be selected to avoid normal Base 64 chars such as '+', '=' and '/' which are invalid in filenames or URLs. This means this Base 64 encoding could be used directly in a URL's parameter string without escaping the '=', or in a file name without directory separators. I've run into problems using Base64 encoding in URLs and filenames and have used a similar solution (different charset). However, I usually use the browser or API base 64 decoding function, then do .replace() on the strings to transliterate the offending chars into safer chars.

It seems the browser built in base 64 decoding wasn't used due to the next part: The values are decoded not into a string but first into an intermediary array of 32 bit integers.

The b var accumulates the 6 bit value (0-63) from v up to 32 bits, then these packed 32 bit values fill the d array.

Next, the r(w) function returns a variable number of bits (w) from the d array.

The next while loop uses r() to construct the text string.

This sounds like a convoluted way to do it, but note that the while loop is calling "r(7)" so it's reading 7 bits at a time, not 8 -- so, the resulting text is only in ASCII range (char 0 to 127). This results in a smaller encoded size than regular Base64 encoded 8 bit bytes.

Now things get interesting: If the output char value v is less than 32 (space) then it's used as a type of control character (0 to 31). For each control code, 10 more bits are read in (0 to 1023). Then starting from three chars from the end of the string, between 3 to 34 chars are copied and appended to the output string.

The effect is a "sliding window" decompression algorithm designed explicitly for ASCII source code. It doesn't seem suited for ordinary ASCII text since whitespace is limited to only spaces, no tabs or returns. Within the previous output 1026 chars, any string of duplicate text of up to 34 chars in length can be compressed down to 17 bits. I couldn't find this compression encoding on the web, so it's probably custom.

The input data is 44570 chars.
The output data is 84916 chars of code (which is passed to eval()). Accounting for the constant 639 chars of decompression code, the code is compressed to 53% of its original size. Not bad. However, this ratio misleading because of the final base 64 encoding required to store the data as text.

Without base64 encoding, i.e., if the storage format was binary rather than in a string (if you could read/write d[] to/from disk directly), and if the decompression code didn't have to accompany the data (say it already existed in the client or a library, then the code would have been compressed to 39% of the original size.

That's pretty good considering how simple the code is and that there's no Huffman encoding in use.

>>19511
you're doing it wrong. replace "evaluate" with "console.log" and you get this: http://pastebin.com/temSPGSe

>>19517
> doing it wrong
Doing what wrong?

I already did what you suggest. That's exactly how I determined the length of the evaluated code. I wanted to understand the encoding used... So, didn't I do that right?

>>19525
Fuck curiosity, right?

>>19511
>>19066
>Any ideas about the area around <0x4e50>?
Not sure, looks like program code.

There seem to be some interesting stuff at these offsets:
0x07400 - locks up when some are changed.
0x0d400 - some appear read only?
0x2d400 - ?

>>19529
Some are read only because that's either the controller code or screen memory. Those values get overwritten with the proper value because they're updated or necessary for function. 2d400 is temp storage I believe. After getting through some of the later clues you'll see those higher values change to text, because the clues are loaded from there.

Could alternatively be read only code that's been tagged by someone who got ring 0.

>>19529
After looking at 0x2d400, it looks like it either has to do with screen scrolling or how the memory addresses are written on the right. Messing with those numbers can really mess up your view. Oddly enough I think that's a location I was hoping to manipulate to read 0xFFFFFFFF or whatever the highest values are. Bet there's some fun stuff down there.

>>19511

Neat. Whoever did this was either dedicated or crazy, probably both.

>>19531
There's no memory protection in the VM at all, as far as I can see. Since the VM batches cycles (VM manager runs 32768 cycles at a time), there's no good way to implement it in the VM management code without being vulnerable to TOCTOU races.

>>19526
>>19525
ah sorry. i take it back, your post is actually neat now that i've read it.
picture depicts how curiosity is one of the things you cant fuarrrk

>>19575
>or crazy, probably both.
I'm not so sure myself. Considering what's public info, declassified government docs, patents, etc. like vid related:
https://www.youtube.com/watch?v=mc-dH3Tl7oo (microwave ray gun in LA County jail).

http://breakingdefense.com/2013/11/raytheon-non-lethal-heat-beam-tackles-new-missions/

Not saying there's he wasn't crazy, just that it's not my automatic assumption anymore given existing tech.

But I may be biased: I'm on a Cyberpunk image board, after all.

----
>>19529
> 0x07400 - locks up when some are changed.

This appears to be the function call stack. The instruction pointer is pushed here along with the rParam register on opcode 0x19 (visit()), then the IP is set to the specified address (like a jump), and these values seem to be restored on opcode 0x20 (the unnamed return code).

My thoughts on Function Call semantics ahead:

Instruction 0x19 is odd. The "dest" "slot" value byte of the 32bit instruction (bits 16 to 23) contains a value that's added to the rParam register. The bits are shifted down 14 instead of 16, and masked off to 0x3Fc. Thus the 8 bit value is effectively multiplied by 4 before adding it to rParam.

The values at 0x7400 don't contain a normal function stack like a x86 CDECL, as there is no parameter data that gets pushed onto the call stack. Maybe one of the other offsets mentioned. I'm still trying to figure out exactly how you pass parameters between functions, but it seems like they may be purely passed via registers and global vars.

The base value of the registers in memory can shift up on a function call, but can't be modified normally afterwards. The offset is unsigned, and modification of rParam throws NOPERM. So, a visit()ed function can't read register values below what the caller offsets to.

That means there's no need to push / pop the registers you want to save, since you can move the register base pointer beyond them. So offsetting by 4 means register value #0,1,2,3 are "protected" and your register #4 becomes register #0 in the called function.

One way to call a function could be as follows:
Figure out how many register values you need to save. Issue instruction 0x19 with the source data as the code offset to execute, and bits 16-23 set to the number of registers to save (which are 32 bit, so the multiplication by 4 works out). The called function won't be able to mess with your protected registers you offset beyond. When its done the called function issues instr 0x20, and continues operation.

Normally, you have caller clean up (the caller restores the stack frame), or callee clean up (the function is responsible for restoring the stack frame before returning).

This seems like the call / return VM instructions do the clean up automatically -- and there's nothing to clean up, since the functions are using their own private copy of the registers.

To pass a parameter to a function you could populate what will be its register 0, 1, 2 ... n, with the parameter values. To return a value you would put the data back in these registers? Hmm. Or, the caller can access all the registers the function was using when it returned, so the return value could be in any register so long as the callee knows which one its in (this could be encoded in a function signature).

Forgive the rambling, I'm just "thinking out loud" here.

I guess function call semantics are beyond the scope of an assembler, but the VM blurs this line since it prevents modification of the call stack outside the call/ret functionality.

Kind of cool that you don't have to push/pop registers to save them, but the calling code has to know how many registers it's protecting before calling a function (most compliers do already know that, however).

>>19580

Nice work. Have you seen >>19402?

I'm a little confused, though. Are you saying that rParam contains the base address of a set of memory-mapped function-specific 'registers'?

That's certainly what I suspect. Rather than storing data in registers, I expect the VM uses the registers to store base addresses, where:

rParam = Data (or Parameter) stack
rCall = Call stack
rHeap, rText, rEntity = Heap memory base addresses
rCode = Code base address

The data stack is accessible via the Indexed address mode, whilst the heaps are accessible by writing a pointer to the data stack and dereferencing it using the Complex address mode.

The data stack layout would then look something like this:

rParam+0x0    [ Parameter           ]
rParam+0x4    [ Parameter           ]
rParam+0x8    [ Local Variable      ]
rParam+0xC    [ Local Variable      ]

To call a function, you'd just write the parameters to the end of the local variable region and call VISIT with the appropriate offset, and write the return value to the parameter space on return:

Initial:

rParam+0x0    [ Parameter           ]
rParam+0x4    [ Parameter           ]
rParam+0x8    [ Local Variable      ]
rParam+0xC    [ Local Variable      ]
rParam+0x10   [ Callee Parameter    ]
rParam+0x14   [ Callee Parameter    ]
rParam+0x18   [ Callee Parameter    ]

rCode+ret-0x4 [ Previous rParam     ]
rCode+ret-0x0 [ Previous PC         ]

After VISIT 0x10:

rParam-0x08   [ ...                 ]
rParam-0x04   [ Local Variable      ]
rParam+0x00   [ Callee Parameter    ]
rParam+0x04   [ Callee Parameter    ]
rParam+0x08   [ Callee Parameter    ]

rCode+ret-0xC [ Previous rParam     ]
rCode+ret-0x8 [ Previous PC         ]
rCode+ret-0x4 [ Caller rParam       ]
rCode+ret-0x0 [ Caller PC           ]

After RET:

rParam+0x0    [ Parameter           ]
rParam+0x4    [ Parameter           ]
rParam+0x8    [ Local Variable      ]
rParam+0xC    [ Local Variable      ]
rParam+0x10   [ Callee Return Value ]
rParam+0x14   [ ...                 ]

rCode+ret-0x4 [ Previous rParam     ]
rCode+ret-0x0 [ Previous PC         ]

>>19580
>I'm a little confused, though. Are you saying that rParam contains the base address of a set of memory-mapped function-specific 'registers'?

Sorry, I was interchanging 'register' with what is labeled in as 'slot' in the source. But I think you're right though.

From the addition() function:

if (...) {
  // ... set base to another register
  base = (base + (_4[(rParam + slot) >> 2] >>> 0)) >>> 0;
}
else base = (rParam + slot) | 0;
switch ( size | 0 ){
  case 0:
    _1[base] = (_1[base] >>> 0) + v0;
    return;
  case 1:
    _2[base >> 1] = (_2[base >> 1] >>> 0) + v0;
    return;
  case 2:
    _4[base >> 2] = (_4[base >> 2] >>> 0) + v0;
    return;
  //...

In the above else condition 'base' is the same as rParam + slot. In the complex address mode rParam + slot is also used. The value stored at that rParam offset becomes a pointer offset from one of the other registers.

So the slot seem to be used to reference data that's offset from rParam (the local data / parameter register?)

As you demonstrate rParam shifts around during function calls.

The alignment of the data is interesting. Due to the shifts required by ASM.js / WebASM when accessing the typed heap aliases:

_1[index]
_2[index >> 1]
_4[index >> 2]

The 0 to 255 slot number access 256 byte positions for size 0 (8 bit), but accesses 128 positions for 16 bit, and 64 byte positions when the size is set to 32 bit: 0,4,8, etc.

So the slot is a byte offset, but with 32 bit mode selected a slot value of 0,1,2,3 all mean the same as 0. A function can only accept 256 bytes of "slot" parameters. I suppose an in-place visit() could be used to temporarily access more of the stack.

So, we discovered all this cool soykaf about the machine it runs on, but we have no idea how to advance past the red screen?

>>19650
Well, we basically have the instruction set decoded aside from a few minor details.

We have yet to decompile the program that the VM is running, or performed code coverage analysis to see if there's unexecuted bits in there. I started to do so manually, but we just need to write an assembler/disassembler first.

The confounding thing is the lack of features that sources hint at. IMO, the VM itself seems incomplete or a type of "springboard". I feel like we've been presented with part of a bootstrap process, but I haven't figured out exactly what that process is or what to work towards. Clearly it's at least a kind of "skill test", but I question what the skillset required says about where it may lead me.

I've seen hints on chans (pic related) and in some other... "darker" places I visit that a deep understanding of this VM and reverse engineering in general is required to access some greater system. I've also been cryptically warned not to "keep going" and to "stop thinking about it".

I've been examining the block of data following the "exe-me" opcode, as I think it "holds the key", so to speak. The meaning "execute me" seems sinister in the greater context. Hope I'm not crawling into a honeypot.

>>19682
Tell us of the darker places anon. I want to know.
>inb4 NSA

>>19682
>I've seen hints on chans (pic related) and in some other... "darker" places I visit...
Don't let it get to you, anon. It's nothing more than a fun game made up by a silly cryptography enthusiast.

>>19682

That screenshot is interesting for several reasons. Firstly, it has a scanline effect, which doesn't appear to be present on my system. Secondly, the code offset is different, though it doesn't seem to do anything new (just starts the skull prompt, same as the default). I'd think it was from an earlier version but the name suggests it was posted in 2015 and the current skullcode version is from 2014 (assuming it's versioned by timestamp, as it appears to be).

And of course there's the obvious red border and screen corruption.

>>19692
You can enable and disable scanlines man. Think it was posted earlier. If it wasn't posted here I believe I have it in a text file.

>>19736
Also, i've changed background color as it was also posted. So I'm not sure how the red background indicated he was in ring0 as was mentioned in the post that picture came from originally.

But I do agree with >>19682 there's more to this thing. I've thought what we've been presented is definitely a barrier to keep bots and skiddies out. As the creator mentioned something along those lines himself. It definitely seems there are accounts in some way, I'm not sure how you'd bootstrap into an account, but I assume they just have persistent VMs that they would somehow load up. It's all very curious.

Another clue was that that poster who claimed ring0 access said he left a tag in memory where users can't normally access, and I've seen no indication of such so I'd imagine there are definitely areas we aren't seeing.

I wouldn't worry about it being a honeypot, I'm sure it's just a game where some people smarter than me are having a good giggle.

Don't know if antone's posted this yet but I was able to make those ribbons going down from the skull extend with, I think d6:00 - d6:07 but I can't remember exactly what I did. It was a run of d(something) on 0-7 as the operands.

>>19682
Hell, as much as I want to believe it, I just can't. I don't think this guy would've been screwed up enough to actually make something more complex than what we already saw. The VM seems mostly unfinished and incapable of doing more complex operations.

For those who haven't seen it: http://project-retrograde.com/cipher/

I'm still gonna "keep going" as instructed, but I doubt the reward is gonna be something meaningful.

>>19753

Even if it's not 'real', it's still neat to pull apart. There's a lot of stuff that's not implemented or unused, like code to store/retrieve Javascript objects from local storage or the remote server. It's possible the author did intend to hide something here, but I'm not sure they succeeded.

I think this concept would work quite well for a lain-themed game, actually. Trapped in live-memory hex editor on an unknown machine with only scraps of datasheets in unallocated regions of memory to guide you, finding snippets of executable code that reveal hidden mem-mapped registers in unexpected places, getting caught in one-way bank-switches as the memory mapper maps itself out of memory, stumbling across hints of others lost in the machine, of a greater conspiracy, et cetera.

>>19767
Yeah, it's great, I'm not saying it's not. I just don't want to have high expectations to something that might not even be finished.

>>19767

>There's a lot of stuff that's not implemented or unused, like code to store/retrieve Javascript objects from local storage or the remote server.

And on that note: http://pastebin.com/h277TTFj

Of interest may be the unusual PRNG design and the apparently unused 3-tier 'AssetManager' class (in-memory cache, LocalStorage cache, remote server) for javascript objects.

The remaining obfuscated classes are probably the most interesting ones, since they implement the VM input and display devices and handle bootstrapping the VM.

>>19753
>For those who haven't seen it: http://project-retrograde.com/cipher/
Hmm. That color reminds me of:
>>19502
>What got me thinking down occult lines for hints (besides the "take it to /x/") is the words that the skull reveals.

What can I read to start understanding this? I'm really curious about this skullcode thing, but everything you are saying sound extremely complex. Where should I begin, just point me a direction /cyb/

>>19804
Depends on what you know at the moment. I assume you never had any experience with ROM hacking or something like that. I also assume you are able to convert numbers from base10 to base16 and know the Endianness theory. At least.
First learn something easy like coding in x86 assembly. Then start figuring out the hardware you run it on. osdev is full of tutorials on it and you can fire it up under a regular x86 virtual machine. Find yourself an x86 opcodes cheat sheet and always check you results with a hex editor. Figure out different addressing methods. Try writing something in pure machine, disassemble it and check the results. If you want to play with the OS-dependent object formats, you can look for the guy called Ange Albertini (I believe his site was called corkami). He has great papers on writing PEs for NT from scratch, as well as the ELFs.
After knowing what the hell is happening there, try reading documentations e.g. for the ARM processors. If you can understand what's going on there, then you could probably start reverse-engineering skullcode. You haven't learned the technique to do it, but you know the rules. And that's where the fun starts.

It's a lot of machine theory, not just logical thinking (like programming). And it's time-consuming. You decide if it's worth it.

>>19811
Wow, thank you so much for the reply
I only know the basics but I'm working on it
College ends next week so I'll have plenty of free time to study everything you said
Thanks

>>19812
No problem, mate. Good luck.

>>19811
> First learn something easy like coding in x86 assembly. Then start figuring out the hardware you run it on. osdev is full of tutorials on it and you can fire it up under a regular x86 virtual machine. Find yourself an x86 opcodes cheat sheet and always check you results with a hex editor.

Coincidental as hell. I was just doing some digging and found this:

http://skullcode.com/bootstrap/hexboot.txt
http://skullcode.com/bootstrap/hexboot.png
http://skullcode.com/bootstrap/hexboot.img

The same guy that made skullcode also made this bootable hex editor, which fits in less than 512 bytes (one boot sector). Pic related.

You can boot the image as a drive image in qemu or bochs, etc emulator. It lets you edit raw RAM and execute it, kind of like on skullcode.com.

I found /bootstrap/ via a script that brute force queries the server. Instead of 404 (not found) it gave a 403 (forbidden). So I started brute forcing file requests within that path.

I didn't see any other files in that directory yet, but they could have odd names. I only got up to files with two word combinations from the dictionary I use.

Be careful querying like mad, or the server will ban your IP. I Limit my requests to one every two seconds, and the scripts been running for a long while. Also, such brute forcing may be misconstrued as a violation of Computer Fraud and Abuse Act by the server host, as that's effectively a DoS attack similar to what the old "Low Orbit Ion Cannon" did.

There could be other files in there, but I might not find them since I'm using a small dictionary of very popular words.

Now, the weird thing is that hexboot.png and hexboot.txt didn't exist until I queried for hexboot.img in the /bootstrap/ directory.

The brute force tries for common extensions in order of popularity. It tries .HTML, .TXT, .PNG, etc. and .IMG was a low priority name. Once I get a hit on a name, my script calls another function that tries a bunch of extensions with the same name. I know for a fact that I sent a request for the "hexboot.txt" file, and got a 404. Then AFTER "hexboot.img" returned 200 (ok), "hexboot.txt" and "hexboot.png" showed up.

The last modified dates of the HTTP headers are as follows:

hexboot.img: 12/25/2015 6:31:11 PM UTC+0
hexboot.png: 12/25/2015 6:31:13 PM UTC+0
hexboot.txt: 12/25/2015 6:31:13 PM UTC+0

So the .png and .txt files were created two seconds after the .img file was. The .img file creation time corresponds to the same time my script requested the file - so it was created on request, and this triggered the other two files to also be created.

IMO, there's a daemon on the server looking for requests and copying files around or maybe all requests are routed through a script on the backend and they're being generated on the fly -- I don't think the latter is the case because the file downloads have "resume" support. Most dynamic scripts don't let you say: "Give me the file, starting at X bytes into the file".

A trigger setup for just the .img is the only explanation I can think of for why would it refuse to give me the .png and .txt source until after I had got the .img binary?

The idea that certain requests change files on the site is intriguing as hell. I don't see any changes to the other skullcode.com files, but I seem to remember someone in another thread maybe here or on /cyber/ mentioning that the site did change before, and somewhat recently.

>>19841
>Now, the weird thing is that hexboot.png and hexboot.txt didn't exist until I queried for hexboot.img in the /bootstrap/ directory.

>The brute force tries for common extensions in order of popularity. It tries .HTML, .TXT, .PNG, etc. and .IMG was a low priority name. Once I get a hit on a name, my script calls another function that tries a bunch of extensions with the same name. I know for a fact that I sent a request for the "hexboot.txt" file, and got a 404. Then AFTER "hexboot.img" returned 200 (ok), "hexboot.txt" and "hexboot.png" showed up.

>So the .png and .txt files were created two seconds after the .img file was. The .img file creation time corresponds to the same time my script requested the file - so it was created on request, and this triggered the other two files to also be created.

Holy soykaf. It just got more spooky. Great job, based anon.

>>19841
>A trigger setup for just the .img is the only explanation
A much simpler explanation is that you are the author: >>>/λ/9341

>>19853
https://archive.is/RedL9
Apparently, the last post of the Skullcoder was at 2015-09-26.

The post you linked to is from 2015-09-12.

He removed his name from the code posted on /λ/, but he kept it on his server along with the screenshot of it in action.

>>19858
>guy's personal site is http://vortexcortex.com/
>check the js code
>tim@codelobe.com

http://codelobe.com/

Guys, I really want off this ride...

>>19860
http://codelobe.com/lexicon/galactic-time.html

WHAT IS THIS THING
WHO IS TIMOTHY LANDERS

>>19860
friend. look at the javascript source.
the page source. look at it.
this does literally nothing. no matter what you put in.

>>19901
But why did he do this?

>>19860
> vortexcortex.com
pic related

>>19868
>WHAT IS THIS THING

Nice Clock Ahmed.

Maybe he's trying to get to The White House?

>>19812
http://popfilesxuru7lsr.onion/~unknw00n/Assembly.pdf

I think you might like it, as well as the others interested in this kind of thing.

>>19841
That exif.

Whelp, here goes nothing.

>>19841

What the hell? The ride never ends, it just keeps going.

>>19894
Pretty sure that's a different Tim.

>>20012
The quote doesn't appear anywhere I can find, and doesn't seem attributed to Ken Thompson.

> hack the Gibson
Obvious "Hackers" movie reference. The phrasing seems similar to "The Matrix" spoon bending scene meme.

> Ken Thompson
He's the original implementer of Unix.

> 1984
Not sure what this means, aside from Orwell's book.

>>20050
"Reflections on Trusting Trust" is from 1984.

>>19578

he wrote custom algorithm to decode actual js that is in variable 's'. after 's' is decoded it is then executed by eval().

deobfuscated and saved, will make for a good element of my homepage =*D.

I think it's also not worth the time, it allows only to bump into few errors and halt.