Category: Technology

Hacker

One of my tiny teenage victories was convincing my parents to buy me The hacker's manual book. I was obsessed with becoming a hacker, and as these things usually go, I was just trying to be cool - we had a hacker at high school, and a well-rounded one: the black glasses, the op status in the local IRC channels, the incomprehensible technical dialect, and a 55.6k modem filled the picture. Retrospectively, this wasn't a particularly good book: it contained mostly poorly-written, typo-laden C code, intended for god-knows-which incompatible gcc version, and demonstrated exploits which the world has usually long forgotten and patched against. If it taught me anything, it was that becoming a hacker is a long journey and I had tons to read more, before I could join the league. And that there were several definitions for hacker, which people regularly misused.

I have to warn you: this post contains some self-flattery. It's not much, but... you've been warned.

To the point: what defines a hacker? In a nutshell, the hacker is just an extremely curious technical person. He's focused on experimentation and loves to tinker. He has a very large and wide expertise in computers, networks, telephony, hardware, mechanics, and so on. He's always hungry for more knowledge, and likes to inspect other people's creations in order to learn from them. He's not afraid to disassemble his brand new $3000 oscilloscope to see how it's made. He feels perverse pleasure in using systems and products in ways their original creators didn't anticipate. You'd see a hacker use GMail as a file system. He'd run Doom on a iPod. He'd mount a webcam over his front door and will write a system to notify him for suspicios persons wandering in there. A good hacker can grasp a large and new system, and recognize known patterns, so in the end he could have some vague understanding of how it works, and, more importantly, where its weak spots may be.

Well, in that description you'd also find the people who bypass computer security systems and manage to steal your passwords, infect your computer with malware or spyware - because somebody didn't really pay attention while writing that OS or website. The "good" hackers insist on calling these people "crackers" - to make it clear that they intentionally crack computer systems for personal gain. Or differentiate between "white hats" and "black hats" (a dubious naming, since I can't imagine a hacker who isn't at least a bit "gray"). And besides, a lot of "hacks" don't necessarily rely on technical prowess - the "I love you" e-mail virus exploited the fact that a lot of people on the internet have unsatisfactory personal lives.

Anyway, the point of writing this article is to provide a good, non-mainstream example of how a hacker thinks, reasons, and works. Holywood is particularly bad at depicting hackers, and you'd see movie after movie, with the big fat budgets they have, but they never come close to a realistic hacking scene. I think they just don't want to do that. That hackers work mostly at night is but the only think they get right. Here the example goes:

----------

The task at hand was to buy a wireless doorbell for a partially deaf granny. It had to have one transmitter (the little box you put near the front door), and not one, but two receivers, one per room. This turned out to be a not well explored area in the wireless doorbell business, as none of the products The Hacker saw had multiple receivers. The offerings mainly differed in external design and boasted how many melodies they supported and how you could set the loudness level.

The hacker thinks: how typical of Marketing! They would make their point about insignificant details like number of melodies, or colors, but woudn't, for a change, mention at what radio frequency do the units operate, what type of error-correcting code is employed, and how many walls can the signal penetrate. Yes, one of them states the maximal workable distance, but of course doesn't mention under what circumstances...

The Hacker got two pieces of the cheapest variant and asked to unpack them at the counter:


The backsides of the transmitters and receivers had a label with a numeric barcode thing - it was the same for a transmitter/receiver pair, but differed between the two pairs. It was obviously not a serial number. The label also stated the frequency, the same for both pairs:


The hacker thinks: if they operate on the same frequency, then they transmit a specific code to differentiate, so that a receiver only rings up when it hears "its" transmitter. Otherwise what would happen if two people bought the same model wireless bell in the same block? You wouldn't expect one to ring them both, right?

Now The Hacker would hope to be able to change the expected code of one of the receivers. To be honest, The Hacker wasn't sure he could do it, but his intuition was urging him to try.

... well, I intentionally picked up the cheapest model out there. They can't be using anything too complicated inside. It should be cheap and easy, like a DIP-switch or configurable wiring. But definitely a simple and dirt cheap thingy.

When he got home, The Hacker found out that the receivers had something configurable indeed - a row of cut traces on the circuit board, some of which were connected with solder:


and, of course, the positions of the solder joints was differing between the two units:


The hacker thinks: We have some numbers here, with pluses and minuses. There must be a mapping between those numbers and the barcodes on the transmitters. But for the purpose of this task I don't need to figure out the scheme - it suffices to make the solder pattern identical on both units.



