[Windows Embedded Standard 7 Serial Number
Hanne Rylaarsdam
im building an interactive portable ad campaign device (x86 platform) with touchscreen and stuffs. which is better OS for the device, Win CE or Win embedded standard (XPE). i need to provide support for multimedia platform such as Flash for easy ad development.
Both XP embedded and Windows CE can be built using tools that allow you to add/remove components from med OS making it possible to trim it to your requirements. Most developer probably never does this but rather use what is "factory default" delivered with the hardware, or let the hardware guys make a custom made image for you.
If you get Windows Embedded Standard, I can tell you from experience that it is easy to set up as a more-or-less full-featured Windows XP installation. This means that you'll be able to install pretty much anything that would run on a normal WinXP desktop - and if it can't run, you usually can just get it to run by figuring out which component you haven't installed yet. This would be a very good feature to have if you need things like Flash.
As far as licensing goes, you're looking at a thousand dollars for the WES license, plus $90 for each WinXP license. Getting all the licensing stuff set up is a hassle because you have to go through distributors for both the WES software and the keys, and there's only 4 distributors in the US. You can get a WES demo that's good for 4 months, and you can generate an unlimited number of "demo" XP installs that last 90-180 days (their numbers, not mine). That's a very gracious amount of time for testing out whether WES suits your needs or not.
If you have a fully fledged x86 system without limitation, low power requirements or interfacing with embedded hardware as I seem to understand from your application then WinXP would win hands-down for me. WinXP has the horrible boot sequence and more venerable to security attacks but as this is not a hand-held consumable product I think I'd live without WinCE's finesse.
Your application, and the ad campaign in particular, are more important than many of the features of the OS, so I'd pick the most straightforward OS to develop on where the development OS is very similar to the target OS.
I would suggest a slight alternative to WinXP Embedded Standard. I would suggest "WinXP for Embedded Systems" (WinXP FES) which is marketed as "Windows Embedded Enterprise". This is the full version of WinXP (as you used to have on your desktop) fully supported to 2016!
The reason I'd suggest WinXP FES is for reduced upfront costs in development tools and development time, faster time to market and with the likely number of units the few extra dollars per system is not likely to be of an issue.
WinXP FES is not available through normal retail distribution (as WinXP has been discontinued), but is available though the embedded channel, the same place as you'd get WinCE and Windows XP Embedded Standard.
For those that do not know you'd need to fill out a declaration that the embedded device will not be used as a normal desktop computer doing office type functions. As long as you can demonstrate that the embedded device is not packaged as such then you'll typically be allowed to license WinXP FES.
Follow the registry hacks in this presentation to set the boot logo image, booting without the "Desktop" into your application (Kiosk Mode), suppressing pop-up messages etc. to make WinXP look more like an embedded OS.
Just to add my 2 cents:
I've been working with Windows CE for 2 years now and haven't found a free solution for Flash. Not even an open source library. I am not sure how many companies out there sell Flash solutions for Windows CE and what the price is. (The only company that I know of and saw that have a solution for Flash is BSQUARE, but I don't know the price)
Bottom line is that XPE will give you way faster time to market. And it might result in a plus minus same price if you put into the equation the time and license for the Flash you will need for Windows CE (Not sure about that...).
Why have you narrowed down to those choices? WinCE typically runs on much more highly constrained (and less expensive) hardware, and will run on multiple architectures. XPe on the other hand runs on x86/PC hardware only.
Windows CE Although it offers a "limited" version of the Win32 API and run the Compact Framework version of .Net, it is a reasonably complete development environment. If you start development targeting the platform you should not run into many problems. Licensing is very reasonable (about $10/copy). It is available for a number of different CPUs.
Windows XPe The promise of Windows XPe is that you get full Windows in a smaller package. The trick is that the smaller package involves leaving some part of Windows behind. Many people find that they end up with essentially all of XP in order to support the parts of XP they want to use. Windows XPe only runs on x86 processors. Licensing is similar to desktop Windows (about $100). On the plus side desktop applications should run on it without changes.
As a note, neither of these are regular Windows and despite Microsofts marketing champaign's, you should be prepared to spend some time to learn about the OS you choose. Better yet look into a consulting company in your area that can walk you through the first deployment.
Finally, a comment on Linux. We looked at Linux as well. We did end up choosing Windows Embedded CE, but it was close. We had several people on staff that were already familiar with Linux (while others were already familiar with CE). Initially we had better performance with Linux, though we were able to get comparable performance from Windows Embedded CE. Our product is shipping now and performing very well.
I tried what is described in this post: A service installation section in the INF is invalid - Installation & Troubleshooting - Arduino Forum ,
also what was pointed at in another post: -arduino-on-windows-embedded/
I have Firefox 43 installed on forklift computers that have Windows XP embedded standard (SP3) and when I use the Help About to keep Firefox current it will download 47.0.1, however I noticed 48.0.2 is the current version. Once the computer is at the 47.0.1 it says it is current, however it will let me download manually the 48.0.2 as an executable and install it.
there is a different background to this not related to xp:basically there was a startup crash with a particular third-party product (websense antivirus) that was experienced by their users updating to firefox 48. as a workaround we introduced a hotfix addon which should single out unaffected users in advance, which would then get updated to 48. this hotfix addon should get installed in the background automatically to firefox installations 47 and older, but it might take a day or two until that is filtering through to an installation.
Our security audits and vulnerability
assessments are based on industry
standards and best practices to assess
weaknesses in your cloud environment
and network, as well as mobile
and web-based apps.
I needed to do some tweaking to get the current tools to work, but in the end, the attack worked as expected and probably will continue to work for a long time given the general lack of patching of embedded devices. I found the following posts especially helpful as I worked through this exercise, so many thanks to the authors!
I first tried using the exploit/windows/smb/ms17_010_eternalblue Metasploit module, but each attempt resulted in a blue screen no matter which payload I tried. I finally found that it has only been ported to x64 at this time, and the authors clearly state that attempts to exploit an x86 device will crash it.
At this point, I figured my best option would be to make the original DoublePulsar implant work for my needs instead of trying to reverse engineer everything and create my own attack from scratch. I will not go in-depth into the background of these commands, since the two posts I linked to above already do a great job of explaining the setup process.
This gives us a graph that looks very promising for something like an OS version checking routine. Notice the section that we jumped to is in the bottom right corner of this graph, so we can traverse upwards to see how we got here.
We can change the bytes by using the Edit Patch program Change bytes menu in IDA. Note it starts with the 74 opcode that we expected. Simply changing that to 75 will switch the path the program takes to kick this down the Win7 path. Again, this is really hacky and a terrible shortcut but we can always come back and make a proper patch after verifying this works.
Now that we have a listener setup on Kali, and a DLL ready to be injected that will make the victim call back to Kali, all we have left to do is actually inject the DLL using our modified version of DoublePulsar.
To make this attack better, the DoublePulsar exe should really be patched with some proper code and incorporated back into the master Github repo, but that will have to wait for now. Regardless, it looks like work is underway to port the attack over to x86 in Metasploit anyways, so once that happens it will be much easier to attack most Windows-based embedded devices.
You might not know how at-risk your security posture is until somebody breaks in . . . and the consequences of a break in could be big. Don't let small fractures in your security protocols lead to a breach. We'll act like a hacker and confirm where you're most vulnerable. As your adversarial allies, we'll work with you to proactively protect your assets. Schedule a consultation with our Principal Security Consultant to discuss your project goals today.
795a8134c1