Proxychains LD_PRELOAD പരാജയങ്ങൾ കണ്ടെത്തൽ

പ്രോഗ്രാം ആരംഭിക്കുന്നു, പക്ഷേ proxychains ലൈബ്രറി മുൻകൂട്ടി ലോഡ് ചെയ്യാനായില്ലെന്ന് ടെർമിനൽ പറയുന്നു. അതിനെ പരാജയപ്പെട്ട സെറ്റപ്പ് ഘട്ടമായി കാണുക, എക്സിറ്റ് IP പരിശോധിക്കുമ്പോൾ അവഗണിക്കാവുന്ന നിരുപദ്രവകരമായ മുന്നറിയിപ്പായി അല്ല.

Proxychains-ng പ്രസക്തമായ കോളുകൾ തടയാൻ ലോഡ് ചെയ്ത ഒരു ലൈബ്രറിയെ ആശ്രയിക്കുന്നു. ആ ലൈബ്രറി ഇല്ലെങ്കിൽ, പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ അല്ലെങ്കിൽ പ്രോസസ്സിൽ ലോഡ് ചെയ്തിട്ടില്ലെങ്കിൽ, പ്രോഗ്രാം നിങ്ങൾ പ്രതീക്ഷിച്ച ഇന്റർസെപ്ഷൻ ഇല്ലാതെ പ്രവർത്തിക്കാം.

ലൈബ്രറിയെ പ്രോസസ്സുമായി ചേർക്കുക

പാക്കേജിന്റെ യഥാർത്ഥ ലൈബ്രറി സ്ഥാനവും എക്സിക്യൂട്ടബിളിന്റെ ആർക്കിടെക്ചറും പരിശോധിക്കുക. 32-bit പാത്ത് ഹാർഡ്കോഡ് ചെയ്യുന്ന പഴയ ഉത്തരം 64-bit പ്രോഗ്രാമിനുള്ള പൊതുവായ പരിഹാരമല്ല. പരിശോധിക്കാത്ത പ്രീലോഡ് ക്രമീകരണം ഓരോ shell സെഷനിലേക്കും ആഗോളമായി ചേർക്കരുത്.

Linux ഡൈനാമിക് ലോഡറിന്റെ കൈപ്പുസ്തകം ലൈബ്രറി തിരച്ചിലും സുരക്ഷിത എക്സിക്യൂഷൻ നിയന്ത്രണങ്ങളും വിശദീകരിക്കുന്നു. ചില പ്രോസസ്സ് ലോഞ്ച് സാഹചര്യങ്ങൾ പ്രീലോഡ് ക്രമീകരണങ്ങൾ ബോധപൂർവം അവഗണിക്കുകയോ പരിമിതപ്പെടുത്തുകയോ ചെയ്യുന്നു. സ്റ്റാറ്റിക് എക്സിക്യൂട്ടബിളും ഒരു എൻവയോൺമെന്റ് വേരിയബിൾ സെറ്റ് ചെയ്തതുകൊണ്ട് മാത്രം ഡൈനാമിക് ആയി തടയാവുന്നതാകുന്നില്ല.

പ്രോജക്ടിന്റെ README റാപ്പറിന്റെ പിന്തുണയുള്ള മാതൃക രേഖപ്പെടുത്തുന്നു. സ്വന്തം നെറ്റ്വർക്കിംഗ് നടപ്പാക്കൽ, വേറിട്ട സഹായ പ്രോസസ്സുകൾ അല്ലെങ്കിൽ ഇതിനകം പ്രവർത്തിക്കുന്ന ഇൻസ്റ്റൻസുകൾ ഉള്ള ആപ്ലിക്കേഷനുകൾ പ്രാരംഭ ലൈബ്രറി ലോഡ് ചെയ്താലും മറ്റ് പരിധികൾ കൊണ്ടുവരാം.

ആപ്ലിക്കേഷനിൽ സ്വദേശീയ പ്രോക്സി ക്രമീകരണം ലഭ്യമാകുമ്പോൾ അത് കൂടുതൽ വ്യക്തമായ ഓപ്ഷനായിരിക്കാം. ഓരോ കണക്ഷനും പുറത്തുനിന്ന് പിടിച്ചെടുക്കാമെന്ന് അനുമാനിക്കുന്നതിന് പകരം ആപ്ലിക്കേഷൻ ഉദ്ദേശിക്കുന്ന നെറ്റ്വർക്ക് ഇന്റർഫേസ് ഇത് ഉപയോഗിക്കുന്നു.

റാപ്പർ സെറ്റപ്പ് പരാജയപ്പെടുമ്പോൾ, നിർത്തി യഥാർത്ഥത്തിൽ എന്താണ് ലോഞ്ച് ചെയ്തതെന്ന് കണ്ടെത്തുക. പ്രോസസ്സിന്റെ എക്സിറ്റ് നില മാത്രം ആപ്ലിക്കേഷൻ പ്രവർത്തിച്ചുവെന്ന് കാണിക്കാം, അതിന്റെ ട്രാഫിക് പ്രോക്സിയിലൂടെ പോയി എന്നല്ല. ലൈബ്രറി ലോഡിംഗ്, തടഞ്ഞ കോളുകൾ, നിരീക്ഷിച്ച പുറം കണക്ഷൻ എന്നിവ വേറിട്ട തെളിവുകളായി സൂക്ഷിക്കുക.