Makelar Pilihan Biner Indonesia: 0x15 Biner Pilihan

Factorio does not starts (how to solve?)

0.001 2020-05-13 18:22:52; Factorio 0.17.79 (build 47865, win64, alpha)
0.002 Operating system: Windows 7 Service Pack 1
0.003 Program arguments: "C:\Users\User\Downloads\Factorio_x64_0.17.79\Factorio_0.17.79\bin\x64\factorio.exe"
0.003 Read data path: C:/Users/UseDownloads/Factorio_x64_0.17.79/Factorio_0.17.79/data
0.003 Write data path: C:/Users/UseDownloads/Factorio_x64_0.17.79/Factorio_0.17.79 [917603/953639MB]
0.003 Binaries path: C:/Users/UseDownloads/Factorio_x64_0.17.79/Factorio_0.17.79/bin
0.013 System info: [CPU: AMD A6-5400K APU with Radeon(tm) HD Graphics, 2 cores, RAM: 2408/7121 MB, page: 3536/14242 MB, virtual: 95/8388607 MB, extended virtual: 0 MB]
0.013 Display options: [FullScreen: 1] [VSync: 1] [UIScale: automatic (100.0%)] [Native DPI: 1] [Screen: 255] [Special: lmw] [Lang: en]
0.016 Available displays: 1
0.017 [0]: \\.\DISPLAY1 - Scheda grafica VGA Standard {0x15, [0,0], 1366x768, 32bit, 1Hz}
Factorio crashed. Generating symbolized stacktrace, please wait ...
c:\cygwin64\tmp\factorio-build-shnskz\src\graphics\sdlwindow.cpp (243): SDLWindow::initializeGraphicsInterface
c:\cygwin64\tmp\factorio-build-shnskz\src\graphics\sdlwindow.cpp (198): SDLWindow::SDLWindow
c:\cygwin64\tmp\factorio-build-shnskz\src\globalcontext.cpp (920): GlobalContext::loadGraphics
c:\cygwin64\tmp\factorio-build-shnskz\src\globalcontext.cpp (464): GlobalContext::init
c:\cygwin64\tmp\factorio-build-shnskz\src\mainloop.cpp (270): MainLoop::run
c:\cygwin64\tmp\factorio-build-shnskz\src\main.cpp (1385): wmain
f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl (288): __scrt_common_main_seh
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 000000007756652D)
000000007756652D (kernel32): (filename not available): BaseThreadInitThunk
ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 000000007779C521)
000000007779C521 (ntdll): (filename not available): RtlUserThreadStart
Stack trace logging done
6.444 Error SDLWindow.cpp:243: Failed to get SDL_DXGIGetOutputInfo. SDL_Error:
Logger::writeStacktrace skipped.
6.444 C:\Users\Adriano\Downloads\Factorio_x64_0.17.79\Factorio_0.17.79\bin\x64\factorio.exe
6.444 C:\Windows\SYSTEM32\ntdll.dll
6.444 C:\Windows\system32\kernel32.dll
6.444 C:\Windows\system32\KERNELBASE.dll
6.444 C:\Windows\system32\WLDAP32.dll
6.444 C:\Windows\system32\msvcrt.dll
6.444 C:\Windows\system32\GDI32.dll
6.444 C:\Windows\system32\USER32.dll
6.444 C:\Windows\system32\LPK.dll
6.444 C:\Windows\system32\USP10.dll
6.444 C:\Windows\system32\ole32.dll
6.444 C:\Windows\system32\RPCRT4.dll
6.444 C:\Windows\system32\WINMM.dll
6.444 C:\Windows\system32\PSAPI.DLL
6.444 C:\Windows\WinSxS\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.17514_none_2b24536c71ed437a\gdiplus.dll
6.444 C:\Windows\system32\SHELL32.dll
6.444 C:\Windows\system32\SHLWAPI.dll
6.444 C:\Windows\system32\IMM32.dll
6.444 C:\Windows\system32\MSCTF.dll
6.444 C:\Windows\system32\OLEAUT32.dll
6.444 C:\Windows\system32\ADVAPI32.dll
6.444 C:\Windows\SYSTEM32\sechost.dll
6.444 C:\Windows\system32\IPHLPAPI.DLL
6.445 C:\Windows\system32\NSI.dll
6.445 C:\Windows\system32\WINNSI.DLL
6.445 C:\Windows\system32\WS2_32.dll
6.445 C:\Windows\system32\CRYPT32.dll
6.445 C:\Windows\system32\MSASN1.dll
6.445 C:\Windows\system32\DSOUND.dll
6.445 C:\Windows\system32\POWRPROF.dll
6.445 C:\Windows\system32\SETUPAPI.dll
6.445 C:\Windows\system32\CFGMGR32.dll
6.445 C:\Windows\system32\DEVOBJ.dll
6.445 C:\Windows\system32\VERSION.dll
6.445 C:\Windows\system32\WINTRUST.dll
6.445 C:\Windows\system32\imagehlp.dll
6.445 C:\Windows\system32\profapi.dll
6.445 C:\Windows\system32\mswsock.dll
6.445 C:\Windows\System32\wshtcpip.dll
6.445 C:\Windows\system32\uxtheme.dll
6.445 C:\Windows\system32\dxgi.dll
6.445 C:\Windows\system32\dwmapi.dll
6.445 C:\Windows\system32\d3d11.dll
6.445 C:\Windows\system32\d3d9.dll
6.445 C:\Windows\system32\d3d8thk.dll
6.445 C:\Windows\system32\d3dcompiler_43.dll
6.445 C:\Windows\system32\CRYPTBASE.dll
6.445 C:\Windows\system32\WindowsCodecs.dll
6.445 C:\Windows\system32\SspiCli.dll
6.445 Error Util.cpp:97: Unexpected error occurred. If you're running the latest version of the game you can help us solve the problem by posting the contents of the log file on the Factorio forums.
Please also include the save file(s), any mods you may be using, and any steps you know of to reproduce the crash.
51.148 Error CrashHandler.cpp:245: Heap validation: success.
51.149 Creating crash dump.
51.366 CrashDump success
submitted by LolerTheGoat to factorio [link] [comments]

Cant passthrough RX 5700 XT

I was trying to passtrough my only gpu but there seems to be a problem with vfio.
CPU: Ryzen 1700X
GPU: Sapphire pulse rx 5700 xt
Mobo: Asus Rog strix X370-F
Bios options: SVM : Enabled, SR-IOV : Disabled
OS: arch , kernel 5.2.11-arch1-1-ARCH
Kernel parameters: "amd_iommu=on iommu=pt loglevel=3 quiet"

