LRP Electronic ist der neue Distributor für die Marken Team Associated und Reedy in den Ländern Deutschland, Österreich, Schweiz, Italien sowie Spanien. Die Anhänger in Benelux und Tschechien werden auch über die LRP-Distributionspartner versorgt. Produkte der beiden neuen Marken im Haus von LRP werden bereits auf der kommenden Spielwarenmesse in Nürnberg Ende Januar auf dem [...]

We must be able to trust payment systems: Payment terminals have conquered nearly every retail outlet and payment cards are as pervasive as cash.

Major parts of this critical payment infrastructure, however, rely on proprietary protocols from the 90’s with large security deficiencies. Payment terminals and the payment processors they connect to are once again the culprit.

Stealing customer credentials. Fraudsters can gain access to large numbers of card details and matching PIN numbers over computer networks.

The main communication protocol between payment terminals and cash registers, ZVT in Germany, allows a fraudster to simply read payment cards – including credit and debit/EC cards – from the local network.

Worse yet, the protocol provides a mechanism for reading PIN numbers remotely. This mechanism is protected by a cryptographic signature (MAC). The symmetric signature key, however, is sometimes stored in Hardware Security Modules (HSMs), of which some are vulnerable to a simple timing attack, which discloses valid signatures. A signature extracted from one such HSM can be used to attack other, more secure models since the signature key is the same across many terminals, violating a base principle of security design.

Merchant account compromise. Fraudsters can also transfer money from merchant accounts, anonymously over the Internet.

Payment terminals communicate with a payment processor (who in turn talks to the banks) over the Internet using the ISO 8583 standard. One ISO 8583 dialect popular in Germany and other countries, Poseidon, is implemented with a major authentication flaw:

A terminal uses a secret key to execute a cryptographic authentication protocol. So far, so good. A large number of terminals – repeating the mistake made in ZVT – contain the exact same authentication key. Therefore, after changing a single number (Terminal ID) in any one terminal, that terminal provides access to the merchant account that Terminal ID belongs to. To make matters worse, Terminal IDs are printed on every payment receipt, allowing for simple fraud.

Fraudsters can, among other things, refund money, or print SIM card top-up vouchers – all at the cost of the victim merchant.

Defense need. In the short term, abusable functionality such as refunds and SIM top-ups should be deactivated wherever possible. To introduce widely acknowledged security principles into our critical payment infrastructure, more drastic system updates are necessary:

The two main payment protocols in Germany, ZVT and Poseidon, are both insecure for the same reason: They share secret keys among a large number of devices. Deploying an individual key to each terminal is paramount to make payment systems more fraud-resistant.

Details of this research were presented at 32C3.

LRP startet mit „ANTIX bei LRP“ eine neue Budget-Marke für den kleinen Geldbeutel. Die Produkte mit dem neuen Logo profitieren von den hohen LRP-Standards, sind aber preislich wesentlich attraktiver. Den Anfang macht eine völlig neue LiPo Line für den Einsteigerbereich. Das Sortiment umfasst 2S, 3S und 4S Akkus, die mit einem robusten Hardcase ausgestattet sind [...]

In Kooperation mit dem Eigenverlag des Porsche Museums in Zuffenhausen hat der Franzis Verlag den Motor des legendären Sportwagens Porsche 911 als Bausatz im Maßstab 1:4 entwickelt. Der Bausatz für das transparente Funktionsmodell wird aus 280 Kunststoffteilen zusammen gebaut – fertig verschraubt bewegen sich alle wesentlichen Teile des Motors. Das farbige Begleitbuch mit ca. 50 [...]

