p-sam氏が、SwitchのCPU/GPU/RAMのクロックをタイトル毎に設定出来るシステムモジュール
sys-clk 0.13.0 をリリースしていました。
- SoC/PCB/Skinの温度のモニタリングをサポート (間隔の指定可)
- ログの改善
- 実行中にログを有効/無効に出来るように
- 出力されるログの改善
- タイムスタンプがミリ秒で記録されるように
- CSVのエクスポートをサポート (間隔の指定可)
(タイムスタンプ, タイトルID, プロファイル, クロック, 温度)
- FW9.0.0に関わる修正
- Homebrewやアプリでクラッシュする事があるのを修正
が変更点です。
config.iniで温度のモニタリング間隔とCSVのエクスポート間隔をミリ秒単位で設定可能です。(0は無効)
temp_log_interval_ms=0
csv_write_interval_ms=0
kood
名無し 2019/10/26 10:54
関係ないコメントですみません
家電量販店で買ってきたdoax3というゲームをnspでバックアップして、インストールしたところ何故かそのゲームの基本無料版に変わってしまいます
解決方法をご存知であれば教えていただきたいです
名無し 2020/01/09 04:58
スイッチのソフトがバージョンアップするとチートが使えなくなるのですが
意図的にダウングレードと任意のバージョンに変更できるやり方とかありますか？
>>名無しさん
ダウングレードはGoldleafやTinfoilで実現可能です。
v1.0.0(アップデートしていない状態)へのダウングレード以外は、目的のバージョンのNSPが必要です。
●Goldleafの場合
１，[Manage console contents] → [SD card] か [NAND USER] → 目的のゲーム → [Update] → [Remove]
２，[Manage console contents] → [SD card] か [NAND USER] → 目的のゲーム → [Base title] → [Reset launch version]
●Tinfoilの場合
１，目的のゲームにカーソルを合わせXボタン
２，TypeがUPDの物を選択
３，目的のゲームにカーソルを合わせXボタン
４，Yボタン (Reset Required Version)
上記の手順でv1.0.0へのダウングレードは完了です。
v1.0.0以外が目的の場合は、続けて目的のバージョンのNSPをインストールしてください。
一応解説しておくと、SwitchはFWに各ゲームの要求FW情報を持っていると言われており、更新データを削除しただけだと
要求FWのチェックに引っかかって「ソフトの更新が必要です」と出てゲームが起動出来ない事があります。
Goldleafの場合の手順2とTinfoilの場合の手順4は、それのリセットを行うための作業です。ただ、それで100%起動出来る
ようになるかと言われるとそうではありません。リセットが成功したために「ソフトの更新が必要です」というのは表示
されなくなるものの起動の段階でエラーを吐く、という事が稀にあります。そうなる原因は不明です。
名無し 2020/04/21 09:16
記事と関係のない質問で申し訳ないです。
以前、SXOSを導入した未対策機を使っていたのですが、何故かBANになってしまい、未対策機の2017年製の新品を買い直しまして、これからatmosphereを導入しようと思うのですが唯一、本体更新はChoiDujourNXを使って、ソフト更新はネット以外のやり方が分からないので、ネットを繋ごうかと思っているのですが、それは可能でしょうか？
前のSwitchがBANになった原因を振り返ると、最初の設定でステルスモードになっておりそのまま触れずにいたので、CFWモードの時はネットに繋がっていないはずで、OFWモードで本体更新やソフトの更新、スマブラのDLCをDLしていたのですが、ある日Switchを触るとBANになっていました。
スマブラやポケモンやどうぶつの森のような任天堂が対策に本気を出したり、直ぐに新しいコンテンツをちょこちょこ卸すようなソフトは通常通り遊ぶ用のSwitchを新たに買うべきかなと思ったのですが、次また同じようなことが起こらないために気をつけたらいいことがあれば教えていただきたいです。
長文で申し訳ございませんがよろしくお願いします。
>>名無しさん
それは、SXOSではOFWモードを使用してネットに接続してゲームを更新していたがAtmosphereでもそれは可能か、という質問ですか？
そうであるなら、もちろん可能です。AutoRCMにしていない限り普通に起動すればCFWではなくOFWで起動しますし、AutoRCMでも
Atmosphereとhekateを合わせる事でSXOSのペイロード同様にOFW(stock)で起動可能です。
AtmosphereでもChoiDujourNXは使用可能か、という質問なら、それももちろん可能です。
SX OSのステルスモードは任天堂のサーバと通信出来ないようにしているだけです。それ以外の効果はありません。
Switchはエラー発生時にエラーレポートを生成しており、設定で "エラー情報の送信" が有効になっている場合はそれが送信されます。
Atmosphereにおいて、エラーレポートの生成防止は最近リリースされた0.11.0までは不完全な物でした。
SX OSはAtmosphereをベースに開発されている事が判明していますから、現状SX OSのエラーレポート生成防止は不完全です。
"エラー情報の送信" が無効になっている場合でも、OFWでオンラインになるとCFW上で生成されたエラーレポートを元にテレメトリが
発生する可能性もあった(SX OSの場合は現在も"ある")ようです。また、エラーレポート以外にもテレメトリはあるようです。
SX OSではステルスモード、Atmosphereなら90DNSによって、任天堂のサーバと通信しないようにする事は可能ですが、OFWにて
オンラインになった際のテレメトリは防ぐ事が出来ません。CFWを使用した痕跡があればBANされる可能性があります。
(OFWでも90DNSは使用可能ですが、OFWで任天堂のサーバと接続出来ないようにしてもあまり意味は無いでしょう)
SwitchのBANは、私の知る限りではBANの殆どが、「CFWを使用した痕跡」が原因と思われる「Switchの証明書のBAN」です。
これには2つあり、1つがゲームの更新及びニンテンドーアカウントでのログインが出来ないようになるBAN。通常はこれです。
もう1つはCDN BANと呼ばれ、ネット経由のFWの更新すらも出来ないようになります。こちらは本当に稀です。
他にはカートリッジ内の証明書やニンテンドーアカウントを対象とした、特定のゲームのオンラインプレイBANもあります。
アカウント自体がBANされる事は稀です。
BAN対策で重要なのは「CFWを使用した痕跡」をどれだけ隠せるかで、ステルスモードや90DNSも対策の1つですが、それらはCFWでの
通信を遮断するだけです。痕跡をSwitchのeMMCに残さないようにするための対策として、emuMMC(emuNAND)が存在します。
(AtmosphereがemuMMC、SX OSがemuNANDと呼んでいるだけで、emuMMC/emuNANDは同じ物です)
emuMMCは、事前にSwitchのeMMCをmicroSDカードに複製しておき、読み書きをそちらにリダイレクトして起動するというものです。
emuMMCでCFWを使用すればeMMCにCFWを使用した痕跡は残りません。つまりOFW環境との分離が実現可能です。
複数台のSwitchを使い分けるのも当然アリです。それ以外ではemuMMCが最も安全なCFW環境と言えます。
私に書けるのはこれくらいです。
名無し 2020/04/21 19:36
>> 管理人 koodさん
ご回答ありがとうございます。
とても分かりやすく、大変感謝感激しております。
BANの件について、管理人さまのご説明で完全に理解させていただきました。
sysNAND、emuMMCともエラー情報の送信をOFFにしておきます。
それと念押しでsysNANDとemuMMCで使う microSDカードを変えることもしておきます。
ご回答により、本体更新、ソフト更新で質問が1つ思い浮かんだので質問させてください。
今から2017年製のSwitch（新品）を改造していこうと思うのですが、初期の物なのでバージョンは相当古く、せっかくなのでfuseを焼かれるのを防ぐために、ChoiDujourNXを使って焼かれずにバージョンを上げようと思っております。
ですが、通常起動する際にはfuseの焼き個数をチェックしてから起動するということを管理者さまのChoiDujourNXの記事で拝見しました。
ということは、OFWからはChoiDujourNXで上げたバージョンでは焼き個数のチェックで弾かれ、起動できないということなのでしょうか？
ChoiDujourNXの仕組みとして、fuseを焼いていないということは、CFWでは最新バージョンとして起動できますが、OFWでは初期のバージョンとして起動するということなのでしょうか？
となると、CFWの状態でソフト更新、本体更新はリスクしかないと思うのですが、その辺はどういう風な立ち回りをするのがベストなのでしょうか？
また長々となってしまいましたが、ご回答よろしくお願いします。
>>名無しさん
Switchは起動する際、実際に焼かれている数と、FWが要求する数のチェックを行います。一致すればOFWで起動します。
焼かれている数が少なければ、FWが要求する数になるように焼いてから、OFWで起動します。これはFWの更新後の処理です。
(FWの更新でヒューズが焼かれるわけではく、更新後の再起動で先述のチェックに引っかかるようになっており、そこで焼かれます)
焼かれている数がFWが要求する数よりも多い場合、OFWは起動せずブラックスクリーンとなります。
RCMではチェックは行われないので、ChoiDujourNXはそれを確実にするためにデフォでAutoRCMを有効にします。
更新後にRCMで起動しないという事は普通に起動するという事なので、チェックに引っかかってしまいます。
(更新後の再起動時にだけチェックがあるのではなく、起動する度に毎回チェックが行われます)
100%確実にRCMで起動出来なければヒューズが焼かれてしまいますから、デフォでAutoRCMが有効になるわけです。
(AutoRCMは絶対にRCMで起動するというもので、普通の起動は出来ないようになるのでチェックは行われません)
(ヒューズを焼いても良い場合は、ChoiDujourNXでAutoRCMを有効にする必要はありません)
CFWとStock(普通の起動ではなくSX OSのペイロードやhekateから起動出来る実質OFW)は、チェックを行いません。
つまりFWの更新後、RCMで起動してCFW/Stockで起動する事で、ヒューズを焼かない起動が実現出来ます。
>CFWでは最新バージョンとして起動できますが、OFWでは初期のバージョンとして起動する
FWはeMMCに格納されます。正規の更新方法でもChoiDujourNXでも、それが書き換えられます。
CFWはCFWのデータをmicroSDカードから、それ以外の起動に必要な物をeMMCから参照し、最終的な起動を実現します。
起動に必要な物全てがmicroSDカードに揃っているわけではないので、普通はCFWとOFWを異なるバージョンで起動する事は
出来ません。emuMMCを使うのであれば話は別です。emuMMCはeMMCの複製であり、microSDカードに配置します。
つまりeMMCとemuMMCでFWは分離されています。emuMMCで起動してChoiDujourNXを使用すればemuMMCのFWの
更新が可能ですから、最新バージョンのCFW(emuMMC)と初期バージョンのOFW(eMMC)の起動は実現可能です。
(現時点でemuMMCはCFWでの起動のみに対応しており、Stockでの起動は未対応です)
>CFWの状態でソフト更新、本体更新はリスクしかない
これはネットに接続して行うのであればその通りです。CFWでそれを行うという事はステルスモードも90DNSも使用しないという事に
なるので、BANのリスクのある情報が任天堂に送信される可能性があります。
BAN対策においてはAtmosphereであってもエラー関連の対処しかしておらず、エラー以外の情報送信があるとしてそれを完全に
防ぐにはCFWではネットに接続しないか、90DNSを使用するしかありません。(SXOSならステルスモード)
ネットに接続せずゲームを更新する方法としては更新用のNSPのインストールがありますが、誰かがそれを作成する必要があります。
本体の更新はご存知のようにChoiDujourNXで実現可能です。
このように何にリスクがあるかを語ると、結論はほぼ必ず「OFWとCFWで本体分けろ」か「emuMMCでCFW起動しろ」になります。
microSDカードを分けるのは、効果が未知です。(任天堂がmicroSDカードの中身を監視しているかどうかは不明なため)
AutoRCMを使用しない場合は、CFWはemuMMC、OFWは普通に起動(eMMC)が対策になります。
emuMMCを使用しない場合は、CFWではステルスモード/90DNS、FW/ゲームの更新やeショップの利用の際はOFWを普通に
起動して、が対策になりますが、これのリスクが0ではないのはあなたも知っての通りです。
(emuMMCならステルスモード/90DNSが不要というわけではありません。それらの使用も対策になります)
AutoRCMを使用する場合、CFWはemuMMC、FW/ゲームの更新やeショップの利用の際はStock、が対策になります。
StockはSXOSのペイロードやhekateを使用した実質OFWな起動方法です。実質というのは、起動の処理が通常とは異なるため
です。それ以外はOFWと同等と言われており、Stock自体がリスクになるという説を唱える人は少数派です。
このコメントのような事を記事にしたいとは思っていますが、記事を書いてなかった時期のリリースを完全には把握していない事もあり
今は1人でリリースを振り返っている途中です。それが終わればSwitchの記事を書いたり更新したりするかもしれません。
a 2020/04/23 03:33
横からで申し訳ないのですが、私からも関連質問よろしいでしょか。
Incognitoと言うSwitch本体の固有情報を削除することが可能なツールがありますよね。
これはemuMMCに対して利用することも出来るのでしょうか？
(そもそもemuMMCの事をちゃんと理解してないのでおかしな質問になってたらスミマセン）
そしてIncognite状態のSwitchでステルスモード/90DNS等を使用せずネット接続したとしてもBANの可能性は原則として無いと言う認識は合っているでしょうか。
>>aさん
emuMMCに対して使用する事も可能です。Incognito_RCMでやるのが一番楽だと思います。
https://github.com/borntohonk/Incognito_RCM/releasesIncognitoは本体毎に固有の情報が格納されたPRODINFOパーティションから一部の情報を削除します。
(全てを削除しない理由は公表されていません)
残りの情報が任天堂に送信される可能性、そしてそこからどの本体かを割り出される可能性は否定出来ません。
そのため、Incognitoを使用したとしても100%の安全性は保証されないという事になります。
私としては、Incognitoはステルスモード/90DNSの代わりではなく、そのオプションという認識です。
ステルスモード/90DNSが任天堂との通信を完全に遮断しているとするなら、任天堂に情報は送信されませんから、
emuMMCに対するIncognitoはBAN対策としては無意味と言えます。
しかし遮断漏れがあるとするなら、Incognitoを使用する事でリスクは軽減されるかもしれません。
つまり、ステルスモード/90DNSだけでは不安ならIncognitoも使ってみては、という感じです。
≪ 次の記事 | HOME |
前の記事 ≫
2019/09/21 21:05