mkinitcpio.conf (comments are ommited)
MODULES=(vfio_pci vfio vfio_iommu_type1 vfio_virqfd) BINARIES=() FILES=() HOOKS=(base udev autodetect modconf block filesystems keyboard fsck) 
/etc/modprobe.d/vfio.conf
options vfio_pci ids=1002:731f,1002:ab38 
iommu groups
IOMMU Group 0: 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] IOMMU Group 1: 00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge [1022:1453] IOMMU Group 10: 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Internal PCIe GPP Bridge 0 to Bus B [1022:1454] IOMMU Group 11: 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 59) 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] (rev 51) IOMMU Group 12: 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 0 [1022:1460] 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 1 [1022:1461] 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 2 [1022:1462] 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 3 [1022:1463] 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 4 [1022:1464] 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 5 [1022:1465] 00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 6 [1022:1466] 00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 7 [1022:1467] IOMMU Group 13: 01:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 [144d:a808] IOMMU Group 14: 02:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] X370 Series Chipset USB 3.1 xHCI Controller [1022:43b9] (rev 02) 02:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] X370 Series Chipset SATA Controller [1022:43b5] (rev 02) 02:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] X370 Series Chipset PCIe Upstream Port [1022:43b0] (rev 02) 03:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02) 03:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02) 03:03.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02) 03:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02) 03:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02) 03:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02) 04:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller [1b21:1242] 05:00.0 Ethernet controller [0200]: Intel Corporation I211 Gigabit Network Connection [8086:1539] (rev 03) IOMMU Group 15: 0a:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:1478] (rev c1) IOMMU Group 16: 0b:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:1479] IOMMU Group 17: 0c:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5700 / 5700 XT] [1002:731f] (rev c1) IOMMU Group 18: 0c:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 HDMI Audio [1002:ab38] IOMMU Group 19: 0d:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Zeppelin/Raven/Raven2 PCIe Dummy Function [1022:145a] IOMMU Group 2: 00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge [1022:1453] IOMMU Group 20: 0d:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Platform Security Processor [1022:1456] IOMMU Group 21: 0d:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) USB 3.0 Host Controller [1022:145c] IOMMU Group 22: 0e:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Zeppelin/Renoir PCIe Dummy Function [1022:1455] IOMMU Group 23: 0e:00.2 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] [1022:7901] (rev 51) IOMMU Group 24: 0e:00.3 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) HD Audio Controller [1022:1457] IOMMU Group 3: 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] IOMMU Group 4: 00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] IOMMU Group 5: 00:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge [1022:1453] IOMMU Group 6: 00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] IOMMU Group 7: 00:07.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] IOMMU Group 8: 00:07.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Internal PCIe GPP Bridge 0 to Bus B [1022:1454] IOMMU Group 9: 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] 
xml
 win10 facb7abd-ac3e-4a04-8e86-d6944b62d723      8388608 8388608 16  hvm /usshare/ovmf/x64/OVMF_CODE.fd /valib/libvirt/qemu/nvram/win10_VARS.fd                      destroy restart destroy      /usbin/qemu-system-x86_64     
Output of "dmesg | grep vfio" before starting vm
[ 1.279191] vfio-pci 0000:0c:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 1.293682] vfio_pci: add [1002:731f[ffffffff:ffffffff]] class 0x000000/00000000 [ 1.310411] vfio_pci: add [1002:ab38[ffffffff:ffffffff]] class 0x000000/00000000 
full output: https://pastebin.com/UVaxAWWU

Output of "dmesg | grep vfio" after starting vm
[ 1.279191] vfio-pci 0000:0c:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 1.293682] vfio_pci: add [1002:731f[ffffffff:ffffffff]] class 0x000000/00000000 [ 1.310411] vfio_pci: add [1002:ab38[ffffffff:ffffffff]] class 0x000000/00000000 [ 358.866916] vfio-pci 0000:0c:00.0: vfio_ecap_init: hiding ecap [email protected] [ 358.866927] vfio-pci 0000:0c:00.0: vfio_ecap_init: hiding ecap [email protected] [ 358.866930] vfio-pci 0000:0c:00.0: vfio_ecap_init: hiding ecap [email protected] [ 358.866931] vfio-pci 0000:0c:00.0: vfio_ecap_init: hiding ecap [email protected] [ 358.866933] vfio-pci 0000:0c:00.0: vfio_ecap_init: hiding ecap [email protected] [ 358.867808] vfio-pci 0000:0c:00.0: BAR 0: can't reserve [mem 0xe0000000-0xefffffff 64bit pref] [ 361.571367] vfio-pci 0000:0c:00.0: No more image in the PCI ROM [ 361.571388] vfio-pci 0000:0c:00.0: No more image in the PCI ROM 
full output: https://pastebin.com/VyxF9Y88

Since I only have one gpu I am forwarding X11 to a laptop and running virt-manager from there, windows starts and works fine but on my main display I only get a blinking cursor after starting the vm.

Edit: Thanks to u/cybervseas and this post https://www.reddit.com/VFIO/comments/7kpw33/cant_passthrough_boot_gpu_did_i_miss_something/ I got the vm working.
I added a line to the xml file that points to the rom file to be used. You can get that file from https://www.techpowerup.com/vgabios/ , download gpu-z and dump it or any other way to get the rom of your gpu.
    
The last thing was changing some settings in grub. I added the kernel parameter 'nofb' and changed GRUB_GFXPAYLOAD from 'keep' to 'text' in the file at /etc/default/grub.
Everything seems to work now I am writing this from inside the vm and I had no problems with the driver installation it works the same way as if windows was the host os.
submitted by diogo464 to VFIO [link] [comments]

Game NCCH and CDN Encryption (an explanation)

Game and CDN Encryption

Overview

