| Welcome, Guest |
Welcome to Makestation! We are a creative arts/indie discussion community — Your center for creative arts discussion, unleashed!
Please note that you must log in to participate in discussions on the forum. If you do not have an account, you can create one here. We hope you enjoy the forum!
|
|
|
the forum is being flooded with spammers!
|
|
|
|
the forum is being flooded with spammers!
|
|
|
|
the forum is being flooded with spammers!
|
|
|
|
the forum is being flooded with spammers!
|
|
|
|
the forum is being flooded with spammers!
|
|
View all updates
|
| Online Users |
There are currently 456 online users.
» 0 Member(s) | 455 Guest(s)
Google
|
|
|
| Custom Video Switch |
|
Posted by: SpookyZalost - October 7th, 2019 at 2:52 AM - Forum: Technology & Hardware
- No Replies
|
 |
Hey, so I've been tossing this idea around for a while, and I'm getting closer and closer.
so my big issue is that for KVM's, component signal, etc, the actual switches are expensive and hard to come by unless you want to pay out the arse for them.
so I've been spending the last couple months researching a custom solution instead, based around a bus switch circuit IC.
effectively what this is, is a method to make a video (and possibly data switch with some tweaking), for less than $25.
to start with, there's articles online, however they're somewhat dated, and not ideal.
so building on the work of an old endgadget article going over a custom switch designed by the very well known ben heck, I've been busy studying what are called bus switch IC's.
effectively they can take a number of inputs and depending on if the pin is high or low can switch that many inputs on/off simultaneously.
the upside is that this makes things fairly easy, the down side though is there needs to be a circuit to prevent interference, effectively, if you turn one circuit to allow traffic through, the rest have to block it.
this might help explain it better.
![[Image: pByAPma.png]](https://i.imgur.com/pByAPma.png)
Effectively, when pin 20 is set to high, no signal get's through, however when pin 20 is set to low, A connects to B.
that's 8 signal lines, either in state 1 or state 0, on or off.
from there you simply route the signals to the output bus like so.
![[Image: bus_engadget_howto.jpg]](https://s.blogcdn.com/www.engadget.com/media/2007/02/bus_engadget_howto.jpg)
fairly simple right?
well this is a powered switch, it needs to be for it to work, so there's a bit of power circuitry going on.
**************************************************************************************************
I know unpowered switches exist, I have a few sitting around, so I decided to take one apart to see what's different.
![[Image: SCIq9Tf.jpg]](https://i.imgur.com/SCIq9Tf.jpg)
![[Image: 5mlxqAV.jpg]](https://i.imgur.com/5mlxqAV.jpg)
What's special about the video switch isn't the circuit, it's essentially the same, just traces going from the inputs to the output.
what's unique is the switching mechanism.
basically it breaks/Connects the traces mechanically, and there's a spring loaded setup across the middle that pushes the other switches to an off state when one is set to an on state (you can still hold down two switches simultaneously however but you'll get crappy signal if you do that because the two will compete.)
it's a mechanical version of the circuit I'm looking to create with the bus switches, and unfortunately this one appears to be a special component, one I can't get off the shelf...
it also actually degrades the signal slightly because of it's nature.
back to square 3...
******************************************************************
so here's the circuit in a nut shell, you tie your grounds together, rig a switch from the power input circuit to send 5v to the bus switches when set to off, and nothing when set to on (remember high = voltage, low = no voltage, it's kind of an inversion of common sense)
and you take your inputs, be they data, video, or audio, and you route them to the same output bus, with a bus switch in between the inputs and the output bus to switch them on/off.
it's simple and it works, I'll take pictures when I have a working prototype, the chips take more than a month to get here from china., but so far this is what I've worked out.
just one bus chip should support 2 USB ports, so I'd need to tie two chips together per switch to make a KVM switch with three separate output bus lines and three inputs per input, USB 1, USB2, Video/Audio.
it is possible to use a 16 bit bus switch, but they cost a lot more than 2 8 bit bus switches, still it's something I've been thinking about regarding the KVM variant.
|
|
|
| Optimization and You |
|
Posted by: Lain - September 24th, 2019 at 3:50 AM - Forum: Software
- Replies (6)
|
 |
If you aspire to do anything half-decent in programming, do yourself a favour and learn either C or Assembly properly. Not only will you learn about all the low-level intricacies of memory management, you'll also learn how to reinvent the wheel when you need to.
I've been learning assembly for quite some time now.
It's not a difficult language. Actually, it's insanely primitive. The difficulty stems from making something useful out of it, but generally, that's not a major issue if you have access to system calls or externally linked libraries.
So, while practicing my assembly skills, I tend to find simple challenged that could be a few small lines in C or whatever, and then I try to port them over to ASM.
I then remembered an 'interview' question I heard a while back to filter out all the braindeads that were applying to be some Malaysian dude's programmer.
The question is simple, and an astounding number of people couldn't solve it. Out of literally hundreds of applicants, only one guy was able to solve it. Sure, it says a lot about the quality of code overseas, but have a look at the question:
Quote:Count down from 700 by 13 until you reach 200 (DO NOT GO BELOW 200!)
That's it. No catch. Nothing weird. No need to try and find the primes in that list or anything.
Simple stuff.
So, back to my story. I decided to use this problem for my assembly challenges. At the same time, I figured it would be cool to have a quick test to see if ASM was significantly faster than C/C++, so I made a few programs to demonstrate, and compiled them with NASM and GCC respectively (with enough compiler flags for optimization, which I'll get into as well.
The Compiler.
Here are the sources I used. Pretty simple. No weird bitfuckery going on here.
C - https://pastebin.com/P8ZNwwSC
C++ - https://pastebin.com/zd0DmKfW
(N)ASM - https://pastebin.com/Mg9VT38s
Have a look at the difference in source code length. C/C++ are almost identical aside from how they handle output.
All these programs have the exact same output. Starts at 700, and prints every decrement of 13 until it dips below 200 (doesn't print 200, stops at 206.)
To compile the C samples, I used GCC/G++ to make my life easier.
Code: gcc CTest.c -o CTest -Wall -s -O2
g++ CPPTest.cpp -o CPPTest -Wall -s -O2
To compile the ASM sample, I used NASM and then linked with ld.
Code: nasm -o ASMTest.o -f elf64 ASMTest.asm
ld -m elf_x86_64 -s -o ASMTest ASMTest.o
Since I specified the main function as _start as a global for the ASM source, ld picked up on the default entry location. No need to f*** around with that.
Now, the first part of the tests: file size.
In each case, I used whatever compiler optimizations I knew to make it fast and have smaller file sizes. -s is the most notable, which basically strips comments and metadata during compilation. Most notably, in the C++ test with G++, I initially compiled without -s and the file size was 17.2 KB or so.
After everything was set and done, I ran a quick ls -l to get the actual byte sizes.
Code: RUNNER ~/ASMTests # ls -l
total 60
-rwxr-xr-x 1 root root 8552 Sep 23 18:48 ASMTest
-rw-r--r-- 1 root root 666 Sep 19 10:27 ASMTest.asm
-rw-r--r-- 1 root root 1328 Sep 23 18:47 ASMTest.o
-rwxr-xr-x 1 root root 14384 Sep 23 18:53 CPPTest
-rw-r--r-- 1 root root 131 Sep 23 18:52 CPPTest.cpp
-rwxr-xr-x 1 root root 14336 Sep 23 18:57 CTest
-rw-r--r-- 1 root root 104 Sep 23 18:56 CTest.c
RUNNER ~/ASMTests #
The number beside the 'roots' in each line is the raw byte size of each file.
For the source files, you can see that C/C++ are almost identical, but the ASM source is 5x/6x larger.
But what's interesting is when we get to the binaries.
I first thought that 8.5KB was pretty big for a file I wrote in ASM. I mean, shouldn't it at least be smaller than the source once it's all condensed into bytecode?
And sure enough, I was right, but I forgot to factor in one thing: ELF format file headers.
ELF is an executable format pretty much made for linux and microcontrollers, and has lots and lots of header data. Why it can't be condensed is beyond me, but the easiest way to figure out the actual size of the code is to launch readelf:
Code: RUNNER ~/ASMTests # readelf -S ASMTest -W
There are 5 section headers, starting at offset 0x2028:
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 0000000000401000 001000 000084 00 AX 0 0 16
[ 2] .data PROGBITS 0000000000402000 002000 000005 00 WA 0 0 4
[ 3] .bss NOBITS 0000000000402008 002005 000008 00 WA 0 0 4
[ 4] .shstrtab STRTAB 0000000000000000 002005 00001c 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
l (large), p (processor specific)
RUNNER ~/ASMTests #
For this, you need to know a bit about assembly, but the important thing you need to know is that the actual code/logic is stored in the .text segment.
And how big is that segment?
Have a look at the size column (admittedly it's easier to read in a terminal.)
Eighty Four Bytes.
EIGHTY FOUR BYTES.
Oh wait, that's in hexadecimal. Convert it to decimal and you get 132 bytes.
Almost smaller than the raw C source code.
(.data and .bss segments are important as well for this program, but still, adding them all up is less than 100b.)
So the file itself is only large because of the headers (and a pretty far-back entry point.) I have yet to figure out if this is condensable, if at all. Could be a fun project sometime.
Back to the story.
Vulgar Display of SPEED.
This is where things get interesting.
If you weren't aware, you can use the 'time' command to get the execution time of a program or command. Use it as a prefix to whatever command, just as you would sudo and at the bottom, it'll always display execution time (assuming it's not a cronjob or something.)
time outputs three values: real, sys and user. sys and user refer to the time spent in either user mode or kernel mode, and we don't really care about them. The real time is the time between pressing enter and the return code of the application, or in other words, the actual execution time.
So, starting with the Assembly code as the last challenge's winner:
Code: RUNNER ~/ASMTests # time ./ASMTest
700
[...snipped...]
206
real 0m0.001s
user 0m0.000s
sys 0m0.001s
RUNNER ~/ASMTests #
Whew, a single millisecond. Cool!
Note that because the ASM sample is written using syscalls exclusively for output, it doesn't spend any notable time in user mode and does everything at a kernel level.
Now it's time to check the others which are now lagging a bit behind:
Code: RUNNER ~/ASMTests # time ./CPPTest
700
[...snip...]
206
real 0m0.005s
user 0m0.004s
sys 0m0.002s
RUNNER ~/ASMTests #
Ouch! the C++ code ran in 5 milliseconds. Sure, it's not a noticeable difference, but that's mainly because this is a simple problem that only involves one loop. If you're searching a 100000 item array using binary sort, you're going to wish your code runs five times faster.
Now, for the last one: C.
Before I go on here, I'd like to first raise the common claim that "modern C++ is just as fast as C." You've probably heard it from that idiotic software engineering or computer science undergrad who just doesn't like not being able to import a library that does all the work for him.
Onto the test:
Code: RUNNER ~/ASMTests # time ./CTest
700
[...snip...]
206
real 0m0.004s
user 0m0.001s
sys 0m0.003s
RUNNER ~/ASMTests #
Okay, not a huge increase in performance, I'll admit. But again, when you consider scalability, that's still a 20% increase in speed.
And don't forget: I just used whatever compiler optimizations I knew of. There are way more out there.
Conclusion
So, the king of filesize is...
ASM
And the king of runtime speed is...
ASM
But were we really surprised?
Why does it matter?
When you do anything at a relatively low level (ie. GPIO pins on Arduino, a Pi, or any other MCU/microprocessor,) you're not only limited by the amount of space you have to store a program, but you also want that program to run fast enough that it doesn't lag any other operations that might be going on. Say you're using interrupts instead of a loop function to save power in arduino (good for you!), then you want those interrupts to respond to the exact nanosecond.
Of course, it always depends on use-case.
But from a variety of posts I've read online, although there's lots of skewed information, many users report up to 70% increase in speed (almost DOUBLE) from writing their code in C or ASM for the digitalWrite arduino function. For other methods and functions, there's likely much more performance to be gained.
So optimize your code. Just because your PC has 16GB of RAM doesn't mean you need to use all of it constantly.
|
|
|
|
| Solar Minimum |
|
Posted by: Guardian - September 21st, 2019 at 5:21 PM - Forum: General Discussion
- Replies (2)
|
 |
Interesting...
https://science.nasa.gov/science-news/ne...-is-coming
High up in the clear blue noontime sky, the sun appears to be much the same day-in, day-out, year after year.
But astronomers have long known that this is not true. The sun does change. Properly-filtered telescopes reveal a fiery disk often speckled with dark sunspots. Sunspots are strongly magnetized, and they crackle with solar flares—magnetic explosions that illuminate Earth with flashes of X-rays and extreme ultraviolet radiation. The sun is a seething mass of activity.
Until it’s not. Every 11 years or so, sunspots fade away, bringing a period of relative calm.
During solar minimum, the effects of Earth’s upper atmosphere on satellites in low Earth orbit changes too.
Normally Earth’s upper atmosphere is heated and puffed up by ultraviolet radiation from the sun. Satellites in low Earth orbit experience friction as they skim through the outskirts of our atmosphere. This friction creates drag, causing satellites to lose speed over time and eventually fall back to Earth. Drag is a good thing, for space junk; natural and man-made particles floating in orbit around Earth. Drag helps keep low Earth orbit clear of debris.
|
|
|
|
| De-Obfuscating JS samples. |
|
Posted by: Lain - September 18th, 2019 at 2:03 PM - Forum: Software
- Replies (7)
|
|
Someone on another forum recently sent me a code sample of a script he claimed to be malicious. The script was installed through TamperMonkey/GreaseMonkey and was allegedly used for stealing BTC from LocalBitcoins silently.
On top of that, the user also claimed that the script would still be active even after uninstalling/removing the script from TamperMonkey, which I already believed to be highly improbable.
Code: https://pastebin.com/1FVJCFa8
Note, that's a live sample. Don't install it. I've made an edit to it, specifically the BTC address of the attacker, so in the case that you do install it and lose BTC, send me a message and I'll refund you the amount (minus fees ofc.)
Since it's a web browser script, it's written in Javascript.
Generally, the first thing you want to do when deobfuscating Javascript, you want to make it actually legible. Find the line endings, find where it should be indented, and so on.
For this, you can do it manually (find+replace ; with ;\n for line endings) and then add tabs as you see fit, but in VSCode you can simply install a pretty-printing addon and format through there, or use a cool tool called JSBeautify (now known as Beautifier.IO.) A quick google will return the page, I don't feel like linking anything that isn't a pastebin.
After that, you'll get something that looks like this:
Code: https://pastebin.com/5k5KhMPs
Now, it's a user-script. User-scripts like this have meta-data. Have a look at the first nine lines. Specifically, have a look at lines 2, 5, 7.
2 gives the name of the script.
5 gives a description of what it's supposed to do (ie. misleading anyone who looks at the code.)
7 gives the rule for which sites this script works on.
Although the script claims to be only used for LocalBitcoins (LBTC) based on lines 2/5, line 7 tells us that the script is to be applied globally, ie. every web page that is visitted (and isn't blacklisted by TamperMonkey to be used on by the user.) That's the first red-flag.
Now, it's time to do some actual deobfuscation.
First, we want to start converting all LITERALS.
This means strings, integers, and anything that isn't being referenced as an offset or another variable or something.
Note lines 13 and 63.
Line 13 is a hex-encoded string. You can tell by the \x delimiter between values, and that each value is a single byte (ie. two hexadecimal characters, 0-F.)
Line 63 is essentially the same thing, except there's more than one.
After decoding line 13, you get a string that looks a lot like base64:
Code: Z2V0RWxlbWVudHNCeUNsYXNzTmFtZQ==
Code: getElementsByClassName
Alright! We have our first piece of information!
Generally, I don't modify code unless it's something that will be implicitly converted by the interpreter, ie. the web Javascript engine. This isn't being implicitly converted. It's a string type inside an array, at offset 0 (notice the square brackets.) It needs to be converted first somewhere down the line. Instead, I usually just add a little comment at the end of the line/variable declaration with the actual decoded value.
Code: // getElementsByClassName
Now, don't be doing this all in the post here. Open up your text editor and paste in the pretty-printed script. After commenting, you can do another cool thing. The variable names are all scrambled with arbitrary hex values (prefixed with _.) Copy the variable name, paste it into find+replace. Rename it (and all of its instances) to getElementsString (or something easily recognizable, you can rename things later as you need to.)
Let's take a look at the bottom, line 63 where we have more literals. Do the exact same thing with the hex-encoded strings and you'll find that they aren't even base64 encoded as well, just hex'd.
Code: 'bitcoin-address bitcoin-address-controls',
'innerHTML',
'158MzR5HTL6c4insJts2XNnFdRMJwBgian'
You can use inline comments for these too, /* like this */
Okay, strings are done. You can already get a good idea what's going on in this script just by knowing these values. But if you're still confused, take it a step further.
So, we don't really have any more strings to fix (aside from the escaped sequence on line 29 if you want to edit that one too,) but we have two more things to do: integers/numbers and variable names.
You'll see most of the numbers in this code sample use hexadecimal notation again. Specifically, you'll notice an absolute ton of null bytes/0 values written as 0x0.
Find and replace again. Swap 0x0 with a simple 0. Watch out for the string-literal one on line 63 again.
Do this with every hexadecimal number you see. On line 37 in the loop you'll see 0x40, 0xff, 0x4, and more. Replace them as necessary, but be aware of what's going on. 0xff is being used as a mask with the bitwise & operator. Likely best to leave that one alone. But also keep in mind that 0xff & 0xzznn will always be equal to the last two bytes, ie. 0xnn. Maybe we can use that later.
Back to renaming. Specifically, variables.
We already renamed line 13. But what about others?
Line 34 presents us with something interesting: a character map. You guessed it: it's going to be used as offsets for converting integer values to ASCII characters. You can rename it to charsetMap or something.
But now this begs another question: why is the charset being brought up here? Like I mentioned, it's probably being used for conversion. I'll get back to it, because I need to explain another couple lesser-known features of Javascript:
Closures:
Closures are basically a fancy way of scoping functions around so that one object can have implicitly private/public variables, and allow functions to access data outside of their limited scope.
Take a look at the example at W3Schools for more info, this isn't a javascript tutorial.
Basically, this entire script is done using closures, also known as local functions. Literally. Read from line 10.
This is in part due to how tamper/greasemonkey work, but also for the sake of allowing this script to work even through obfuscation.
So when we're talking about introducing a charset here, it's because it's about to be used in another function.
(I hope you remembered to find+replace the name of the charset variable everywhere and not just the variable itself!)
Another cool feature of Javascript is called Array Notation. And no, I'm not talking about declaring/using arrays:
Array Notation (ON OBJECTS!)
Let's use an array as an example.
We can push new items into the array using the .push() method, right?
Printing the array will yield [1,2,3,4]
But you can also do some pretty f*** stuff with calling that method. By f***, I mean we can pass the method as a string to the object using the same notation that you used for declaring the array:
Google for 'object property accessor' or 'object bracket notation' to find a couple articles on why/how this is used.
What's relevant is that this is used almost EVERYWHERE in this code sample!
Even the push() and shift() array methods are being called using that notation on line 17.
And immediatelly, that tells us that the variable it's being used with (and the variables in the brackets) are all of array type! You can comment them or rename them as you choose.
But what's even more interesting is what goes on down by the charset we brought up earlier.
Right below it, in the loop, you can see a variable accessing something called 'atob'.
If you've done any JS development, you might have come across this method before: it converts the type string (base64 encoded) to a type string as plaintext.
So essentially, this entire function/loop is dedicated to converting the variable from line 13!
You can slowly drudge through the code more if you want, but at this point, it's safe to say we've figured out the sample's behaviour without needing to install it:
On line 63 with all the other strings we decoded earlier, it calls the document object's method, getElementsByClassName. Don't worry about the 0x0/0 that comes right after it (or within it.) It pulls in the classname of 'bitcoin-address bitcoin-address-controls' and once selected (if it can find anything,) calls the innerHTML property of the classname and replaces it with the value of the BTC address.
In other words, all that code simply does what a one-liner does:
Code: document.getElementsByClassName('bitcoin-address bitcoin-address-controls').innerHTML = "BTC-ADDRESS"
Seems mostly harmless.
But where do we find the bitcoin-address* classnames on LBTC?
Right on the desposit page.
When you want to convert your hard-earned BTC to cash, bank transfer, paypal, or whatever, you need to deposit that BTC on their site using the address they give you on the deposit page.
When you open that page with the script, the script will silently change the address to the attacker, misleading you to send BTC to the attacker's BTC address.
So back to the original questions on behaviour:
--Is the script harmful?
--Will it survive uninstalls?
--Will it steal all your BTC?
1. Yes. We've established that through de-ob.
2. This script reflects no signs of that.
3. No, but it will try to mislead you into sending BTC to a different address than the one provided by LBTC, which can cause you to lose some money.
So what about question two?
After questioning the user more about what other addresses were allegedly changed to, he replied with a different address than that initially decoded from the sample.
It's likely he had other malware on his system installed and thought that removing this one script would make him clean.
His fault, I guess.
That concludes this little walkthrough. You can play around with the sample above. It's not my code and I don't assume any responsibility for damages done using the live sample, I'm only posting it here for the sake of informative purposes regarding deobfuscation.
I can post more walkthroughs regarding obfuscated code if you'd like. Most of it is regarding scripting languages, though, nothing native that's noteworthy, yet.
|
|
|
|
| Fallout |
|
Posted by: Thomas - September 8th, 2019 at 2:27 PM - Forum: Other Games
- Replies (2)
|
 |
What's your favorite Fallout game, and why is it Fallout New Vegas (aka the pinnacle of computer role playing games)?
|
|
|
|
| NFL Season 2019 |
|
Posted by: Guardian - September 6th, 2019 at 2:57 AM - Forum: Sports
- Replies (48)
|
|
The Packers and the Bears have kicked off the 2019 NFL season tonight!
Very defense-oriented game so far. Not bad for a season-opener for the 100th anniversary of professional football.
|
|
|
|
| Chernobyl |
|
Posted by: Thomas - September 2nd, 2019 at 3:29 PM - Forum: Media & Entertainment
- Replies (2)
|
|
Anyone catch this show? I watched it as each episode came out and was blown away. Easily the best TV show I've ever seen. Not necessarily my favorite, but definitely the best.
|
|
|
|
|
![[Image: wii-u-nintendo.png]](https://nintendotoday.com/wp-content/uploads/2014/02/wii-u-nintendo.png)
