I hate to admit it. I don’t really use Linux on my desktop anymore. Well, technically I do. I boot into Linux. Then I do about 95% of my work in Chrome. About the only native applications I use anymore are development tools, the shell, emacs, and GIMP. If I really wanted to, I could probably find replacements for nearly all of those that run in the browser. I don’t use it, but there’s even an ssh client in the browser. Mail client? Gmail. Blogging? WordPress. Notes? OneNote or Evernote. Wouldn’t it be great to run those as actual applications instead of tabs in a browser? You can and I’ll show you how.
Having apps inside Chrome can be a real problem. I wind up with dozens of tabs open — I’m bad about that anyway. Restarting chrome is a nightmare as it struggles to load 100 tabs all at once. (Related tip: Go to chrome://flags and turn “Offline Auto-Reload Mode” off and “Only Auto-Reload Visible Tabs” on.) I also waste a lot of time searching since I try to organize tabs by window. So I have to find the window that has, say, Gmail in it and then find Gmail among the twenty or so tabs in that window.
What I want is a way to wrap web applications in their own window so that they’d show up in the task bar with their own icon, but external web pages that open from these apps ought to open in Chrome rather than in the same window. If applications were outside of the single browser window, I could move them to different desktops and organize them like they were any other program, including adding them to a launcher. Hopefully, this would let me have fewer windows like this:
Continue reading “Linux Fu: Turn a Web App into a Full Program”
We tend to think of elaborate electronic conference badges as something limited to the hacker scene, but it looks like the badgelife movement is starting to hit the big time. Now even the “big boys” are getting into the act, and pretty soon you won’t be able to go to a stuffy professional conference without seeing a sea of RGB LEDs firing off. We’ll let the good readers of Hackaday determine if this means it’s officially post-cool or not.
[Noel Portugal] writes in to tell us about how he created the “Code Card” during his tenure with the Oracle Groundbreakers Team. Featuring an ESP8266 and an e-ink screen, the Code Card serves not only as swanky way of identifying yourself, but as a real-world demonstration of physical devices pulling content from Oracle’s Cloud. Gotta keep those corporate overlords happy.
The Code Card is a fairly simple piece of hardware as far as badges go these days, but then the goal was never to be flashy. It does feature dual four-pin Grove System connectors on the backside though, so you can plug in additional sensors and gadgets for the customary badge hacking sessions.
To maximize runtime on the rechargeable coin cell battery, the Code Card only turns on the ESP after the user has pressed one of the buttons on the front. Once the ESP has finished performing whatever task the user requested, its powered back off completely rather than put into standby. Combined with the e-ink screen, power consumption while the device isn’t actively updating the display or pulling down new content is negligible.
[Noel] really went all-out on the software side, going as far as developing a web application which let conference attendees configure their Code Cards from their smartphones. Different functions could be assigned to short and long presses on the badge’s two buttons, and users could even select icons for the various functions from a list of images included in the firmware. A feature where attendees could upload their own images didn’t make the cut, but that surely won’t stop people from hacking around in the published Arduino source code and figuring out how to do it manually.
If you think the Code Card looks a bit familiar, it’s perhaps because it was designed in conjunction with Squarofumi, creators of the Badgy. So even if you aren’t hitting up any of Oracle’s upcoming conferences, you’re not completely out of luck if you want an e-ink badge to play with.
If you can’t stand the thought of using an application in your browser, you might as well jump ahead to the comments and start flaming.
Still with us? Imagine this scenario. You are at the office, at a client’s site, at a school, or visiting your mom. Suddenly, for some strange reason, you need to edit a hex file. We don’t know why, but if you are reading Hackaday, it isn’t that big of a stretch to imagine it. What do you do? Download and install a hex editor? Maybe you can’t. Or, if it is mom’s computer, maybe you just don’t want to. Your next option is to navigate to HexEd.it.
Continue reading “Edit Hex in the Browser”
[Don] installed an Android tablet into his wife’s vehicle and realized he wanted to allow it to operate and monitor the garage door. His biggest challenge? Meeting the (what he refers to) as the WAF or Wife Acceptance Factor. He decided to use a Web app on a Raspberry Pi, along with a handful of switches and a relay. His list of goals were straightforward:
- Provide the status of the door (open/closed/unknown)
- Open and close the door
- Work across multiple platforms
- Secure enough to connect to the Internet
- Reliable and simple
Continue reading “Open Sesame Raspberry Pi Style”
FPGAs aren’t really programmed, they are configured. Most designers use Verilog or VHDL to describe the desired circuit configuration. Developers typically simulate these configurations before committing them to silicon (a good habit, especially if you ever graduate from FPGAs to ASICs where changes are very expensive). That simulation takes a lot of software you have to install and learn, right?
Not necessarily. You can do e-mail, word processing, and PCB layout in your browser. Why not FPGA design? The EDAPlayground website provides two editor views: one for your main “code” and another for the testbench (the simulation driver you use to test your design). You can even open multiple files, if you have a complex design.
Once you’ve entered your Verilog or VHDL (or picked one of many examples) you can run the simulation and see the result right in your browser. No software to install, and–outside of actually learning VHDL or Verilog–not much learning curve.
As [Strauburn], [combinatorylogic], and others commented on our recent post about a VHDL CPU, you can do a lot of learning without ever having your hands on real hardware. The web site gives you access to several different tools (useful if you want to see how your code will behave on different tools) and also many standard verification libraries. There are limited synthesis tools, but honestly, if you want to go to real hardware, you are going to want the vendor tools for the specific FPGA you are using.
Continue reading “Learn FPGAs in your Browser”
Moonpig is a well-known greeting card company in the UK. You can use their services to send personalized greeting cards to your friends and family. [Paul] decided to do some digging around and discovered a few security vulnerabilities between the Moonpig Android app and their API.
First of all, [Paul] noticed that the system was using basic authentication. This is not ideal, but the company was at least using SSL encryption to protect the customer credentials. After decoding the authentication header, [Paul] noticed something strange. The username and password being sent with each request were not his own credentials. His customer ID was there, but the actual credentials were wrong.
[Paul] created a new account and found that the credentials were the same. By modifying the customer ID in the HTTP request of his second account, he was able to trick the website into spitting out all of the saved address information of his first account. This meant that there was essentially no authentication at all. Any user could impersonate another user. Pulling address information may not sound like a big deal, but [Paul] claims that every API request was like this. This meant that you could go as far as placing orders under other customer accounts without their consent.
[Paul] used Moonpig’s API help files to locate more interesting methods. One that stood out to him was the GetCreditCardDetails method. [Paul] gave it a shot, and sure enough the system dumped out credit card details including the last four digits of the card, expiration date, and the name associated with the card. It may not be full card numbers but this is still obviously a pretty big problem that would be fixed immediately… right?
[Paul] disclosed the vulnerability responsibly to Moonpig in August 2013. Moonpig responded by saying the problem was due to legacy code and it would be fixed promptly. A year later, [Paul] followed up with Moonpig. He was told it should be resolved before Christmas. On January 5, 2015, the vulnerability was still not resolved. [Paul] decided that enough was enough, and he might as well just publish his findings online to help press the issue. It seems to have worked. Moonpig has since disabled its API and released a statement via Twitter claiming that, “all password and payment information is and has always been safe”. That’s great and all, but it would mean a bit more if the passwords actually mattered.
The computer security industry has made many positive changes since the early days of computing. One thing that seems to be catching on with bigger tech companies is bug bounty programs. PayPal offers such a program and [Yasser] decided to throw his hat in the ring and see if he could find any juicy vulnerabilities. His curiosity paid off big time.
Paypal is a huge player in the payment processing world, but that doesn’t mean they aren’t without their flaws. Sometimes the bigger the target, the more difficult it is to find problems. [Yasser] wanted to experiment with a cross-site request forgery attack. This type of attack typically requires the attacker to trick the victim into clicking a malicious link. The link would then impersonate the victim and make requests on the victim’s behalf. This is only made possible if the victim is logged into the target website.
PayPal has protection mechanisms in place to prevent this kind of thing, but [Yasser] found a loophole. When a user logs in to make a request, PayPal gives them an authentication token. This token is supposed to be valid for one user and one request only. Through experimentation, [Yasser] discovered a way to obtain a sort of “skeleton key” auth token. The attacker can attempt to initiate a payment transfer without first logging in to any PayPal account. Once the transfer is attempted, PayPal will request the user to authenticate. This process produces an auth token that apparently works for multiple requests from any user. It renders the authentication token almost entirely ineffective.
Once the attacker has a “universal auth token”, he can trick the victim into visiting a malicious web page. If the user is logged into their PayPal account at the time, the attacker’s webpage can use the universal auth token to trick the victim’s computer into making many different PayPal requests. Examples include adding email addresses to the account, changing the answers to security questions, and more. All of this can be done simply by tricking the user into clicking on a single link. Pretty scary.
[Yasser] was responsible with his disclosure, of course. He reported the bug to PayPal and reports that it was fixed promptly. It’s always great to see big companies like PayPal promoting responsible disclosure and rewarding it rather than calling the lawyers. Be sure to catch a video demonstration of the hack below. Continue reading “Hacking PayPal Accounts With CSRF”