5 minutes later, the two receivers were ringing in unison, and there, two walls apart, was The Hacker, with a big, happy grin on his face.

----------

In conclusion... the next time when you'd want to explain somebody what a hacker is - send him here. Please. I'm fed up of these unshaven weeps in glasses, who hack multi-billion-dollar systems using novel, futuristic GUI systems, mumbling faux l33tsp34k. Correct portrayal of hackers must triumph!

Posted in category Technology -- 1 Jun 2016, 16:20, 1 comment

AMD SimNow tutorial

I decided to write a tutorial about AMD SimNow™, which I bumped into recently. While the tool is nice, the introductory articles about it are somewhat lacking, so you just RTFM, RTFM and RTFM until your head explodes. I found some of the things quite nonintuitive, hence this tutorial.

So, SimNow is, in a nutshell, a complete simulator of a PC (even an imaginary one). If you were told in you CS classes, that CPUs are just software (which is correct), and they are being tested (by software) hundreds of thousands of hours, before they are implemented on actual silicon (also correct), then this is one of the programs that does this sort of simulations.
SimNow works on a very low level - analyzing, for example, how is the CPU—memory transfer going (the exact speed and timings are emulated as well), or how is the HyperTransport performing, etc.
The price to be paid for that kind of thoroughness is speed: e.g., a 3200 MHz real CPU emulates an (imaginary) 2.0 GHz part, with an emulation speed of around 50-100 MIPS. So the simulation moves slower than real time (contrary to other technologies like DosBox, VMWare, etc.). This means that the emulated CPU(s) is assumed to be fixed-speed, and its full-speed simulation is impossible, thus the time "stretches" from the Host's viewpoint: a "sleep 1s" would take 10 seconds (wall-time) if the current emulation speed is 200 MIPS. So, if you're watching a movie inside the emulator, it will "play" without a hitch, but it would display quite a bit slower. Other emulators/virtualization solutions usually take the other way - there, the guest movie player will notice the CPU is slow, and activate framedrop, etc.

That said, you'd guess that using SimNow requires a hell lot of waiting. Thus, you're better off using a lightweight and optimized guest OS. Creating a virtual HDD image is not very easy to do, so the simpler way is to mount .ISO CD images, and run some of the lighweight LiveCD linux distros - I used Puppy Linux 5.28. This OS fits the task quite well: it doesn't complain about that CPU it has unheard of, and boots in a reasonable time (still, 10 minuites, but that's considered quick), and after booting all works fast enough to be usable. You'd probably be annoyed by the lack of mouse cursor sync between guest and host - some of the issues can be mitigated by twiddling with the Puppy's mouse sensitivity settings.
SimNow allows you to "assemble" any machine. Just drop-in the hardware components from the catalogue (video-cards, southbridges, CPUs,...). However, tying them all together can be a tedious task. An easier way is to just load and run one of the prefabricated "configurations", which come with the installation. For example, the Bulldozer is implemented in only one config, named vp_bd_phase1.bsd.
There's still one hitch you need to resolve before emulating your LiveCD: the BIOS's boot order has the HDD before any CDs, and you'd get an "Invalid (or missing) operating system" error if you launch it right away; you need to go inside the BIOS (which is... well..., real) and fix that. Restart and voilà!

The next part is not well documented and took me quite a while to figure it out. It's about how to connect our emulated machine to the world. SimNow doesn't support Copy/Paste between guest and host, it has no "shared folders" thing, but it has a virtual networking. The latter is implemented in a way that may seem striking and overcomplicated at first, but there's a reason behind it. From the guest's side, it is simple: it just sees a E1000 network adapter. Host, on the other hand, expects to have a connection to a "mediator" server process (which has to be run manually). The mediator is the actual "exit point" of the emulated traffic to the world. I.e., if the guest decides to ping google.com, the packet is first passed to the emulated E1000 interface, then SimNow tunnels the packet to the mediator (which can be situated on a different machine if you will), and then the packet appears on the server side, potentially after a NAT step, or directly, as if it originates from a bridged adapter. The bridged scenario is the easiest, so I'll describe that. Before running SimNow, you need to launch the mediator program; the arguments are "-p <port>" (e.g., "./mediator -p 8888"). The mediator uses libpcap, and thus requires superuser privileges. After that, launch your simulation, and use the command prompt of SimNow (this is usually the console where you launched ./simnow from) to instruct it to connect to your mediator. Use "setMediatorHost localhost:8892" (the number needs to be <port> + 4). After that, enter "linkConnect down" and "linkConnect auto" - this will tell the E1000 that "the cable is connected" (in our case the "cable" goes to our real LAN). This establishes the communication so you can start working with yout VM. Yet, I had some issues, for an unknown reason: I was unable to ping the guest from the host, even though other machines in the same LAN had no problems! Thus, to copy a file to the guest, I first uploaded the file to some other machine in my LAN, and then downloaded it from the guest with wget. Luckily, Puppy has both wget and unzip :)