There's been a lot of misinformation going around since the Sun/Moon demo's been announced, and I've come to realize people really don't understand how game encryption works on the 3DS.
I'd like to try to correct that.
Please note that the earlier parts of this post have been plagiarized liberally from topkeknosnek's wonderful explanation of the eShop and CDN's encryption.
The parts past CDN encryption are less plagiarized.
(To skip the bits that aren't relevant for physical game cartridges, jump to step 4.)

Overview

Very abstractly spoken, this is what happens when you purchase and download a game from the eShop:
  1. The game is purchased via eShop.
  2. eShop causes the download and installation of the ticket for the title.
  3. 3DS downloads the tmd and CDN contents.
  4. (3a) 3DS decrypts and installs the CDN contents.
  5. (3b) 3DS verifies the SHA-256 hash of the decrypted CDN contents.
You probably barely got any of that, so let's break it down.

Step 1: eShop Title Purchase

First, the game to download needs to be purchased.
Some terminology: eShop games are called "titles". The term "titles" is broader than that, however, and includes every part of the system firmware, such as NATIVE_FIRM or the HOME Menu.
The eShop application on the 3DS ("tiger") sends a request to the eShop server called ninja -- there are multiple eShop servers, but ninja is the relevant one for purchase-related things. In that request, tiger asks for purchase of a certain title.
ninja then verifies whether tiger is actually authenticated and if the associated account has the required balance. If not, an error is returned to tiger. If yes, the purchase is processed and tiger is notified about that. From then on, the respective title is associated with its respective NNID.

Step 2: Ticket Download

Once the eShop has been notified of the successful purchase, it calls the nim system module to download and install the ticket for the purchased title. The nim service is a service in the 3DS's firmware that handles downloading and installing CDN contents, including the firmware itself.

Tickets

A ticket describes a digital entitlement to a certain CDN content. A ticket can be either unique, in which case it contains a console ID and an eShop account ID. Or it can be a cetk (Common E-Ticket), which is valid for all consoles.
Of particular interest in a ticket is the titlekey. The titlekey is an encryption key that is used to decrypt the CDN contents. Guessing it blindly (brute forcing it) is currently considered computationally infeasible.
Furthermore, a ticket contains the amount of times a title can be launched. This is effectively only used for demos. The current amount of times the title can be launched, however, is kept track of by the HOME Menu. For this reason, HANS, regionthree and similar launchers can bypass the demo launch limit.
Tickets are always signed by Nintendo (RSA-2048 over a SHA-256 hash with PKCS#1 padding), meaning they cannot be forged. This signature is also checked every time the title is launched. Finding the private key to the public key is currently considered computationally infeasible.

Step 3: TMDs and Contents

Once the ticket has been installed, nim will then download and install the title. This is done in two steps: Downloading and verifying the TMD, then downloading and verifying the CDN contents.

Step 3a: TMD

First, nim downloads the TMD for a given title.
A TMD (title metadata) contains information about the contents themselves: The number of contents and their respective SHA-256 hashes.
TMDs are always signed by Nintendo (RSA-2048 over a SHA-256 hash with PKCS#1 padding), meaning they cannot be forged.

Step 3b: Contents

Once the TMD has been obtained, nim proceeds to download the contents described in the TMD.
All contents on the CDN have a layer of encryption around them (AES-128-CBC; the IV is the content index as described by the TMD, then 14 bytes of zeroes are appended). This is sometimes called the "outer" encryption because contents themselves can have encryption inside as well.
A content is just an NCCH after decryption. An NCCH is, simply put, something the 3DS can work with: A bundle of resources (CFA, CTR File Archive, such as the digital manuals) or an executable (CXI, CTR eXecutable Image).
While nim downloads, decrypts and installs the contents, it also hashes the contents (SHA-256). Hashing is the process of taking an input of arbitrary length and getting a fixed-length (hopefully unique) number. Finding the file that belongs to a hash, or a different file that has the same hash, is -- for a good hash function -- computationally infeasible. Spoiler: SHA-256 is a good hash function.
If the SHA-256 of any one of the decrypted contents mismatches the hash in the TMD (which is signed), nim fails the installation and removes the partially installed title.

Step 4: NCCH Decryption

As mentioned before, a game consists of one or more NCCH archives, where an NCCH is a special type of archive that the console knows how to work with.
Game decryption consists of validating the NCCH's signatures, and then decrypting its various partitions.
An NCCH generally consists of the following partitions:
The encrypted partitions can, optionally, be stored decrypted instead, but no commercial title would ever elect to make use of that option (for obvious reasons), so I will be assuming NCCHs are always encrypted for the remainder of this post.
It's also worth nothing that the three additional partitions are all optional -- manuals have no Extended Header or ExeFS, for example.

Step 4a: NCCH signature verification

The first 256 bytes of any NCCH consists of an RSA-2048 signature over the SHA-256 hash of the remaining 256-bytes of the header. This signature, as with all RSA-2048 signatures, is computationally infeasible to break, and so verifies the validity of the following header metadata.
Once the NCCH's header has been verified, the system will proceed to read the metadata for the other partitions, and decrypt them to verify their SHA-256 hashes, which are stored in the header.

Step 4b: NCCH partition decryption

NCCH partitions are encrypted with one of (as of October 9th, 2016) five (really six) possible key derivation schemes. Sound confusing? It is. The system originally only had two schemes, but as they were cracked and the system began to be penetrated by homebrew users, Nintendo cooked up new and more complex schemes to prevent unauthorized users from decrypting NCCH contents.
Once the key has been derived, though, NCCH decryption is relatively simple -- each partition is protected by AES-CTR encryption, using the Title ID and Partition type (Extended Header, ExeFS, or RomFS) as a CTInitialization Vector. As such, I'll mostly be focused on explaining the various key derivation schemes, as they're the meat of how NCCH files are protected.

Scheme 0: Fixed-key encryption

The first, and simplest key derivation scheme. Used presumably for testing in the early stages of the 3DS's development and for legacy support, partitions are protected using a key that consists entirely of zeros. This is not very secure, obviously, and so titles that use this encryption method can be easily decrypted on a PC. This isn't really used by anything, but it merits mentioning because it's the key scheme Gateway allowed users to use when they began to allow users to run homebrew from their red cart, way back in the early days of the scene. Scheme 0 is also the type of encryption used by the SDK for testing games on dev units.

Scheme 1: Secure1 encryption

The second key derivation scheme, and the simplest of the ones that do real key derivation. Before I can explain how it works, one should know that the 3DS has a hardware engine devoted to doing AES encryption and decryption which also serves a second purpose as a "Keyscrambler". The keyscrambler, originally introduced with the DSi, allows Nintendo to "mix" two keys together to calculate a third key. The keyscrambler is write-only -- which means that even though you can use the secret keys made by scrambling together two input keys, you can't read them or learn what they are. The hardware engine also has some number of keyslots, each of which is devoted to a particular kind of encryption, so that it can keep track of many mixed-together secret keys without removing access to the others.
Some terminology:
With that out of the way, Secure1 uses a fairly basic method to derive the secret encryption key. The bootrom (the unchangable code that runs early in the console's boot, which locks access to itself away as soon as it's done executing) initializes the 44th (0x2C) keyslot by writing secret data to the KeyX. When an NCCH using Secure1 needs to decrypt one of its partitions, it writes the first 16 bytes from the header's signature to the KeyY, and uses the resulting secret key to decrypt the partition's contents. This is clever, because using part of the signature to calculate the secret key discourages an attacker from trying to modify the signature -- doing so would make the partitions decrypt incorrectly!
Secure1 is a good scheme. That said, when the system was first compromised at the Kernel9 level, Nintendo realized people could decrypt titles and worked to create a new scheme that would keep content safe even with the system itself compromised.

Scheme 2: Secure2 encryption

The third key derivation scheme, introduced with firmware 7.0. Having realized that Secure1 had been compromised due to the 4.5 ARM9 exploits, Nintendo implemented this scheme to prevent content decryption without a new ARM9 exploit on higher firmwares. They accomplished this fairly ingeniously: the bootrom, in addition to initializing the hardware keyslots, initializes some RSA data that went unused, and got overwritten later on during the firmware's bootup process. Nintendo added code that runs early on in the firmware boot that checks whether this RSA data is still present. If so, firmware will perform RSA encryption on some static data, then hash the resulting encrypted data with SHA-256. The second 16 bytes of this SHA-256 hash is then used to initialize the 37th (0x25) keyslot's KeyX, and firmware will overwrite the RSA data to prevent its being used after the system is fully booted up.
Secure2 decryption proceeds much the same way as Secure1, afterwards. The Extended header and ExeFS still largely use keyslot 0x2C for encryption using the Secure1 secret key methodology. However, the ExeFS's code binary and RomFS get special treatment -- they use keyslot 0x25 instead of keyslot 0x2C.
That scheme was, for a while, secure -- the data is already overwritten by the time attackers got ARM9 code execution on 4.0. Since the Extended header, and title's 3D banneicon still use the old form of encryption, to an older system the title will display correctly in the home menu, but when it comes time for the title to launch the game's code and RomFS will fail to decrypt correctly -- and thus Nintendo achieved backwards compatibility while keeping the important bits of a title's content secure and out of the hands of unauthorized users.
However, Gateway got a hold of the data used to initialize keyslot 0x25 somehow. Nobody's actually sure how this happened! Gateway's obtaining the key meant, though, that they included it in their exploit, and it was eventually extracted and leaked to the public by an anonymous user known as "K" on October 25th, 2014. Nintendo's sytem was thus once more insecure -- and so they needed to fix that.

Scheme 3: Secure3 encryption

With the release of the N3DS, Nintendo added a new, N3DS-exclusive encryption method in Secure3. The N3DS, as anyone who uses A9LH will know, added a new 512-byte sector of encrypted secret data to the console's NAND, and a new loader to firmware. This loader decrypted the first 16-bytes of the secret sector using the SHA-256 hash of first 144 bytes from the console's OTP data, initializes a temporary (0x11) keyslot with those first 16-bytes, then locks out access to the OTP. It then verifies the key it read from NAND, uses the temporary keyslot to decrypt some static data to initialize the 21st (0x15) keyslot and other static data to initialize the 24th (0x18) through the 31st (0x1F) keyslots, then uses keyslot 0x15 to decrypt the rest of the N3DS's firmware.
Secure3 encryption works exactly the same as Secure2 encryption, except where Secure2 would use keyslot 0x25, Secure3 uses keyslot 0x18.
This scheme was, once more, seemingly secure -- as far as Nintendo knew, nobody could access the OTP, and thus nobody could decrypt the secret data in NAND to get the new NCCH key. However, Nintendo made a mistake -- the close reader will notice they forgot to clear their temporary keyslot 0x11 after using it, and so once people gained ARM9 code execution on a New 3DS, they could use keyslot 0x11 to decrypt firmware and regenerate the missing keys, once more breaking nintendo's scheme. Nintendo fixed this in their 9.6 update, introducing their next two schemes.

Scheme 4: Secure4 encryption

Introduced in Firmware 9.6.0, Nintendo sought to fix their mistake in Secure3 by using a different set of 16 bytes from the encrypted secret data in NAND to decrypt firmware and calculate further encryption keys. They did this by initializing their temporary keyslot 0x11 with the second 16-bytes from the secret sector the same way they did with the first 16, then lock out the OTP. They then use the temporary keyslot to decrypt some static data to initialize the 22nd (0x16) keyslot and other static data to initialize the 25th (0x19) through the 31st (0x1F) keyslots, then uses keyslot 0x16 to decrypt the rest of the N3DS's firmware (They leave the 24th keyslot initialized the same way as before, to retain compatibility with Secure3-protected titles). They also properly clear their temporary keyslot (0x11) when done.
Secure4 encryption works as Secure3 and Secure2 do, except using keyslot 0x1B in place of 0x18/0x25.
This scheme was secure for a long while. However, people eventually noticed that Nintendo made a fatal flaw in their implementation -- they forgot to verify keyslot 0x16 before using it to decrypt firmware. The secret sector was leaked on pastebin by an anonymous user known as "K" on January 12th, 2016, and, thus, by random brute force or by obtaining OTP, one can replace the key in NAND with a calculated one to gain pre-kernel code access on N3DS or O3DS known usually as "arm9loaderhax", sometimes "kernel9loaderhax", and occasionally to the very stupid as "Gateway Fast-Boot". Arm9loaderhax breaks Secure4 entirely -- and prevents Nintendo from ever using the secret sector again for additional encryption schemes, and from using other miscellaneous bootrom-initialized data. It also enables the user to calculate the key used for Secure2 encryption, though as it was leaked there's not much point to doing this. It also enables some other cool stuff with custom firmware, but from an encryption perspective that's relatively uninteresting and outside of the scope of this post.

Scheme 5: Seed encryption

Introduced alongside Secure4, Seed encryption isn't actually separate from the other schemes! It can be used alongside Secure2, Secure3, or Secure4, as an additional protection layer for certain titles. The motivation behind Seed encryption was that Nintendo wanted to allow users to purchase titles and download them in advance of their release date, but not let users play them before release date arrived. The old encryption methods had no way to support this -- purchasing a title gives its titlekey, which enables decryption, and once a title has been decrypted none of the schemes had any concept of release date protection -- they just use the first 16 bytes NCCH signature mixed with some other secret data (varying by Secure# scheme) to derive the secret key.
Seed encryption fixes this problem. Nintendo added a new server ("kagiya") to their CDN which stores 16-byte "external seeds", also known as "content lock seeds", "ext seeds", "ext keys", and any number of other names. These seeds are unique to each title that uses the encryption scheme. If a title uses seed encryption, then whenever it is launched Nintendo will attempt to retrieve the title's seed from SEEDDB. Failing that, the user will be prompted to download a "small update" from the eShop, which consists of the console trying to retrieve the seed from kagiya, and storing the seed in SEEDDB for future easy access.
Supposing the console succeeds in retrieving the seed from SEEDDB, it will then calculate the SHA256 hash of the first 16 bytes of the NCCH's signature and the 16 byte external seed. If the partition being decrypted would use Secure1's keyslot 0x2C, decryption proceeds per normal. However, if the partition is code or the title's RomFS, the system will instead use this SHA256 hash as the KeyY for whatever keyslot the secondary encryption scheme would use (0x25 for Secure2, 0x18 for Secure3, and 0x1B for Secure4).
This scheme adds no security after a title's release date, but it enables exactly the pre-purchasing behavior Nintendo wanted -- Nintendo can hold off on releasing the external seed for a title until its release date, while allowing users to purchase the title beforehand. Purchasing the title will let users download the title to their console and decrypt the CDN contents with the titlekey -- users can also preview the icon and 3d banner, as they will use the old 0x2C Secure1 encryption. However, because code and RomFS partitions will use a secret key that requires the content seed to calculate, they cannot be accessed prior to release date when Nintendo publishes the title's seed to their Kagiya server.

Practical Impact

All Secure# methods have been broken, at this point. Anyone with a console and arm9loaderhax can make use of the 3ds's hardware AES engine to decrypt content using any of the Secure1/2/3/4 schemes. Further, Nintendo cannot introduce new schemes, as there is no bootrom-initialized data that a future kernel9loader could access that vulnerable versions can't similarly access. Introducing a new scheme would require a new hardware revision, and with the NX on the horizon that seems unlikely to happen.
However, you may notice that Secure2/3/4 use calculated data for their KeyX, whereas Secure1 uses bootrom-initialized data. This means, in practice, that since the 3DS's keyscrambler algorithm was broken at 32c3 by yellows8 and plutoo, we can calculate the scrambled secret keys for those schemes on our PCs without any need for a console. Ironically, this means Secure1 is actually more secure than Secure2/Secure3/Secure4 -- any titles making use of later schemes can have their code and RomFSs be decrypted on PC, but Secure1 can only be decrypted by making use of a hacked 3DS console. Nintendo would actually be better off by no longer using Secure2/3/4, and by switching back exclusively to Secure1, which will remain permanently secure unless the 3DS's bootrom somehow gets dumped.
Further, seed encryption prevents titles from being played ahead of their release dates even if their titlekys are public knowledge. This means that when, for example, Pokemon Sun and Moon become available for prepurchase in the next month, even though their titlekeys will be public and usable with piracy tools the games won't be playable or capable of being decrypted before the official release date.
It is worth nothing, however, seed encryption is for downloadable eShop titles only -- no physical cartridge will ever make use of it.

And a bit of trivia

Even though content lock seeds should never be published ahead of time, Nintendo can be a bit careless with them -- they're fairly often released when they shouldn't be, enabling pre-release date access to some games. The Legend of Zelda: Triforce Heroes, for example, had its content lock seed published a month before its release date, despite being pre-purchasable. This meant that anyone who was paying attention could have been playing that game several weeks in advance, though I don't know that anyone publically exploited this.
submitted by SciresM to 3dshacks [link] [comments]

Using different Linux and now get undefined reference to boost::system even though it exists

I am using Ubuntu whereas the previous computer I worked on used a different version of Linux. I have a project in C++ using Cmake. I'm rather new to Linux and Unix so I don't understand the errors I'm getting and how to fix them. When I type make I get:
Linking CXX executable ../../bin/MyProgram ../../lib/libMP.a(MPL.cpp.o): In function `_GLOBAL__sub_I_mult_fmm2': MPL.cpp:(.text.startup+0x15): undefined reference to `boost::system::generic_category()' MPL.cpp:(.text.startup+0x1a): undefined reference to `boost::system::generic_category()' MPL.cpp:(.text.startup+0x1f): undefined reference to `boost::system::system_category()' ../../lib/libThing.a(vases.cpp.o): In function `_GLOBAL__sub_I__ZN9Thing6VasesC2ERKN3Two9DimensionENS1_8DataTypeE': Vases.cpp:(.text.startup+0x15): undefined reference to `boost::system::generic_category()' Vases.cpp:(.text.startup+0x1a): undefined reference to `boost::system::generic_category()' Vases.cpp:(.text.startup+0x1f): undefined reference to `boost::system::system_category()' ... ../../lib/libThing.a(HDF5_IO.cpp.o): In function `Thing::HDF5_IO::createVolumeFile(std::__cxx11::basic_string, std::allocator > const&, Two::GenericBoundingBox const&, Two::Dimension const&, std::vector > const&, unsigned int, unsigned int, double, double) const': HDF5_IO.cpp:(.text+0x79c5): undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)' ../../lib/libThing.a(HDF5_IO.cpp.o): In function `Thing::HDF5_IO::writeVolumeFile(Thing::Volume const&, std::__cxx11::basic_string, std::allocator > const&, unsigned int, unsigned int, unsigned long, unsigned long, unsigned long, bool) const': HDF5_IO.cpp:(.text+0x97d1): undefined reference to `boost::thread::start_thread_noexcept()' HDF5_IO.cpp:(.text+0x9b77): undefined reference to `boost::thread::join_noexcept()' HDF5_IO.cpp:(.text+0x9fbb): undefined reference to `boost::thread::join_noexcept()' ... 
and my link.txt file looks like
/usbin/g++ -O3 -O3 -DNDEBUG CMakeFiles/MyProject.dimain.cpp.o -o ../../bin/MyProject -L/home/myname/Desktop/MyProject/build/lib -rdynamic -lboost_thread-mt -lboost_date_time-mt -lboost_regex -lboost_filesystem-mt -lboost_program_options-mt ../../lib/libfftw3.a -lxcb -lXau -lXext -lX11 -lpetsc -lmpich -lmpl -lrt ../../lib/libflapack.a -lgfortran ../../lib/libfblas.a -lgfortran ../../lib/libMyProjectAPI.a -lfftw3 -lGLU -lGL -lpthread ../../lib/libfftw3.a -lxcb -lXau -lX11 -lpetsc -lmpich -lmpl -lrt ../../lib/libflapack.a -lgfortran ../../lib/libfblas.a -lgfortran ../../lib/libfblas.a -lpthread -lboost_thread-mt -lboost_date_time-mt -lboost_regex -lboost_filesystem-mt -lboost_system-mt -lboost_program_options-mt /home/myname/anaconda2/lib/libhdf5.so /home/myname/anaconda2/lib/libhdf5_hl.so -lrt /home/myname/anaconda2/lib/libz.so -ldl -lm /home/myname/anaconda2/lib/libhdf5_cpp.so /home/myname/anaconda2/lib/libhdf5_hl_cpp.so /home/myname/anaconda2/lib/libhdf5.so /home/myname/anaconda2/lib/libhdf5_hl.so -lrt /home/myname/anaconda2/lib/libz.so -ldl -lm /home/myname/anaconda2/lib/libhdf5_cpp.so /home/myname/anaconda2/lib/libhdf5_hl_cpp.so -Wl,-rpath,/home/myname/Desktop/MyProject/build/lib:/home/myname/anaconda2/lib 
Anyone know how to solve this? If I replace -lboost_system-mtwith ../../lib/libboost_system-mt.a then I get the same error. And I see that in /home/myname/Desktop/MyProject/build/lib that libboost_system-mt.a clearly exists, so removing the -mt is not the problem.
I think the problem is because I'm trying to link the executable against libraries built with another compiler. I'm using g++ 5.2 and boost is already installed in usinclude. The program code I'm using has those libboost files in /home/myname/Desktop/MyProject/build/lib. I got this code to work properly on an original computer, but am now having these linker errors on my new computer. That original computer used g++ on I think version 4.8
I already installed libboost-system-dev on my new computer and it says I already have the latest version. However, locate libboost_system-mt.a shows that libboost_system-mt.a is not in uslib but only in /home/myname/Desktop/MyProject/build/lib
My makefiles contents are below: http://pastebin.com/eyVsg52R for makefile in /home/myname/Desktop/MyProject/build http://pastebin.com/sgSFAmsF for makefile in /home/myname/Desktop/MyProject/
I did notice in that second makefile that CMAKE_COMMAND is referring to gcc-4.6 and the different version of linux, which were for my original computer. I'm now using gcc-5.2 on a different version of Linux. _SOURCE_DIR and _BINARY_DIR are also set to the directory in my previous computer and not my current one. Do I need to modify these so they point to the directories in my current computer? I just tried to modify them to the correct directories in my new computer (such as changing CMAKE_COMMAND = /opt/olddirectory/cmake/cmake-2.8.9/oldlinuxversion/gcc-4.6/bin/cmake to CMAKE_COMMAND = /usbin/cmake), but I still get the same error when I type make in the build directory
submitted by iwant2believe3 to linux4noobs [link] [comments]

Undefined reference errors due to problem with makefile linkage?

I am using Ubuntu whereas the previous computer I worked on used a different version of Linux. I have a project in C++ using Cmake. I'm rather new to Linux and Unix so I don't understand the errors I'm getting and how to fix them. When I type make I get:
Linking CXX executable ../../bin/MyProgram ../../lib/libMP.a(MPL.cpp.o): In function `_GLOBAL__sub_I_mult_fmm2': MPL.cpp:(.text.startup+0x15): undefined reference to `boost::system::generic_category()' MPL.cpp:(.text.startup+0x1a): undefined reference to `boost::system::generic_category()' MPL.cpp:(.text.startup+0x1f): undefined reference to `boost::system::system_category()' ../../lib/libThing.a(vases.cpp.o): In function `_GLOBAL__sub_I__ZN9Thing6VasesC2ERKN3Two9DimensionENS1_8DataTypeE': Vases.cpp:(.text.startup+0x15): undefined reference to `boost::system::generic_category()' Vases.cpp:(.text.startup+0x1a): undefined reference to `boost::system::generic_category()' Vases.cpp:(.text.startup+0x1f): undefined reference to `boost::system::system_category()' ... ../../lib/libThing.a(HDF5_IO.cpp.o): In function `Thing::HDF5_IO::createVolumeFile(std::__cxx11::basic_string, std::allocator > const&, Two::GenericBoundingBox const&, Two::Dimension const&, std::vector > const&, unsigned int, unsigned int, double, double) const': HDF5_IO.cpp:(.text+0x79c5): undefined reference to `boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)' ../../lib/libThing.a(HDF5_IO.cpp.o): In function `Thing::HDF5_IO::writeVolumeFile(Thing::Volume const&, std::__cxx11::basic_string, std::allocator > const&, unsigned int, unsigned int, unsigned long, unsigned long, unsigned long, bool) const': HDF5_IO.cpp:(.text+0x97d1): undefined reference to `boost::thread::start_thread_noexcept()' HDF5_IO.cpp:(.text+0x9b77): undefined reference to `boost::thread::join_noexcept()' HDF5_IO.cpp:(.text+0x9fbb): undefined reference to `boost::thread::join_noexcept()' ... 
and my link.txt file looks like
/usbin/g++ -O3 -O3 -DNDEBUG CMakeFiles/MyProject.dimain.cpp.o -o ../../bin/MyProject -L/home/myname/Desktop/MyProject/build/lib -rdynamic -lboost_thread-mt -lboost_date_time-mt -lboost_regex -lboost_filesystem-mt -lboost_program_options-mt ../../lib/libfftw3.a -lxcb -lXau -lXext -lX11 -lpetsc -lmpich -lmpl -lrt ../../lib/libflapack.a -lgfortran ../../lib/libfblas.a -lgfortran ../../lib/libMyProjectAPI.a -lfftw3 -lGLU -lGL -lpthread ../../lib/libfftw3.a -lxcb -lXau -lX11 -lpetsc -lmpich -lmpl -lrt ../../lib/libflapack.a -lgfortran ../../lib/libfblas.a -lgfortran ../../lib/libfblas.a -lpthread -lboost_thread-mt -lboost_date_time-mt -lboost_regex -lboost_filesystem-mt -lboost_system-mt -lboost_program_options-mt /home/myname/anaconda2/lib/libhdf5.so /home/myname/anaconda2/lib/libhdf5_hl.so -lrt /home/myname/anaconda2/lib/libz.so -ldl -lm /home/myname/anaconda2/lib/libhdf5_cpp.so /home/myname/anaconda2/lib/libhdf5_hl_cpp.so /home/myname/anaconda2/lib/libhdf5.so /home/myname/anaconda2/lib/libhdf5_hl.so -lrt /home/myname/anaconda2/lib/libz.so -ldl -lm /home/myname/anaconda2/lib/libhdf5_cpp.so /home/myname/anaconda2/lib/libhdf5_hl_cpp.so -Wl,-rpath,/home/myname/Desktop/MyProject/build/lib:/home/myname/anaconda2/lib 
Anyone know how to solve this? If I replace -lboost_system-mtwith ../../lib/libboost_system-mt.a then I get the same error. And I see that in /home/myname/Desktop/MyProject/build/lib that libboost_system-mt.a clearly exists, so removing the -mt is not the problem.
I think the problem is because I'm trying to link the executable against libraries built with another compiler. I'm using g++ 5.2 and boost is already installed in usinclude. The program code I'm using has those libboost files in /home/myname/Desktop/MyProject/build/lib. I got this code to work properly on an original computer, but am now having these linker errors on my new computer. That original computer used g++ on I think version 4.8
I already installed libboost-system-dev on my new computer and it says I already have the latest version. However, locate libboost_system-mt.a shows that libboost_system-mt.a is not in uslib but only in /home/myname/Desktop/MyProject/build/lib
My makefiles contents are below: http://pastebin.com/eyVsg52R for makefile in /home/myname/Desktop/MyProject/build http://pastebin.com/sgSFAmsF for makefile in /home/myname/Desktop/MyProject/
I did notice in that second makefile that CMAKE_COMMAND is referring to gcc-4.6 and the different version of linux, which were for my original computer. I'm now using gcc-5.2 on a different version of Linux. _SOURCE_DIR and _BINARY_DIR are also set to the directory in my previous computer and not my current one. Do I need to modify these so they point to the directories in my current computer? I just tried to modify them to the correct directories in my new computer (such as changing CMAKE_COMMAND = /opt/olddirectory/cmake/cmake-2.8.9/oldlinuxversion/gcc-4.6/bin/cmake to CMAKE_COMMAND = /usbin/cmake), but I still get the same error when I type make in the build directory
submitted by iwant2believe3 to linuxquestions [link] [comments]

Adafruit Space Invader pendant. Want to convert to using a bicolor 1.2 led matrix. How would the code change?

 // Trinket/Gemma + LED matrix backpack jewelry. Plays animated // sequence on LED matrix. Press reset button to display again, // or add optional momentary button between pin #1 and +V. // THERE IS NO ANIMATION DATA IN THIS SOURCE FILE, you should // rarely need to change anything here. EDIT anim.h INSTEAD. #define BRIGHTNESS 14 // 0=min, 15=max #define I2C_ADDR 0x70 // Edit if backpack A0/A1 jumpers set #include  #include  #include  #include "anim2.h" // Animation data is located here #include "anim3.h" // Animation data is located here #include "anim4.h" // Animation data is located here static const uint8_t PROGMEM reorder[] = { // Column-reordering table 0x00,0x40,0x20,0x60,0x10,0x50,0x30,0x70,0x08,0x48,0x28,0x68,0x18,0x58,0x38,0x78, 0x04,0x44,0x24,0x64,0x14,0x54,0x34,0x74,0x0c,0x4c,0x2c,0x6c,0x1c,0x5c,0x3c,0x7c, 0x02,0x42,0x22,0x62,0x12,0x52,0x32,0x72,0x0a,0x4a,0x2a,0x6a,0x1a,0x5a,0x3a,0x7a, 0x06,0x46,0x26,0x66,0x16,0x56,0x36,0x76,0x0e,0x4e,0x2e,0x6e,0x1e,0x5e,0x3e,0x7e, 0x01,0x41,0x21,0x61,0x11,0x51,0x31,0x71,0x09,0x49,0x29,0x69,0x19,0x59,0x39,0x79, 0x05,0x45,0x25,0x65,0x15,0x55,0x35,0x75,0x0d,0x4d,0x2d,0x6d,0x1d,0x5d,0x3d,0x7d, 0x03,0x43,0x23,0x63,0x13,0x53,0x33,0x73,0x0b,0x4b,0x2b,0x6b,0x1b,0x5b,0x3b,0x7b, 0x07,0x47,0x27,0x67,0x17,0x57,0x37,0x77,0x0f,0x4f,0x2f,0x6f,0x1f,0x5f,0x3f,0x7f, 0x80,0xc0,0xa0,0xe0,0x90,0xd0,0xb0,0xf0,0x88,0xc8,0xa8,0xe8,0x98,0xd8,0xb8,0xf8, 0x84,0xc4,0xa4,0xe4,0x94,0xd4,0xb4,0xf4,0x8c,0xcc,0xac,0xec,0x9c,0xdc,0xbc,0xfc, 0x82,0xc2,0xa2,0xe2,0x92,0xd2,0xb2,0xf2,0x8a,0xca,0xaa,0xea,0x9a,0xda,0xba,0xfa, 0x86,0xc6,0xa6,0xe6,0x96,0xd6,0xb6,0xf6,0x8e,0xce,0xae,0xee,0x9e,0xde,0xbe,0xfe, 0x81,0xc1,0xa1,0xe1,0x91,0xd1,0xb1,0xf1,0x89,0xc9,0xa9,0xe9,0x99,0xd9,0xb9,0xf9, 0x85,0xc5,0xa5,0xe5,0x95,0xd5,0xb5,0xf5,0x8d,0xcd,0xad,0xed,0x9d,0xdd,0xbd,0xfd, 0x83,0xc3,0xa3,0xe3,0x93,0xd3,0xb3,0xf3,0x8b,0xcb,0xab,0xeb,0x9b,0xdb,0xbb,0xfb, 0x87,0xc7,0xa7,0xe7,0x97,0xd7,0xb7,0xf7,0x8f,0xcf,0xaf,0xef,0x9f,0xdf,0xbf,0xff }; int animationSection = 0; void ledCmd(uint8_t x) { // Issue command to LED backback driver Wire.beginTransmission(I2C_ADDR); Wire.write(x); Wire.endTransmission(); } void clear(void) { // Clear display buffer Wire.beginTransmission(I2C_ADDR); for(uint8_t i=0; i<17; i++) Wire.write(0); Wire.endTransmission(); } void setup() { power_timer1_disable(); // Disable unused peripherals power_adc_disable(); // to save power PCMSK |= _BV(PCINT1); // Set change mask for pin 1 Wire.begin(); // I2C init clear(); // Blank display ledCmd(0x21); // Turn on oscillator ledCmd(0xE0 | BRIGHTNESS); // Set brightness ledCmd(0x81); // Display on, no blink } uint8_t rep = REPS; void loop() { switch (animationSection) { case 0: for(int i=0; i 10) { animationSection = 0; } if(!--rep) { // If last cycle... ledCmd(0x20); // LED matrix in standby mode // GIMSK = _BV(PCIE); // Enable pin change interrupt // power_all_disable(); // All peripherals off // set_sleep_mode(SLEEP_MODE_PWR_DOWN); // sleep_enable(); // sei(); // Keep interrupts disabled // sleep_mode(); // Power down CPU (pin 1 will wake) // Execution resumes here on wake. // PLD - Simply Sleep for 2 minutes then start again... //delay(100000); //delay(100000); delay(120000); animationSection = 0; GIMSK = 0; // Disable pin change interrupt rep = REPS; // Reset animation counter power_timer0_enable(); // Re-enable timer power_usi_enable(); // Re-enable USI Wire.begin(); // Re-init I2C clear(); // Blank display ledCmd(0x21); // Re-enable matrix } } ISR(PCINT0_vect) {} // Button tap 
This is a section of the anim file. I want to be able to set the various colors in these "frames"
// Animation data for Trinket/Gemma + LED matrix backpack jewelry. // Edit this file to change the animation; it's unlikely you'll need // to edit the source code. #define REPS 10 // Number of times to repeat the animation loop (1-255) const int frameSpeed2 = 3; const uint8_t PROGMEM anim2[] = { // Animation bitmaps. Each frame of animation MUST contain // 8 lines of graphics data (there is no error checking for // length). Each line should be prefixed with the letter 'B', // followed by exactly 8 binary digits (0 or 1), no more, // no less (again, no error checking). '0' represents an // 'off' pixel, '1' an 'on' pixel. End line with a comma. B00000000, B00000000, B00000000, B00000000, B00000000, B00000000, B00000000, B00000000, frameSpeed2, // 0.10 seconds }; 
submitted by pldiguanaman to arduino [link] [comments]

BINARY OPTIONS STRATEGY THAT WORKS - Binary Options Live ... BINARY OPTIONS TUTORIAL - How to Get Right Binary Options ... BINARY OPTIONS TRADING - New Binary Options Trading ... STRATEGIA OPZIONI BINARIE VINCENTE - YouTube Most powerful breakout strategy in binary option 2020 ... Best IQ Options Trading Strategy Binary Options - YouTube Binary Options Strategy - YouTube BINARY OPTIONS TRADING SYSTEM - REAL ACCOUNT - Binary ... REAL MONEY! BINARY OPTIONS TRADING - Profit with Binary ... Trade WhichWays with WhichWay Binary Options trading ...

The binary numeral system uses the number 2 as its base (radix). As a base-2 numeral system, it consists of only two numbers: 0 and 1. While it has been applied in ancient Egypt, China and India for different purposes, the binary system has become the language of electronics and computers in the modern world. This is the most efficient system to detect an electric signal’s off (0) and on (1 ... Binary options MT4 indicators download google / Tc admiral markets Forex; Watino investment advisor / Murrey math lines Forexworld; Indikator Forex yang bagus film / Dscp 26 binary options; How to invest your money like the rich don t go to heaven / Ramzy; Binary options brokers canada; Perevorot v 2 2 / Forex bygglov ; Property investment guide malaysia; Forex trader pro forgot password ... Friday, 17 February 2017. 0x15 Binary Optionen September 07, 2018 0x15 binary options Binary options platform software / Binary option indicator trader elite penny; Trade binary options 2020 calendar; Tomorrow Forex; Coin collection as an investment; Forextsd; Forex show london / Phet daravong investment; Icm metatrader download for android; Abr investment strategy / Helm ink centro jet motif investing; Us regulated binary options broker ; One click binary options; Blender2ogre ... Wednesday, 26 April 2017. 0x15 Binary Options There Makelar Pilihan Biner Indonesia: 0x15 Biner Pilihan are several naïve traders & investors in the binary options trading industry who are not aware of the complete binary trading system. As such, it is important for them to know about the in-depth Makelar Pilihan Biner Indonesia: 0x15 Biner Pilihan knowledge about the binary options trading industry for ensuring their success in the same. Friday, 17 November 2017. 0x15 Binäre Optionen You should understand and accept Makelar Pilihan Biner Indonesia: 0x15 Biner Pilihan the Binary Options market risks. You may make profits or lose a part or all your money. Therefore, be careful and practice in your demo account before starting to trade. Guet. Entry Spot. The entry spot is the first tick after the contract is processed by our servers. Best satisfaction rate (97%) Excellent ... Binary Options Broker Hoewel binêre opsies is 'n relatief nuwe manier om handel te dryf in die aandelemark en ander finansiële markte, dit i...

[index] [1056] [660] [27013] [7594] [15246] [4913] [24308] [5881] [8494] [3473]

BINARY OPTIONS STRATEGY THAT WORKS - Binary Options Live ...

I Do Not Own Copyrights To Music! In today’s video I will be showing you guys A super easy 4 step profitable binary options strategy. It works for Forex Trad... Free demo account https://clck.ru/RrWGe _____ binary options,binary options strategy,binary o... # Open IQ Option Demo Account https://urlzs.com/q6kvy! Totally Free 10000$ Demo account!Join Facebook Group: https://www.facebook.com/groups/21656...Telegra... BINARY OPTIONS TUTORIAL - How to Get Right Binary Options Signal ★ TRY STRATEGY HERE http://iqopts.com/demo ★ WORK ON REAL MONEY http://iqopts.com/regist... BINARY OPTIONS TRADING - New Binary Options Trading Strategy ★ TRY STRATEGY HERE http://iqopts.com/demo ★ WORK ON REAL MONEY http://iqopts.com/register ★... BINARY OPTIONS STRATEGY THAT WORKS - Binary Options Live Trading ★ TRY STRATEGY HERE http://iqopts.com/demo ★ WORK ON REAL MONEY http://iqopts.com/regist... BINARY OPTIONS TRADING SYSTEM - REAL ACCOUNT - Binary Options Brokers ★ TRY STRATEGY HERE http://iqopts.com/demo ★ WORK ON REAL MONEY http://iqopts.com/r... Ciao in questo video ti mostro un operazione vincente fatta con il gruppo cabras university🔥Non hai mai fatto trading?Hai paura di farlo oppure hai poco capita... REAL MONEY! BINARY OPTIONS TRADING - Profit with Binary Options ★ TRY STRATEGY HERE http://iqopts.com/demo ★ WORK ON REAL MONEY http://iqopts.com/registe... Binary trading tutorial video showcasing the "WhichWays" option type for the WhichWay Binary trading platform. Come and join us on http://www.whichway.com/re...

http://binaryoptiontrade.cadesent.ml