TL; DR
మేవెన్ సెంట్రల్ ఆర్టిఫ్యాక్ట్ ఈ విధంగా ప్రచురించబడింది io.github.davidtimur:c2-lab తొమ్మిది విడుదలలను పంపిణీ చేసింది, వాటిలో ఎనిమిది, jar ఫైల్ను దాని అనొటేషన్-ప్రాసెసర్ పాత్లో ఉంచిన ఏదైనా డౌన్స్ట్రీమ్ ప్రాజెక్ట్ యొక్క కంపైలేషన్ సమయంలో రిమోట్-యాక్సెస్ పేలోడ్ను అమలు చేశాయి. ఏ అప్లికేషన్ కోడ్ కూడా దానిని ఇంపోర్ట్ చేయవలసిన అవసరం లేదు. సోర్స్ కోడ్లోని ఏ ఒక్క లైన్ కూడా దానిని రిఫరెన్స్ చేయవలసిన అవసరం లేదు. ఇన్స్టాల్ స్క్రిప్ట్ గానీ, పోస్ట్ఇన్స్టాల్కు సమానమైనది గానీ, లేదా టూలింగ్ పరిశీలించడానికి ఎలాంటి లైఫ్సైకిల్ హుక్ గానీ లేదు.
ఎగ్జిక్యూషన్ వెక్టర్ అనేది jar లోపల ఉండే ఒకే 46-బైట్ ఫైల్: ఇది ఒక జావా సర్వీస్-ప్రొవైడర్ రిజిస్ట్రేషన్, ఇది ఒక క్లాస్ను అమలు చేస్తూ పేరు పెడుతుంది. javax.annotation.processing.Processorజావా కంపైలర్ అటువంటి రిజిస్ట్రేషన్లను స్వయంచాలకంగా కనుగొంటుంది. ఒకసారి కనుగొన్న తర్వాత, javac కంపైల్ చేసే సాధారణ ప్రక్రియలో భాగంగా ఇది క్లాస్ను ఇన్స్టాంటియేట్ చేసి రన్ చేస్తుంది. అంటే, పేలోడ్ యొక్క రన్టైమ్ ఎన్విరాన్మెంట్ బిల్డ్ మెషీన్. ప్రస్తుతం ఆ బిల్డ్ మెషీన్, దాని అసలు పనిని చేస్తోంది.
తొమ్మిది విడుదలలలో కమాండ్-అండ్-కంట్రోల్ ఛానెల్ మూడుసార్లు పునర్నిర్మించబడింది: మొదట ఆపరేటర్ అందించిన కాల్బ్యాక్ URL, ఆ తర్వాత ngrok TCP టన్నెల్ ద్వారా రివర్స్ షెల్, ఆపై దాని మార్గాలు మరో రెండుసార్లు మారిన HTTP పోలింగ్ ఛానెల్. చివరి విడుదలలో, JVM డిఫాల్ట్గా నో-ఆప్ TLS ట్రస్ట్ మేనేజర్ ఇన్స్టాల్ చేయబడింది. కంపైల్ వ్యవధిలో ఏదైనా సర్టిఫికేట్ను అంగీకరించడం.
ఆ ఆర్టిఫ్యాక్ట్ దాని స్వంత POMలో "C2 ల్యాబ్ పేలోడ్" అనే పదాలను మరియు ఒక MIT లైసెన్స్ను కలిగి ఉంది. మేము దానిని గమనించిన మొత్తం కాలంలో అది మేవెన్ సెంట్రల్లో ప్రత్యక్షంగా ఉంది. అప్పటి నుండి దాని మొత్తంతో పాటు తొలగించబడింది io.github.davidtimur సమూహం.
నిర్మాణం: ఎగ్జిక్యూషన్ ఇంజిన్గా కంపైలర్
జావా యొక్క అనొటేషన్ ప్రాసెసింగ్ ఫ్రేమ్వర్క్, లైబ్రరీలు కంపైల్ సమయంలో కోడ్ను రూపొందించడానికి వీలు కల్పిస్తుంది — లోంబోక్, డాగర్, మరియు అనేక ORM మరియు సీరియలైజేషన్ సాధనాల వెనుక ఉన్న యంత్రాంగం ఇదే. ఒక ప్రాసెసర్, jar లోపల ఒక ప్లెయిన్-టెక్స్ట్ ఫైల్తో తన ఉనికిని చాటుకుంటుంది:
META-INF/services/javax.annotation.processing.Processor
ప్రభావితమైన ప్రతి విడుదలలోని ఆ ఫైల్ యొక్క విషయాలు, యథాతథంగా మరియు పూర్తిగా:
io.github.davidtimur.c2lab.C2Processor
ఈ ఫైల్ 1.0.1 నుండి 1.0.8 వరకు ఉన్న విడుదలలలో బైట్ పరంగా ఒకేలా ఉంటుంది, md5 7d2a08a5c8869a47eea9fa62487dfbe4. విడుదల 1.0.0లో ఇది లేదు.
ఎప్పుడు జావాక్ ఇది రన్ అయినప్పుడు, ఈ సర్వీస్ ఎంట్రీల కోసం అనొటేషన్-ప్రాసెసర్ పాత్ను స్కాన్ చేసి, దొరికిన వాటిని లోడ్ చేస్తుంది. కంపైల్ చేయబడుతున్న ప్రాజెక్ట్లో ప్రాసెసర్ను ప్రస్తావించడం, దేనినీ అనొటేట్ చేయడం, లేదా దేనినీ కాన్ఫిగర్ చేయడం వంటివి చేయనవసరం లేదు. పాత్లో దాని ఉనికి ఉంటే సరిపోతుంది. చాలా టూల్స్ ఆధారపడిన సప్లై-చైన్ ప్యాటర్న్ల నుండి JavacDoorను వేరుచేసే లక్షణం ఇదే:
ఇన్స్టాల్ హుక్ అనేది మానిఫెస్ట్లోని ఒక డిక్లరేషన్, మరియు ఎవరైనా చదివే మొదటి విషయం మానిఫెస్టే. ఇంపోర్ట్-టైమ్ పేలోడ్ కనీసం చదవగలిగే సోర్స్లో ఉంటుంది. సర్వీస్ రిజిస్ట్రేషన్ ఈ రెండూ కాదు: అది ఒక ఫైల్ పేరు మరియు ఒక క్లాస్ను పేర్కొనే ఒక లైన్ మాత్రమే, మరియు దాని ప్రవర్తన ఒక డైరెక్టరీ దూరంలో కంపైల్ చేయబడిన బైట్కోడ్లో ఉంటుంది.
పేలోడ్ క్లాస్ స్వయంగా షెల్లింగ్ అవుట్ చేయడం ద్వారా హోస్ట్ నిఘాను నిర్వహిస్తుంది. కంపైల్ చేయబడిన క్లాస్ల యొక్క కాన్స్టాంట్ పూల్స్లో ఇవి ఉంటాయి / Bin / sh, నేను ఎవరు, నాతో కలువు, pwd యూనిక్స్ మార్గంలో మరియు పనుల జాబితా విండోస్ మార్గంలో, కలిసి redirectErrorstream చైల్డ్ ప్రాసెస్ యొక్క ఎర్రర్ అవుట్పుట్ను క్యాప్చర్ చేయబడిన స్ట్రీమ్లోకి విలీనం చేయడానికి. రెండు JSON టెంప్లేట్లు హోస్ట్ నుండి ఫలితాలను తీసుకువెళ్తాయి — ఒక రిజిస్ట్రేషన్ బీకన్:
{"host":"%s","os":"%s","user":"%s","dir":"%s"}
నుండి జనాభా హోస్ట్ పేరుకి ఆదేశం మరియు ఓఎస్.పేరు, వినియోగదారు పేరుమరియు యూజర్.డైర్ సిస్టమ్ ప్రాపర్టీలు, మరియు ఒక ఫలిత కాల్బ్యాక్:
{"version":"%s","host":"%s","time":"%s","output":"%s"}
కంపైలర్ యొక్క సొంత అవుట్పుట్లో మిగిలి ఉన్న పురోగతి సూచికలు అసాధారణంగా నిష్కపటంగా ఉన్నాయి: [C2] కంపైల్-టైమ్ అమలు పూర్తయింది, [C2] కాల్బ్యాక్ పంపబడింది → HTTP , [C2] షెల్ కనెక్ట్ చేయబడింది .
తొమ్మిది విడుదలలు, మూడు C2 తరాలు
ఈ విడుదలలు ఒకే పేలోడ్ యొక్క తొమ్మిది కాపీలు కావు. అవి ఒక పునరావృత లాగ్, మరియు వాటిని వరుసక్రమంలో చదివితే, డెలివరీ వెక్టర్ స్థిరంగా ఉండగా ఛానల్ పునర్నిర్మించబడుతున్నట్లు తెలుస్తుంది.
ఆ పట్టికలోని మూడు వివరాలను ప్రత్యేకంగా ప్రస్తావించడం ముఖ్యం, ఎందుకంటే వాటిలో ప్రతి ఒక్కటీ ఆర్టిఫ్యాక్ట్ సెట్ను అర్థం చేసుకునే విధానాన్ని మారుస్తుంది.
వెక్టర్ 1.0.2 వద్దకు కాకుండా 1.0.1 వద్దకు చేరుకుంటుంది. రిలీజ్ 1.0.0 అదే రెకనైసెన్స్ మరియు కాల్బ్యాక్ లాజిక్ను కలిగి ఉంటుంది, కానీ దీనికి సర్వీస్ ఫైల్ మరియు అనొటేషన్-ప్రాసెసింగ్ ఇంపోర్ట్లు ఉండవు; ఏదైనా దానిని పిలిస్తేనే ఇది రన్ అవుతుంది. 1.0.1 నుండి సర్వీస్ ఫైల్ అందుబాటులో ఉంది మరియు కంపైల్ చేయబడిన క్లాసులు ఇంపోర్ట్ చేయబడతాయి. javax.annotation.processing.SupportedSourceVersion1.0.0 మరియు 1.0.2 అనే రెండు విడుదలలను పోల్చే ఏ మదింపు అయినా, ఏదో మార్పు జరిగిందని సరిగ్గా నిర్ధారిస్తుంది, కానీ అది ఎక్కడ జరిగిందో తప్పుగా గుర్తిస్తుంది.
రివర్స్ షెల్ కేవలం ఒకే విడుదలలో ఉంటుంది. విడుదల 1.0.2 కలిగి ఉంది 0.tcp.ngrok[.]io, లాగ్ లైన్ [C2] షెల్ 0.tcp.ngrok[.]io:19823కి కనెక్ట్ చేయబడింది, ఒక ఇంటరాక్టివ్ బ్యానర్ సి2-షెల్మరియు ఒక ఫ్రేమ్ టెర్మినేటర్ ముగింపు1.0.3 మరియు ఆ తర్వాతి విడుదలలలో వాటిలో ఏవీ లేవు, బదులుగా అవి ఒక HTTPS హోస్ట్ను చేరుకుంటాయి. టికెట్ చేయబడిన విడుదలలను మాత్రమే పేర్కొంటూ చేసిన ఒక టేక్డౌన్ అభ్యర్థన, పనిచేయని TCP ఎండ్పాయింట్ను ఉదహరించి, ఆ తర్వాత వచ్చిన ఆరు విడుదలలలో ఉన్న లైవ్ HTTP ఛానెల్ను ప్రస్తావించకుండా వదిలివేసి ఉండేది.
తుది విడుదల రవాణా ధృవీకరణను తొలగిస్తుంది. విడుదల 1.0.8 అమలు చేసే ఒక తరగతిని జోడిస్తుంది javax.net.ssl.X509TrustManager దీని సర్టిఫికేట్-తనిఖీ పద్ధతులు ఏమీ చేయవు, దీని ద్వారా నమోదు చేయబడిన ఎల్లప్పుడూ నిజమైన హోస్ట్ పేరు వెరిఫైయర్ setDefaultHostnameVerifier, మరియు ఒక అందరినీ నమ్మండి ఈ రొటీన్ రెండింటినీ JVM యొక్క డిఫాల్ట్లుగా ఇన్స్టాల్ చేస్తుంది. దీని ప్రభావం ఏమిటంటే, ఆ కంపైల్ పూర్తయ్యేంత వరకు, JVM ఏ హోస్ట్ నుండి అయినా ఏ సర్టిఫికేట్నైనా అంగీకరిస్తుంది — కేవలం పేలోడ్ యొక్క సొంత ట్రాఫిక్ కోసమే కాకుండా, ఆ తర్వాత బిల్డ్ TLS ద్వారా చేసే మరే ఇతర పనికైనా కూడా.
HTTP ఛానెల్ను ఉపయోగించే ఆరు విడుదలలలోనూ, దానికి ముందు ఒకే హోస్ట్ ఉంటుంది: tableful-fervor-crazed.ngrok-free[.]devప్రతి అభ్యర్థన హెడర్ను కలిగి ఉంటుంది ngrok-skip-browser-warningఇది ఉచిత ngrok టన్నెల్స్ బ్రౌజర్లకు అందించే మధ్యంతర పేజీని అణిచివేస్తుంది. విడుదలల వారీగా పాత్ సెట్లు మారుతాయి — /బయట 1.0.7 వద్ద అదృశ్యమవుతుంది, మరియు /cmd దీనితో మారుతుంది /పోల్ కానీ ఆతిథేయుడు ఎప్పటికీ మారడు.
స్వీయ-బహిష్కరణ చెబుతుంది
1.0.1 నుండి ప్రతి POM, ఆర్టిఫ్యాక్ట్ యొక్క సొంత బిల్డ్ కోసం ఒక కంపైలర్ ఆర్గ్యుమెంట్ను సెట్ చేస్తుంది:
-ప్రొక్:నన్
ఆ ఫ్లాగ్ అనోటేషన్ ప్రాసెసింగ్ను నిలిపివేస్తుంది. ఇక్కడ దాని ప్రభావం ముందుగాcise: ప్రాసెసర్ను కలిగి ఉన్న ప్రాజెక్ట్ కంపైల్ చేయబడినప్పుడు, ప్రాసెసర్ పనిచేయదు.
ఈ ఫ్లాగ్కు పూర్తిగా సాధారణ ఉపయోగాలు ఉన్నాయి. ఒక అనొటేషన్ ప్రాసెసర్ను అందించే ప్రాజెక్ట్, బూట్స్ట్రాప్ సమయంలో ఆ ప్రాసెసర్ను తనకు తానుగా వర్తింపజేయకుండా ఉండవలసి వస్తుంది, మరియు బిల్డ్-టూల్ డాక్యుమెంటేషన్ కూడా సరిగ్గా ఇదే సిఫార్సు చేస్తుంది. దీనిని విడిగా తీసుకుంటే, అది దేనినీ నిరూపించదు.
అయితే, ప్రాసెసర్ చేసే పనితో కలిపి చూసినప్పుడు, ఇది ఒక నిర్దిష్ట అసమానతను వివరిస్తుంది: కోడ్, ఆర్టిఫ్యాక్ట్ను బిల్డ్ చేసే మెషీన్లో కాకుండా, దానికి వ్యతిరేకంగా కంపైల్ చేసే ప్రతి ఒక్కరి మెషీన్లలో ఎగ్జిక్యూట్ అవుతుంది. ఈ ఫ్లాగ్, సర్వీస్ ఫైల్ను పరిచయం చేసిన అదే రిలీజ్ — 1.0.1 — లో మరియు దాని తర్వాత వచ్చిన ప్రతి రిలీజ్లోనూ కనిపిస్తుంది. "కంపైల్-టైమ్ ఎగ్జిక్యూషన్ ప్రారంభమయ్యే రిలీజ్" మరియు "స్థానికంగా కంపైల్-టైమ్ ఎగ్జిక్యూషన్ స్విచ్ ఆఫ్ చేయబడిన రిలీజ్" మధ్య ఉన్న సంబంధమే ఆర్టిఫ్యాక్ట్ సెట్లోని అత్యంత ఉపయోగకరమైన విశ్లేషణాత్మక సంకేతం, మరియు ఇది దేనినీ డీకంపైల్ చేయకుండానే ఒక ప్లెయిన్-టెక్స్ట్ POMలో కనిపిస్తుంది.
మేము ప్రభావాన్ని గమనించి అక్కడితో ఆపేస్తాము. ఫ్లాగ్ ఎందుకు సెట్ చేయబడిందో ఆర్టిఫ్యాక్ట్స్లో ఏదీ తెలియజేయడం లేదు.
ప్రధానంగా దానిని పరిష్కరించడానికే, మరో మెటాడేటా అంశం ప్రస్తావించదగినది. POM ఈ ప్రాజెక్ట్కు “C2 ల్యాబ్ పేలోడ్” అని పేరు పెట్టింది, దానిని “C2 ల్యాబ్ పేలోడ్ ఆర్టిఫ్యాక్ట్”గా వర్ణించింది మరియు MIT నుండి లైసెన్స్ పొందింది. ఒక ప్యాకేజీ పరిశోధనా ప్రయోగం అని చెప్పడానికి, ఈ రకమైన స్వీయ-లేబులింగ్ను కొన్నిసార్లు సాక్ష్యంగా అందిస్తారు.cisప్రత్యక్ష ముప్పు కంటే, అప్పుడప్పుడు ఆ వ్యాఖ్యానం సరైనదే — అందుబాటులో లేని మౌలిక సదుపాయాలు కలిగిన, ప్రకటించబడిన కానరీ అనేది దీనికి భిన్నమైన వస్తువు. అది ఇక్కడ వర్తించదు. తొమ్మిది విడుదలలలో మూడుసార్లు పునర్నిర్మించబడిన అవుట్బౌండ్ మౌలిక సదుపాయాలతో, ఏ వినియోగదారుడైనా చేరుకోగలిగేలా, పబ్లిక్ రిపోజిటరీకి ప్రచురించబడిన ఒక ఫంక్షనల్ ఇంప్లాంట్, దాని మెటాడేటా దానిని ఏమని పిలిచినా సరే, అది ఒక ప్రత్యక్ష సామర్థ్యమే. POMలోని పేరు, దానికి వ్యతిరేకంగా కంపైల్ చేసే మెషీన్లో ఏమి జరుగుతుందనే దాని గురించి ఏమీ మార్చదు.
నిర్మాణ యంత్రాల సూచికలు
ఒకవేళ బిల్డ్ హోస్ట్ ఈ ఆర్టిఫ్యాక్ట్కు వ్యతిరేకంగా కంపైల్ చేస్తే, ఆ సాక్ష్యం డిస్క్పై శాశ్వత ఇంప్లాంట్లో కాకుండా బిల్డ్ లాగ్లు మరియు నెట్వర్క్ టెలిమెట్రీలో ఉంటుంది — పేలోడ్ కంపైలర్ ప్రాసెస్ లోపల రన్ అయి, దానితో పాటు నిష్క్రమిస్తుంది.
jar లేదా స్థానిక రిపోజిటరీ కాష్లో
META-INF/services/javax.annotation.processing.Processorనామకరణio.github.davidtimur.c2lab.C2Processor- సర్వీస్ ఫైల్ md5
7d2a08a5c8869a47eea9fa62487dfbe4 - తరగతులు కింద
io/github/davidtimur/c2lab/:C2Processor,C2Task,Taskమరియు 1.0.8 లో అంతర్గత తరగతిTask$1
బిల్డ్ అవుట్పుట్లో
[C2] compile-time execution complete[C2] callback sent → HTTP[C2] callback failed:[C2] shell connected to- ఇంటరాక్టివ్ బ్యానర్
c2-shellఫ్రేమ్ టెర్మినేటర్__END__
ప్రక్రియ టెలిమెట్రీలో
javacతల్లిదండ్రిగా/bin/sh -c(యూనిక్స్) లేదా విండోస్ కమాండ్ ఇంటర్ప్రెటర్- పిల్లల ఆదేశాలు
whoami,uname -a,pwd(యూనిక్స్) లేదాtasklist(విండోస్) కంపైల్ స్టెప్ ద్వారా పేరెంట్ చేయబడింది
నెట్వర్క్ టెలిమెట్రీలో
- అవుట్బౌండ్ TCP కి
0.tcp.ngrok[.]io:19823(విడుదల 1.0.2) - HTTPS
tableful-fervor-crazed.ngrok-free[.]dev, మార్గాలు/register,/cmd,/poll,/out(విడుదలలు 1.0.3 నుండి 1.0.8 వరకు) - అభ్యర్థన శీర్షిక
ngrok-skip-browser-warning: true - అభ్యర్థన బాడీలు సరిపోలుతున్నాయి
{"host":...,"os":...,"user":...,"dir":...}or{"version":...,"host":...,"time":...,"output":...}
కాన్ఫిగరేషన్లో
- పర్యావరణ వేరియబుల్స్
CALLBACK,CALLBACK_URLసిస్టమ్ ప్రాపర్టీcallback.url
ప్రచురణకర్త మెటాడేటా
- గ్రూప్
io.github.davidtimurప్రచురణకర్త చిరునామాdavudboi999@gmail[.]comసంతకం కీE520C345EF94423D
రిలీజ్ 1.0.8ను అమలు చేసిన బిల్డ్కు ఒక అదనపు తనిఖీ అవసరం. ఎందుకంటే ఆ రిలీజ్, JVM-వ్యాప్త డిఫాల్ట్గా ఒక అనుమతించే ట్రస్ట్ మేనేజర్ను ఇన్స్టాల్ చేస్తుంది, కాబట్టి అదే JVMలో తర్వాత చేసిన ఏ TLS కనెక్షన్ అయినా — డిపెండెన్సీ రిజల్యూషన్, ఆర్టిఫ్యాక్ట్ అప్లోడ్, ఒక డిప్లాయ్మెంట్ స్టెప్ — సర్టిఫికేట్ ధ్రువీకరణ లేకుండానే కొనసాగింది. ఆ విండో నుండి వచ్చే ట్రాఫిక్ను ప్రామాణీకరించబడినదిగా భావించకూడదు.
కంపైల్ చేయబడిన ఆర్టిఫ్యాక్ట్లకు వేర్వేరు స్కానింగ్ ఎందుకు అవసరం
JavacDoor ఒక ఉపయోగకరమైన పరీక్షా సందర్భం, ఎందుకంటే ఇది ఒకేసారి రెండు సాధారణ అంచనాలను తప్పు అని నిరూపిస్తుంది, మరియు ఈ వైఫల్యాలలో ఏదీ ఏ ఒక్క విక్రేత యొక్క సాధనాలకు ప్రత్యేకమైనది కాదు.
ప్రమాదకరమైన కోడ్ ఒక మానిఫెస్ట్లో తనను తాను ప్రకటించుకుంటుందనేది మొదటి అంచనా. సరఫరా గొలుసు సాధనాలలో అధిక భాగం జీవితచక్రం ఆధారంగా నిర్వహించబడుతుంది. hooksఎందుకంటే npm మరియు PyPI లకు సాధారణంగా అసలు చర్య అక్కడే ఉంటుంది. JavacDoor కు హుక్ లేదు. దాని ట్రిగ్గర్ ఒక సర్వీస్-రిజిస్ట్రేషన్ ఫైల్, దాని పేరు ఒక జావా ఇంటర్ఫేస్ మరియు దానిలోని కంటెంట్ ఒక క్లాస్ పేరు. దానిని స్టాటిక్గా పట్టుకోవాలంటే మీరు ఈ విధంగా వ్యవహరించాలి. META-INF/services/javax.annotation.processing.Processor స్వతంత్రంగా ఒక అమలు ప్రవేశ స్థానంగా, ఒక పోస్ట్ ఇన్స్టాల్ స్క్రిప్ట్ — ఆపై పేరు పెట్టబడిన క్లాస్ను అనుసరించి బైట్కోడ్లోకి వెళ్లండి. ఎకోసిస్టమ్లు ఈ ఆకారంలో తమ సొంత ఆటో-డిస్కవరీ మెకానిజమ్లను కలిగి ఉంటాయి మరియు టూలింగ్ దానిని ఒకటిగా జాబితా చేసినా చేయకపోయినా ప్రతిదీ ఒక ఎంట్రీ పాయింట్ అవుతుంది.
రెండవ ఊహ ఏమిటంటే, స్ట్రింగ్లు సోర్స్ ఫైల్స్లో ఉంటాయి. ఒక jar కోసం, ఎండ్పాయింట్లు, షెల్ కమాండ్లు, JSON టెంప్లేట్లు మరియు లాగ్ మార్కర్లు అన్నీ కాన్స్టాంట్ పూల్స్లో ఉంటాయి. .తరగతి ఫైల్స్. టెక్స్ట్ను గ్రెప్ చేసే టూల్స్కు ఏమీ దొరకదు — స్ట్రింగ్లు అస్పష్టంగా ఉన్నందువల్ల కాదు, కానీ అవి టెక్స్ట్ స్కాన్ పార్స్ చేయని ఒక నిర్మాణాత్మక బైనరీ కంటైనర్లో ఉన్నందువల్ల. ఈ పోస్ట్లోని ప్రతి నెట్వర్క్ ఇండికేటర్ కాన్స్టాంట్-పూల్ పార్సింగ్ నుండి వచ్చింది. వాటిలో ఒకటి పూర్తిగా ఏర్పడినది. https:// క్లాస్ ఫైల్లో URL స్పష్టంగా కనిపిస్తున్నప్పటికీ, jar యొక్క చదవగలిగే కంటెంట్ను టెక్స్ట్ రూపంలో స్కాన్ చేసినా అది బయటపడదు. ఇక్కడ అధిగమించడానికి ఎన్కోడింగ్ ఏమీ లేదు, కేవలం చదవడానికి ఒక కంటైనర్ ఫార్మాట్ మాత్రమే ఉంది.
రెండు లోపాలూ ఒకే ఆకారాన్ని కలిగి ఉన్నాయి: ఒక ఆర్టిఫ్యాక్ట్ ఫార్మాట్ను, నిర్వచించబడిన సెమాంటిక్స్తో కూడిన నిర్మాణంగా కాకుండా, ఫైళ్ల సముదాయంగా పరిగణించడం జరిగింది. దీనిని సరిదిద్దడం అంత ఆకర్షణీయమైనది కాదు — కంటైనర్ను పార్స్ చేయడం, ఎకోసిస్టమ్ యొక్క సొంత ఆటో-డిస్కవరీ ఎంట్రీ పాయింట్లను జాబితా చేయడం, మరియు వాటిని అనుసరించి కంపైల్ చేయబడిన కోడ్లోకి వెళ్లడం. ప్రత్యేకంగా బిల్డ్-టైమ్ వెక్టర్స్ కోసం, మూడవ తనిఖీ చవకైనది మరియు ఆశ్చర్యకరంగా నిర్ధారణాత్మకమైనది: ఒక ఆర్టిఫ్యాక్ట్ వినియోగదారుల కోసం ఏమి చేస్తుందో, మరియు అది దేని నుండి మినహాయింపు పొందుతుందో పోల్చి చూడండి. ఒక కంపైల్-టైమ్ ప్రాసెసర్ను నమోదు చేసుకుని, అదే సమయంలో తన సొంత బిల్డ్ కోసం కంపైల్-టైమ్ ప్రాసెసింగ్ను నిలిపివేసే ఒక ఆర్టిఫ్యాక్ట్, తన గురించి రెండు లైన్ల సాదా-టెక్స్ట్ POMలో మీకు తెలియజేసినట్లే.
ప్రస్తుతం మేవెన్ ఆర్టిఫ్యాక్ట్లను ఉపయోగించే బృందాల కోసం, మూడు ఆచరణాత్మక చర్యలు ఈ క్రింది విధంగా ఉన్నాయి:
- అనోటేషన్-ప్రాసెసర్ మార్గాన్ని ఒక ఎగ్జిక్యూషన్ సరిహద్దుగా పరిగణించండి. అక్కడ చేరే డిపెండెన్సీలు మీ బిల్డ్లో కోడ్ను రన్ చేస్తాయి. బిల్డ్కు అనొటేషన్ ప్రాసెసింగ్ అవసరం లేని చోట, -ప్రొక్:నన్ ఇక్కడ స్థానికంగా ఉన్నట్లే, రక్షణ పరంగా కూడా ఇది అంతే ఉపయోగకరంగా ఉంటుంది; ఎక్కడైతే ఇది ఉపయోగపడుతుందో, అక్కడ కంపైల్ క్లాస్పాత్ నుండి వారసత్వంగా పొందకుండా, ప్రాసెసర్ సెట్ను స్పష్టంగా పిన్ చేయండి.
- కంపైలర్ ఉపప్రక్రియలను లాగ్ చేయండి. చాలా ప్రాజెక్ట్లలో షెల్ను ప్రారంభించే కంపైల్ స్టెప్ అసాధారణమైనది మరియు దీనిని సులభంగా గుర్తించవచ్చు.
- మెటాడేటాను సాక్ష్యంగా పరిగణించవద్దు. ప్యాకేజీ పేరు లేదా వివరణలోని “Lab”, “test”, “payload”, మరియు “PoC” అనేవి పరిధి పరిమితులు కావు. చేరుకోగల సామర్థ్యం మరియు ప్రవర్తన అనేవి పరిమితులు.
ఆ కళాఖండాన్ని మరియు దాని మొత్తం సమూహాన్ని తొలగించారు మావెన్ మా నివేదికను అనుసరించి సెంట్రల్; ఆర్టిఫ్యాక్ట్ పాత్ మరియు గ్రూప్ పాత్ రెండూ ఇప్పుడు 404ను తిరిగి ఇస్తున్నాయి, మరియు సెంట్రల్ ఇండెక్స్ సరిపోలే కోఆర్డినేట్లు ఏవీ లేవని నివేదిస్తోంది. అది ఈ ఆర్టిఫ్యాక్ట్ను మూసివేస్తుంది. ఇది వెక్టర్ను మూసివేయదు, ఇది జావా కంపైలర్ యొక్క డాక్యుమెంట్ చేయబడిన ఫీచర్ మరియు jarను ప్రచురించే ఎవరికైనా అందుబాటులో ఉంటుంది.
ప్రస్తావనలు
ఈ పోస్ట్ ఎటువంటి బాహ్య మూలాలను ఉదహరించలేదు. తొలగింపుకు ముందు మేవెన్ సెంట్రల్ నుండి పొందిన, ప్రచురించబడిన తొమ్మిది జార్ల యొక్క ప్రత్యక్ష స్టాటిక్ విశ్లేషణే ఇక్కడ కనుగొన్న విషయాలన్నీ. ఆర్టిఫ్యాక్ట్ల నుండి ఏ కోడ్ కూడా ఏ దశలోనూ అమలు చేయబడలేదు.