After all that info, you might be wondering - why would you need to do all that? Well, in my case, that was the only way to test my XOP instruction implementation of ucbench - without actually buying a Bulldozer, which was (at the time) kinda impossible, given it was before its launch date! The vp_bd_phase1.bsd config supports both XOP and FMA4, at their actual speeds. As an example of the usefulness of the complete simulation (which SimNow dows) - when I benchmarked my new code on the Puppy under SimNow, it showed a performance increase of around 50%. At first, I thought this was quite too much, but then the real Bulldozer showed the same figure, so the simulation was pretty accurate!

One more thing: the simulator works on 64-bit AMD processors only (it's explicitly stated in the reqs). Interestingly enough, the situation is more or less the same in the Intel camp, only it's unofficial: Intel also has a CPU emulator for yet-to-be-released processor cores, which I tried (before the Sandy Bridge launch, around March). The requirements just list "an Intel-compatible prpocessor". Well, if you are brave enough to run it on an AMD CPU, it appears to start and for some time it works without complaining, and then it crashes "mysteriously", with a Segfault. The same program, on a 14-times-weaker Intel CPU (Atom, vs. Thuban) works without a hitch :D. Cross-company backstabbing ftw :]

Posted in category Technology -- 24 Oct 2011, 02:29, 3 comments

Beat detection

Not long ago, I was pondering if there's some useful way to exploit my memory-load sensor of the EpoX 9NPA+ Motherboard I use at home. For those of you which haven't heard about it - this sensor shows you the memory load/traffic in real-time. So, in idle, it blinks very slightly, but when you run any memory-intensive benchmark, it gets quite bright.
A week ago (just as I was listening to «Moloko - Sing it back»), I came up with a nifty way to abuse this sensor: to visualize the beats of some song. Here is it in action:



YouTube - Beat visualization on Epox 9NPA+
Local copy (H.264 750 kbps)

I wrote a visualization plugin for XMMS, which uses a simple beat-detection algorithm, and, when a hit is detected, it blinks the sensor. The blinking is inflicted using a large number of memcpy() operations inside a 64 MB array :) The algorithm is right now only sensitive to bass beats (this is the reason it doesn't detect the snare drums, as visible on the second song in the video).

Posted in category Technology -- 19 Apr 2010, 11:07, 0 comments

Wizz Air and regular expressions

Sometimes I wonder - is it just me, or this world is much more complicated and confused than it needs to be?

In short:

1) I'm booking an online ticket through the Wizz Air website. I have an account, so there's no traveler information I need to fill in;
2) The surprise comes in. I'm stuck at one of the pre-filled forms - when I press the "Next" button, a JavaScript window pops up and tells me I've entered an invalid phone number. Strangely enough, their system has had accepted the same phone number the previous time I booked a ticket;
3) After some experimentation, I realize that the system won't accept neither +35988XXXXXXX nor 0035988XXXXXXX (359 is the country-code of Bulgaria, btw). Weird, isn't it? I open the page's source code and search for the error message. So I arrive at the checkPhoneNumber function:

function checkPhoneNumber(num){
var filter = /^([0-9]){10,13}$/;
if (filter.test(num) || num == "")
return true;
else
return false;
}

4) Eureka! The regex says it all - they need a number with 10-13 digits inclusive. The country-code goes bye-bye.

In conclusion, one could to ask himself - will the average Joe, when being frown upon by this automatic System, know about the piles of source code which lay behind the funky web pages? Or that the "System" actually consists of a few screenfulls of simple code, written in an interpreted language? And within this code, it is the checkPhoneNumber function that does it all (ok, this may seem easy, but you could have been an Angolan, and do not know English at all)? And that the phone number is marked as valid if it's 10-13 digits, inclusive? More generally - the whole thing comes from one source after all, so why didn't they put a clarifying text like "(10-13 digits, please)" next to the input box? Even more generally - does it have to be such an elaborate and complex explanation to every simple problem in IT? And finally, why is this world so complex, anyway?

Posted in category Technology -- 25 Aug 2009, 01:43, 0 comments