Ab sofort ist der neue Shop unseres Sponsors RCBay unter der Domain rcbay.eu im komplett überarbeiteten Design zu erreichen. Mit der “Flyout” Navigation und der verbesserten Sortierung lassen sich insbesondere die vielen verschiedenen Kugellagergrößen schneller finden. Als weitere Neuerung ist nun auch die Zahlung per Paypal Express möglich. Die Lieferdaten werden direkt aus dem Paypal-Konto [&hellip

Wie die Polizei Minden-Lübbecke meldet, brach im “Czypu Drom” letztes Wochenende ein Feuer aus, welches offenbar von einem defekten LiPo-Akkupack ausgelöst worden ist. Zu diesem Ergebnis kamen die Brandexperten der Polizei bei ihren Untersuchungen der Brandstelle am Montagnachmittag. Alles andere als eine technische Ursache schließt die Polizei aus. Bereits in der Nacht hatten die Ermittler [&hellip

Flightgear is constantly under development and as the feature freeze for the next 3.2 release approaches, it is becoming increasingly clear what the next version will have to offer to users:

(to avoid misunderstandings – this is a selection of features currently under development and not a release note, i.e. there is no guarantee that all items will appear in 3.4, nor are the features of 3.4 limited to what is listed here)

Precipitation

Added realism for precipitation:

The precipitation system has been partially upgraded. The speed of falling raindrops now follows a physical scaling with droplet size, and the system renders now hail in addition to rain and snow. The correct dependence of lighting with illumination of the scene has been added. In Advanced Weather, droplet size and rain intensity are now set independently, allowing to realistically render fine spray as well as splattering rain in thunderstorms. A dynamical splash-pattern of raindrops added to the Atmospheric Light Scattering (ALS) runway effect completes the visual impression.

Advanced Weather clouds

Near photo-realistic 3d clouds:

The cloud rendering system has received an upgrade, allowing to let the edges of cloud patches gradually fade out. This makes several types of cloud formations appear even more realistic.

Haze

Have you ever wondered why the terrain appears bluish in the distance?

The Atmospheric Light Scattering (ALS) rendering framework has received a significant upgrade rendering the effects of Rayleigh scattering of light with air molecules and fine dust. This includes the in-scattering of light, resulting in the blue appearance of distant objects, as well as an out-scattering effect which makes colors seen through dry haze shifted towards the red. Combined with the already existing model for rendering hazes, this leads to truly impressive visuals.

Instrumentation

Improved instruments:

A new flexible CDU framework allows aircraft developers to set up extensive CDU pages with relatively little effort. The framework supports both 3D and 2D instruments, multipages, down selecting settings to the scratchpad and various input formats (e.g. FL115 or 11500). It comes with a 2D panel popup screen so you won’t have to pan around the cockpit all the time. The CDU is expected to be introduced on the Boeing 747-400, but the framework has been designed to be flexible and fit other airliners.

Aircraft

Enjoy the latest additions:

The Extra 500 introduces a luxury aircraft one of the most advanced glass cockpits to be simulated by Flightgear. The F-14b has received a significant upgrade with an added JSBSim flight dynamics model. There is also progress on a new version of the X-15 which might make it into the release, as well as the F-20.

Atmospheric Light Scattering

Enjoy yet more interesting visuals:

ALS continues to receive a host of additions, allowing for some stunning visuals:

* tree shadows, rendered using a very performance-friendly technique
* landing and search lights for better night flight experience
* improved implementation of Fresnel scattering on water surfaces, leading to more realistic water appearance
* a procedural rock effect, capable of rendering a large variety of different rock textures and colors across the world
…

And many improvements more!

Much work is done under the hood which is not all visible:

* improvements to the rendering framework, leading to better performance
* more applications utilizing the FG-internal webserver
* a canvas-based alternative GUI and aircraft center, allowing to manage installed aircraft inside FG
…

Stay tuned as we fly towards our next release!

Ready to launch?

Thanks to Alexis Bory and Enrique Laso, the F-14b has been for a long time one of Flightgear’s most impressive 3d models, with a highly detailed cockpit and a large number of modeled systems.

But it just got even better – are you ready for a ride?

New flight dynamics

Richard Harrison has added a detailed JSBSim model for the flight dynamics based on a number of aerodynamical data sources which makes especially the behaviour at low airspeed very close to the real airplane. This also includes an accurate modeling of stall and departure into spin or flat spin and high alpha control reversal. Wing sweep can be controlled manually and affects the behaviour of the plane,

All of the plane’s control systems are implemented in JSBSim rather than in Nasal (which means they are computed at a much higher rate than the framerate), making the response of the plane more fluid, especially at framerates below 30 fps. All in all, the detailed JSBSim FDM adds quite a lot to the flight experience,

Improved systems modeling

The 3d cockpit has received a number of additions, among them a master warning panel with working indicators, an engine control panel and a master generator control panel. Other switches, such as the fuel cutoffs on the glareshield panel, are now functional, such that an engine startup/shutdown procedure from the cockpit is now possible.

Here is an example of the cockpit view in low-level flight:

And the RIO view:

The full range of operations

Just like the previous YaSim version, the new JSBSim F-14b supports a full range of military operations. The plane is fully aircraft-carrier capable (due to the improved modeling of low airspeed behaviour, carrier landings are somewhat more difficult than with the YaSim version though).

The plane also has a detailed radar with several different modes, capable of tracking targets, and the operation of the AIM-9M sidewinder missile is modeled as well as the M61A6 Vulcan gun.

Full air-to-air refueling capability from e.g. the KA-6 is also modeled:

Enjoy the new F-14b along with many exciting new features on current GIT (3.3) or with the forthcoming stable release 3.4!

(All features presented in the screenshots (bluish atmosphere haze, details on the Vinson flightdeck, improved appearance of water,…) are available in the current development version and will be part of the 3.4 release. The screenshots have been taken off the coast of Corsica and over Nevada, both in the default 2.0 World Scenery.)

The FlightGear development team is delighted to announce the v3.2 release of FlightGear, the free, open-source flight simulator. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include an experimental aircraft manager allowing users to download and load aircraft in-sim, a very capable built-in HTTP server, built-in voice synthesizer for ATIS messages, and many improvements to the Canvas rendering framework.

Should Flightgear switch to dds texture format?

What is this about?

The FG development team is considering to switch the format for terrain textures from png to dds. This would offer a number of significant advantages:

– dds is a compressed format, hence the download size of the FG base package may be decreased
– compressed dds can be directly used by many graphics cards, reducing also GPU memory consumption
– dds stores all texture resolution levels, i.e. no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
– the resolution levels (‘mipmaps’) can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use dds for these reasons.

However, the dds compression algorithm is patented, which means that it is not readily available for OpenSource graphics drivers used by Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process dds, for older graphics cards there are non-patented workarounds available which decompress the dds on the software level). The development team is concerned about making the Flightgear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

If there are no problems reported, FG will change defaults to txtures in dds format with the 3.4 release, and then phase out the use of png textures.

What would we need?

Flightgear already provides the simple option to test a dds texture set. If you are running on Linux and especially if you use an OpenSource graphics driver, please take 5 minutes to help during your next FG session:

– Open the dialog under View -> Rendering

– Under ‘Terrain texture scheme’, change the default ‘Region-specific’ to ‘Global alternative (DDS format)’ (see red circle)

– Press ‘Okay’ – FG will reload the terrain

– Do you see proper textures on the terrain (they may look different and may also not fit the location perfectly)? If yes, you’re fine. If you see monochromatic colors or other rendering artifacts, your system may have problems with dds.

– Change back to the texture scheme you like best

– Go to the wiki page and report your experiences, ideally including the graphics card you have and the driver you’re using.

Thanks for your time!

Some context for those interested

The visuals you get to see of the terrain in Flightgear depend on texture scheme and rendering scheme being used.

Simply put, the texture scheme selects a set of texture sheets which are mapped to the various landclasses in the terrain, such that a forest is rendered as forest rather than as grass. The old ‘Global’ texture scheme uses one such set everywhere in the world, the ‘Global alternative’ scheme uses a different set, but the format the textures are stored in is dds rather than png, and the ‘Regional’ scheme selects different textures based on what part of the world you are in. So the texture scheme selection governs things like the basic appearance of the terrain, the format the textures are internally stored in and the definitions where in the world certain textures should be used.

However, modern graphics cards allow to modify textures dynamically, or even create them on the fly by Procedural Texturing using shader effects. Dependent on shader quality level, these effects may have quite a pronounced impact on the visuals. If you are not running Rembrandt, you can switch the main rendering schemes runtime using the ‘Atmospheric Light Scattering’ (ALS) checkbox in the rendering dialog (blue circle in the image above) and explore what it does. So in summary, the rendering scheme selection governs just what is done in detail with the basic texture layers selected above (but, confusingly enough, shader effects may even replace textures).

Some examples exploring the different texture and rendering schemes below:

This is the South Rim of Grand Canyon using regional texture definitions and ALS procedural texturing:

Regional texture definitions allow to adjust the rock color to what is prevalent in the US Southwest, whereas the banded rock structure is not part of the texture file but generated procedurally.

Same scene using global texture definitions and ALS:

Using global textures, the rock and grass color is no longer adapted to the region, and also the shader effect no longer replaces the steepest forest patches by rock.

Same scene using global alternative (DDS) textures and ALS:

Switching to global DDS textures does not alter the visuals significantly in this case, the main difference is the texture format and detail resolution.

Same scene using regional textures and default rendering scheme:

The default rendering scheme at high quality contains some texture replacements which are coded globally into the effect framework and do not mesh too well with the regional texture colors seen elsewhere in the scene.

Same scene using global texture scheme and default rendering scheme:

Such global texture replacements in the shader however work better with a global texture scheme.

Same scene using global alternative DDS texture scheme and default rendering scheme:

Here, the dds texture scheme leads to somewhat different colors.

FG supports this wide variety of textures and rendering schemes so that users can customize the visuals to the performance offered by their computer and select the best compromise between good framerate and compelling visuals.

We need different schemes for this, since in trying to render a scene faithfully, we need to decide questions whether an average level of dust should already be included into textures (as done in the global scheme) or added dynamically according to weather (as done in the regional scheme in procedural texturing). The first alternative is preferable on low-end hardware where procedural texturing is too slow, but the second alternative works much better on high-end systems. Similarly, having different texture schemes allows us to provide a quick fallback for users who might experience problems with a dds-based scheme.